--- title: "Backend implementation" description: "Build the REST API that FlowDrop expects to communicate with." source: https://flowdrop.io/docs/editor/integration/backend-implementation site: FlowDrop documentation --- # Backend implementation FlowDrop is a frontend editor that calls **your** backend REST API. This guide explains what endpoints to implement, what request/response formats FlowDrop expects, and how to get a working backend running. ## Endpoint Tiers Not all endpoints are required. Here they are organized by priority: ### Tier 1: Minimum Viable Backend These 5 endpoints are the **bare minimum** to get FlowDrop working: | Method | Path | Purpose | | ------ | ---------------- | -------------------------------------------- | | `GET` | `/health` | Health check (FlowDrop checks this on mount) | | `GET` | `/nodes` | List available node types | | `GET` | `/workflows/:id` | Load a workflow | | `POST` | `/workflows` | Create a new workflow | | `PUT` | `/workflows/:id` | Update an existing workflow | ### Tier 2: Full Editor Experience These endpoints enable the complete sidebar, categories, and port validation: | Method | Path | Purpose | | -------- | ---------------- | ------------------------------------------ | | `GET` | `/categories` | Node category definitions (sidebar groups) | | `GET` | `/port-config` | Port data types and compatibility rules | | `GET` | `/nodes/:id` | Get a single node's metadata | | `GET` | `/workflows` | List all workflows | | `DELETE` | `/workflows/:id` | Delete a workflow | ### Tier 3: Advanced Features These enable playground, execution, and interrupts: | Method | Path | Purpose | | ------ | -------------------------------------- | ------------------------- | | `POST` | `/workflows/:id/execute` | Execute a workflow | | `GET` | `/executions/:id` | Get execution status | | `POST` | `/workflows/:id/playground/sessions` | Create playground session | | `GET` | `/playground/sessions/:sid/messages` | Poll for messages | | `POST` | `/playground/sessions/:sid/messages` | Send user message | | `GET` | `/interrupts/:id` | Get pending interrupt | | `POST` | `/interrupts/:id` | Resolve an interrupt | | `GET` | `/system/config` | Runtime configuration | **The OpenAPI spec is the authoritative contract.** The Tier 1–2 shapes are documented in full below, the Tier 3 shapes under [Advanced endpoint formats](#advanced-endpoint-formats-tier-3). For the exhaustive schema, see the [OpenAPI specification](/api). ## Base URL Configuration All paths above are relative to a base URL you configure: ```typescript import { createEndpointConfig } from '@flowdrop/flowdrop/core'; const endpointConfig = createEndpointConfig('/api/flowdrop'); // Nodes endpoint becomes: GET /api/flowdrop/nodes ``` ## Request & Response Formats ### `GET /health` FlowDrop calls this to verify the backend is reachable. **Response:** ```json { "status": "ok", "version": "1.0.0" } ``` ### `GET /nodes` Returns all available node types. FlowDrop uses this to populate the sidebar. **Query parameters:** - `category` (optional) — filter by category - `search` (optional) — search name/description - `limit` (optional, default: 100) - `offset` (optional, default: 0) **Response:** ```json { "success": true, "data": [ { "node_type_id": "text_input", "name": "Text Input", "description": "Accepts text from the user", "type": "simple", "category": "inputs", "icon": "mdi:text-box-outline", "inputs": [], "outputs": [ { "id": "output", "name": "Text", "type": "output", "dataType": "string" } ], "configSchema": { "type": "object", "properties": { "placeholder": { "type": "string", "title": "Placeholder", "default": "Enter text..." } } } } ] } ``` **Key fields in `NodeMetadata`:** - `node_type_id` (required) — unique node-type identifier - `name` (required) — display name - `type` — node visual type: `workflowNode`, `simple`, `square`, `tool`, `gateway`, `terminal`, `idea`, `note` - `category` — sidebar group: `inputs`, `outputs`, `models`, `processing`, `logic`, `tools`, etc. - `icon` — [Iconify](https://icon-sets.iconify.design/) icon ID (e.g., `mdi:text-box-outline`) - `inputs` / `outputs` — port definitions with `id`, `name`, `type`, `dataType` - `configSchema` — JSON Schema defining the configuration form ### `POST /workflows` Creates a new workflow. FlowDrop sends the full workflow JSON. **Request body:** ```json { "name": "My Workflow", "description": "A simple workflow", "nodes": [ { "id": "node-1", "type": "simple", "position": { "x": 100, "y": 200 }, "data": { "label": "Text Input", "config": { "placeholder": "Enter text..." }, "metadata": { "node_type_id": "text_input", "name": "Text Input", "...": "..." } } } ], "edges": [ { "id": "edge-1", "source": "node-1", "sourceHandle": "output", "target": "node-2", "targetHandle": "input" } ] } ``` **Response:** ```json { "success": true, "data": { "id": "wf-abc123", "name": "My Workflow", "nodes": [], "edges": [], "metadata": { "schemaVersion": "1.0.0", "createdAt": "2025-01-01T00:00:00Z", "updatedAt": "2025-01-01T00:00:00Z" } } } ``` ### `PUT /workflows/:id` Updates an existing workflow. Same request body format as `POST`. ### `GET /workflows/:id` Returns a single workflow by ID. Same response format as `POST` response. ### `GET /categories` Returns category definitions for the node sidebar. **Response:** ```json { "success": true, "data": [ { "id": "inputs", "name": "Inputs", "description": "Data input nodes", "icon": "mdi:import", "color": "var(--fd-node-emerald)", "weight": 10 }, { "id": "processing", "name": "Processing", "description": "Data transformation nodes", "icon": "mdi:cog", "color": "var(--fd-node-blue)", "weight": 30 } ] } ``` ### `GET /port-config` Returns data type definitions and compatibility rules for port connections. **Response:** ```json { "success": true, "data": { "version": "1.0.0", "defaultDataType": "string", "dataTypes": [ { "id": "string", "name": "String", "description": "Text data", "color": "#10b981", "category": "basic" }, { "id": "json", "name": "JSON", "description": "Structured data", "color": "#f59e0b", "category": "complex" } ], "compatibilityRules": [ { "from": "string", "to": "json" }, { "from": "json", "to": "string" } ] } } ``` ## Advanced endpoint formats (Tier 3) These power execution, the interactive playground, and human-in-the-loop interrupts. They use the same `{ "success": true, "data": ... }` envelope as Tier 1–2 unless noted. ### `POST /workflows/:id/execute` Starts a run. The body is optional. **Request:** ```json { "inputs": { "text_input": "Hello" }, "options": { "timeout": 30000, "maxSteps": 50 } } ``` **Response (`202 Accepted`):** ```json { "success": true, "data": { "execution_id": "exec-abc123", "status": "running", "started_at": "2025-01-01T00:00:00Z", "estimated_completion": "2025-01-01T00:00:05Z" } } ``` ### `GET /executions/:id` Poll for execution status using the `execution_id` returned above. **This endpoint returns the status object directly — no `success`/`data` envelope.** It is the one exception to the response wrapper. **Response:** ```json { "status": "completed", "jobs": [], "node_statuses": { "node-1": { "status": "completed" } }, "job_status_summary": {} } ``` `status` is one of `pending`, `running`, `completed`, `failed`, `cancelled`, `paused`, `interrupted`. The playground's `isTerminalStatus` and `shouldStopPolling` callbacks key off these values. ### `POST /workflows/:id/playground/sessions` Create an isolated test session for a workflow. The body is optional. **Request:** ```json { "name": "Test Session 1" } ``` **Response (`201`):** ```json { "success": true, "data": { "id": "sess-abc123", "workflowId": "wf-abc123", "name": "Test Session 1", "status": "idle", "createdAt": "2025-01-01T00:00:00Z", "updatedAt": "2025-01-01T00:00:00Z" } } ``` `status` is one of `idle`, `running`, `awaiting_input`, `completed`, `failed`. ### `POST /playground/sessions/:sid/messages` Send a user message — this triggers a run. The message is created with status `pending` and processed asynchronously; poll the messages endpoint to track it. **Request:** ```json { "content": "Process this file", "inputs": { "file_path": "/data/input.csv" } } ``` **Response (`200`):** ```json { "success": true, "data": { "id": "msg-1", "sessionId": "sess-abc123", "role": "user", "content": "Process this file", "status": "pending", "sequenceNumber": 1, "timestamp": "2025-01-01T00:00:00Z" } } ``` Returns `409` if the previous message in the session is still processing — messages are handled in sequence. ### `GET /playground/sessions/:sid/messages` Poll for new messages. Supports `since`, `latest`, and `before` query parameters for pagination. **Response:** ```json { "success": true, "data": [ { "id": "msg-2", "sessionId": "sess-abc123", "role": "assistant", "content": "Done — processed 42 rows.", "status": "completed", "sequenceNumber": 2, "timestamp": "2025-01-01T00:00:03Z" } ], "hasMore": false, "sessionStatus": "completed" } ``` `role` is `user`, `assistant`, `system`, or `log`. `sessionStatus` tells the poller when to stop. ### `GET /interrupts/:id` Fetch a pending human-in-the-loop interrupt. **Response:** ```json { "success": true, "data": { "id": "int-abc123", "type": "confirmation", "status": "pending", "nodeId": "node-3", "executionId": "exec-abc123", "allowCancel": true, "config": { "message": "Do you approve this action?", "confirm_label": "Approve", "cancel_label": "Reject" }, "createdAt": "2025-01-01T00:00:00Z" } } ``` `type` is `confirmation`, `choice`, `text`, `form`, or `review`; `status` is `pending`, `resolved`, or `cancelled`. ### `POST /interrupts/:id` Resolve an interrupt by submitting the user's response. The `value` type depends on the interrupt `type`. **Request:** ```json { "value": true } ``` | Interrupt `type` | `value` shape | | ---------------- | ----------------------------------- | | `confirmation` | `boolean` | | `choice` | `string` or `string[]` | | `text` | `string` | | `form` | `object` matching the form schema | | `review` | decisions map + summary | **Response:** the updated interrupt (same shape as `GET /interrupts/:id`, now with `status: "resolved"`). ### `GET /system/config` Public runtime configuration the editor reads on mount. **Response:** ```json { "success": true, "data": { "version": "1.0.0", "features": { "playground": true, "interrupts": true }, "limits": { "maxWorkflowNodes": 100, "maxConcurrentExecutions": 5 } } } ``` ## CORS Configuration FlowDrop runs in the browser, so your backend must allow cross-origin requests if served from a different domain: ```typescript // Express example import cors from 'cors'; app.use( cors({ origin: 'http://localhost:5173', // your frontend URL methods: ['GET', 'POST', 'PUT', 'DELETE'], allowedHeaders: ['Content-Type', 'Authorization'] }) ); ``` ## Error Response Format When an operation fails, return a consistent error format: ```json { "success": false, "error": "Workflow not found", "code": "NOT_FOUND", "message": "No workflow exists with ID 'wf-xyz'" } ``` FlowDrop's API client expects standard HTTP status codes: - `200` — success - `201` — created - `400` — bad request (validation error) - `401` — unauthorized (triggers `onApiError` and auth provider's `onUnauthorized`) - `404` — not found - `500` — server error ## Static vs. Dynamic Node Serving For simple use cases, you can serve node metadata as **static JSON**: ```typescript // nodes.json — serve as a static file const nodes = [ { id: 'text_input', name: 'Text Input', ... }, { id: 'http_request', name: 'HTTP Request', ... } ]; app.get('/api/flowdrop/nodes', (req, res) => { res.json({ success: true, data: nodes }); }); ``` For dynamic use cases, load from a database: ```typescript app.get('/api/flowdrop/nodes', async (req, res) => { const nodes = await db .collection('nodes') .find({ ...(req.query.category && { category: req.query.category }) }) .toArray(); res.json({ success: true, data: nodes }); }); ``` ## Verify your backend (conformance checklist) FlowDrop exercises your API in a predictable order on mount. Run these requests against your base URL to confirm the contract **before** wiring up the editor — they mirror exactly what the editor does. Replace the `BASE` value with your own. ```bash BASE=http://localhost:3001/api/flowdrop # 1. Health — FlowDrop checks this first on mount curl -s $BASE/health # 2. Nodes — populates the sidebar curl -s $BASE/nodes # 3. Categories — sidebar groups curl -s $BASE/categories # 4. Port config — connection compatibility rules curl -s $BASE/port-config # 5. Create a workflow (note the returned id) curl -s -X POST $BASE/workflows \ -H 'Content-Type: application/json' \ -d '{"name":"Smoke test","nodes":[],"edges":[]}' # 6. Load it back (use the id from step 5) curl -s $BASE/workflows/ # 7. Update it curl -s -X PUT $BASE/workflows/ \ -H 'Content-Type: application/json' \ -d '{"name":"Smoke test (edited)","nodes":[],"edges":[]}' ``` Your backend conforms when: - [ ] `GET /health` returns `200` with `{ "status": "ok" }` - [ ] Every response uses the `{ "success": true, "data": ... }` envelope (the one exception is `GET /executions/:id`) - [ ] `GET /nodes` data items include at least `id`, `name`, `type`, and `category` - [ ] Workflow `metadata` uses the exact field names `schemaVersion`, `createdAt`, `updatedAt` (not `created_at` / `updated_at`) - [ ] `POST /workflows` returns `201` and echoes a server-assigned `id` - [ ] Errors return the correct HTTP status (`404` missing, `401` unauthorized) with `{ "success": false, "error": ... }` - [ ] CORS allows your frontend origin if the backend runs on a different domain If all seven calls succeed and the checklist passes, mounting the editor against this base URL will load nodes into the sidebar and let you create, edit, and save workflows. ## Next Steps - [Backend: Express.js](/tutorials/recipes/backend-express) — get a working backend in 15 minutes - [Framework Integration](/editor/frameworks) — connect FlowDrop to your backend - [API Overview](/editor/reference/api-overview) — complete module and endpoint reference - [OpenAPI Specification](/api) — full API contract