mirror of
https://github.com/langflow-ai/langflow.git
synced 2026-07-24 06:10:49 +08:00
* docs: migrate code blocks from CodeSnippet to native Prism Replace the custom CodeSnippet component (@code-hike/lighter) with Docusaurus's native @theme/CodeBlock across all MDX files (current and versioned docs). Add bash to additionalLanguages and swizzle prism-include-languages.js to add custom token highlighting for shell commands and flags. Remove @code-hike/mdx dependency. * docs: improve inline code styling Darken inline code background, increase horizontal padding to 0.4em, fix vertical alignment, and remove border in light mode. * docs: address PR review — fix code slice regression and CSS/regex polish - Inline RecursiveCharacterTextSplitter inputs and methods as literal code blocks in concepts-components.mdx (current + 1.8.0 + 1.9.0), restoring the focused slices lost when migrating from CodeSnippet - Scope bash-plain Prism regex to unambiguous CLI subcommands only, removing generic bash builtins (run, add, get, set, start, stop, etc.) - Merge duplicate .theme-code-block CSS rules into a single declaration * fix(docs): prevent horizontal scroll on API docs pages The Redoc two-column layout (sidebar 300px + api-content 1300px) totals 1600px, expanding .main-wrapper beyond narrower viewports because it has overflow:visible. Clips at .main-wrapper using the html.plugin-redoc class that Docusaurus adds on API pages only. * fix(docs): API docs sidebar and layout fixes - Disable Redoc built-in search (disableSearch: true) - Pin sidebar top to navbar height (top: 60px) so it never hides behind navbar - Remove hardcoded #111 background from dark mode sidebar * fix(docs): render markdown correctly in API docs descriptions The _clean_descriptions function was converting newlines to <br> tags, mixing HTML with Markdown. CommonMark stops parsing Markdown headings (###) inside HTML blocks, causing them to appear as literal text in Redoc. Replace the <br> conversion with a simple strip() so descriptions remain pure Markdown and Redoc renders headings, lists, and code blocks correctly. * feat(docs): align API docs colors with Langflow brand - Set primaryColor to #F471B5 (Langflow pink) - Add HTTP method badge colors matching Langflow palette - Set schema.linesColor and requireLabelColor to brand pink - Set inline code color to pink, headers to #e3e3e3 - Set sidebar background to #18181b (matches frontend dark bg) - Set rightPanel background to #0d0d0f, codeBlock to #161618 - Refactor: move color config from CSS to theme.theme where safe - Remove dead search input CSS (search disabled via disableSearch:true) - Consolidate duplicate .menu-content rules * wip(docs): API docs styling — colors, components, light/dark themes * fix(docs): fix Response samples h3 title padding and refactor HTTP method button CSS * feat(docs): add sidebar dark background, active item styles, and right panel color adjustments * fix(docs): add sidebar borders and remove operation divider border * fix(docs): fix expanded response background and align dark/light theme colors * refactor(docs): standardize selectors, comments and remove duplicate rules in redocusaurus.css * refactor(docs): apply PR review — CSS custom properties, version pin, dom version comments, fix overflow * fix(docs): fix Redocly badge visibility covered by sidebar background * fix(docs): extend sidebar border-right to Redocly badge area * refactor(docs): replace hardcoded #ffffff label color with --redoc-text-label variable * fix(docs): lighten inline code background in API docs dark theme Redoc's default typography.code.backgroundColor (rgba(38, 50, 56, 0.05)) is nearly invisible over the dark background. Override it with rgba(255, 255, 255, 0.05) in dark theme only, excluding pre > code so code sample blocks stay unaffected. * feat(docs): align docs primary pink with API spec brand color Use #f471b5 (API spec primaryColor) as --ifm-color-primary in dark theme and #e44fa0 (slightly darkened for contrast on white) in light theme. Remove dark-theme pink overrides in sidebar.css (#ff6ad0 CTA and hsla(329, 55%, 68%) active TOC link) — they compensated for the old muted pink and are redundant now that the primary itself is bright. * feat(docs): lighten dark theme text colors for better readability Bump body text (#a8a8b0 -> #bcbcc4), headings (#cdcdd4 -> #dcdce2) and sidebar menu (#8a8a92 -> #9c9ca4) one step brighter. * chore(docs): add IBM Equal Access accessibility-checker setup Add accessibility-checker as devDependency with aceconfig.js (policy IBM_Accessibility, JSON reports in docs/a11y-results/, gitignored). Scan with: npx achecker <url> against a built docs site. * fix(docs): WCAG AA contrast and ARIA fixes across docs and API reference Validated with IBM Equal Access scans (light theme): home, quickstart and component pages at 0 violations; /api from 3382 down to 167 (all remaining are Redoc-internal DOM: schema table headers, svg/select labels). Docs site: - Light primary pink #d11074 — passes 4.5:1 on white and inline-code bg - Light Prism palette darkened per-token to pass 4.5:1 on #f9f9fd - TabItem swizzled to give tabpanels an accessible name (aria-label) - codeBlockA11y client module: scrollable code blocks get role=region + unique label; non-scrollable ones lose the needless tabindex API reference (Redocusaurus): - redocA11y client module: role=main on api-content, role=navigation on sidebar — fixes 1924 aria_content_in_landmark violations - HTTP method badges and response chips darkened to pass with white text - Light-theme overrides: accessible pink #cd1072 for links, required markers, constraint chips, schema tree lines; darker grays for utility buttons and type labels (incl. 0.7-opacity wrapper fix) - Sidebar active/hover items use regular text color, method badges keep their own colors; expandable property names match non-expandable ones * fix(docs): WCAG AA contrast fixes for dark theme Validated with IBM Equal Access scans in dark mode (temporary colorMode.defaultMode flip during scanning): home, quickstart and component pages at 0 violations; /api matches light at 167 remaining (all Redoc-internal DOM: table headers, svg/select labels). - Code block comments/line numbers #4a5060 -> #798197 (4.56:1 on #18181a) - Redoc dark sample tokens: boolean/null #e95c59, number #5392b8 - Status-code tabs: lift docusaurus-theme-redoc's #303846 !important selected-tab rule with a higher-specificity override - oneOf variant buttons: dark text in both themes (their white/pink backgrounds are theme-independent) - redocA11y client module: patch response chip colors (success green / error red) to dark-accessible variants when data-theme=dark — a single Redoc theme color cannot pass on both light and dark derived backgrounds, and status is only distinguishable by computed color * fix(docs): resolve remaining Redoc-internal accessibility violations Extend the redocA11y client module with semantic patches for Redoc DOM the theme cannot reach (validated: 0 IBM Equal Access violations on all scanned pages in both light and dark themes): - Decorative svg chevrons/arrows: aria-hidden=true (svg_graphics_labelled) - Content-type dropdowns: aria-label (input_label_exists) - Schema field tables (2-col name|description layout, no <th> anywhere): role=presentation — content reads in DOM order; role=rowheader on <td> is invalid ARIA inside a native table (table_headers_exists/related) - Semantic patches run on the next animation frame after DOM changes so Redoc's lazy-rendered operations are covered immediately; the heavier color patch stays debounced * ci(docs): gate docs accessibility with IBM Equal Access scans Add test-docs-accessibility job to docs_test.yml (rides the existing docs/** path filter from ci.yml): build + scan 4 representative pages (home, quickstart, component page, /api) in light theme, then flip colorMode.defaultMode to dark, rebuild and scan again. - scripts/a11y-ci.sh: serves the build and runs npx achecker per page with one retry to absorb Redoc lazy-render timing flakes; any real violation fails the job (failLevels: violation) - aceconfig.js: pin ruleArchive to 19May2026 so IBM rule updates don't break CI without a deliberate bump * ci(docs): fix Chrome sandbox launch on Ubuntu 24.04 runners Ubuntu 24.04 restricts unprivileged user namespaces via AppArmor, which prevents puppeteer's Chrome (used by the IBM checker) from starting its sandbox. Re-enable them with the documented sysctl workaround instead of weakening the browser with --no-sandbox. * fix(docs): align response status code with description text Redoc sets vertical-align: top and a smaller line-height on the status code <strong> inside response buttons, leaving "200" visually higher than "Successful Response". Align both to the shared text baseline. * refactor(docs): apply PR review feedback - redocA11y: match only real Redoc routes (/api, /api/workflow) — a bare startsWith("/api") also matched docs pages like /api-request and leaked one body MutationObserver per navigation - codeBlockA11y: also observe the hidden attribute — Docusaurus tabs toggle panels via hidden (no childList mutation), so scrollable blocks inside an initially hidden tab were never re-evaluated for tabindex - Extract Prism themes to src/prismThemes.js (docusaurus.config.js was past the 600-line red flag) - concepts-components.mdx (current + 1.9.0 + 1.8.0): comment pointing hardcoded snippets to recursive_character.py to mitigate drift Validated: clean build + IBM Equal Access scans 4/4 passing. * replace-openapi-file-with-1.10 * migrate-prism-changes-to-1.10-version * a11y-script-dont-block --------- Co-authored-by: Mendon Kissling <59585235+mendonk@users.noreply.github.com>
366 lines
13 KiB
Plaintext
366 lines
13 KiB
Plaintext
---
|
|
title: Workflow API (Beta)
|
|
slug: /workflow-api
|
|
---
|
|
import CodeBlock from '@theme/CodeBlock';
|
|
import exampleWorkflowsApiExampleSynchronousRequest from '!!raw-loader!@site/docs/API-Reference/curl-examples/workflows-api/example-synchronous-request.sh';
|
|
import exampleWorkflowsApiExampleAsynchronousRequest from '!!raw-loader!@site/docs/API-Reference/curl-examples/workflows-api/example-asynchronous-request.sh';
|
|
import exampleWorkflowsApiExampleRequest from '!!raw-loader!@site/docs/API-Reference/curl-examples/workflows-api/example-request.sh';
|
|
import exampleWorkflowsApiExampleRequest2 from '!!raw-loader!@site/docs/API-Reference/curl-examples/workflows-api/example-request-2.sh';
|
|
import examplePythonWorkflowsApiExampleSynchronousRequest from '!!raw-loader!@site/docs/API-Reference/python-examples/workflows-api/example-synchronous-request.py';
|
|
import examplePythonWorkflowsApiExampleAsynchronousRequest from '!!raw-loader!@site/docs/API-Reference/python-examples/workflows-api/example-asynchronous-request.py';
|
|
import examplePythonWorkflowsApiExampleRequest from '!!raw-loader!@site/docs/API-Reference/python-examples/workflows-api/example-request.py';
|
|
import examplePythonWorkflowsApiExampleRequest2 from '!!raw-loader!@site/docs/API-Reference/python-examples/workflows-api/example-request-2.py';
|
|
import exampleJavascriptWorkflowsApiExampleSynchronousRequest from '!!raw-loader!@site/docs/API-Reference/javascript-examples/workflows-api/example-synchronous-request.js';
|
|
import exampleJavascriptWorkflowsApiExampleAsynchronousRequest from '!!raw-loader!@site/docs/API-Reference/javascript-examples/workflows-api/example-asynchronous-request.js';
|
|
import exampleJavascriptWorkflowsApiExampleRequest from '!!raw-loader!@site/docs/API-Reference/javascript-examples/workflows-api/example-request.js';
|
|
import exampleJavascriptWorkflowsApiExampleRequest2 from '!!raw-loader!@site/docs/API-Reference/javascript-examples/workflows-api/example-request-2.js';
|
|
|
|
|
|
|
|
|
|
import Tabs from '@theme/Tabs';
|
|
import TabItem from '@theme/TabItem';
|
|
import PartialAPISetup from '@site/docs/_partial-api-setup.mdx';
|
|
|
|
:::warning Beta Feature
|
|
The Workflow API is currently in **Beta**.
|
|
The API endpoints and response formats may change in future releases.
|
|
:::
|
|
|
|
The Workflow API provides programmatic access to execute Langflow workflows synchronously or asynchronously.
|
|
Synchronous requests receive complete results immediately upon completion.
|
|
Asynchronous requests are queued in the background and will run until complete, or a request is issued to the [Stop Workflow endpoint](#stop-workflow-endpoint).
|
|
|
|
The Workflow API is part of the Langflow Developer v2 API and offers enhanced workflow execution capabilities compared to the v1 `/run` endpoint.
|
|
|
|
<PartialAPISetup />
|
|
|
|
## Execute workflows endpoint (synchronous or asynchronous)
|
|
|
|
**Endpoint:**
|
|
|
|
```
|
|
POST /api/v2/workflows
|
|
```
|
|
|
|
**Description:** Execute a workflow synchronously and receive complete results immediately upon completion.
|
|
Set `background=false` to make the request synchronous.
|
|
|
|
### Example synchronous request
|
|
|
|
Execute a workflow synchronously and receive complete results immediately:
|
|
|
|
<Tabs>
|
|
<TabItem value="Python" label="Python" default>
|
|
|
|
<CodeBlock language="python">{examplePythonWorkflowsApiExampleSynchronousRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
<TabItem value="JavaScript" label="JavaScript">
|
|
|
|
<CodeBlock language="javascript">{exampleJavascriptWorkflowsApiExampleSynchronousRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
<TabItem value="curl" label="curl">
|
|
|
|
<CodeBlock language="bash">{exampleWorkflowsApiExampleSynchronousRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
</Tabs>
|
|
|
|
### Example asynchronous request
|
|
|
|
For long-running workflows, set `background=true` to get a `job_id` immediately, and then poll the status [using the GET endpoint](#get-workflow-status-endpoint) until the job is complete.
|
|
|
|
To stop a job, send a POST request to the [Stop workflow endpoint](#stop-workflow-endpoint).
|
|
|
|
:::tip
|
|
The asynchronous request contains `stream` parameter, but streaming is not yet supported. The parameter is included for future compatibility.
|
|
:::
|
|
|
|
**Example request:**
|
|
|
|
<Tabs>
|
|
<TabItem value="Python" label="Python" default>
|
|
|
|
<CodeBlock language="python">{examplePythonWorkflowsApiExampleAsynchronousRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
<TabItem value="JavaScript" label="JavaScript">
|
|
|
|
<CodeBlock language="javascript">{exampleJavascriptWorkflowsApiExampleAsynchronousRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
<TabItem value="curl" label="curl">
|
|
|
|
<CodeBlock language="bash">{exampleWorkflowsApiExampleAsynchronousRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
</Tabs>
|
|
|
|
**Response:**
|
|
|
|
```json
|
|
{
|
|
"job_id": "job_id_1234567890",
|
|
"created_timestamp": "2025-01-15T10:30:00Z",
|
|
"status": "queued",
|
|
"errors": []
|
|
}
|
|
```
|
|
|
|
### Request body
|
|
|
|
| Field | Type | Required | Default | Description |
|
|
|-------|------|----------|---------|-------------|
|
|
| `flow_id` | `string` | Yes | - | The ID or endpoint name of the flow to execute. |
|
|
| `flow_version` | `string` | No | - | Optional version hash to pin to a specific flow version. |
|
|
| `background` | `boolean` | No | `false` | Must be `false` for synchronous execution. |
|
|
| `inputs` | `object` | No | `{}` | Inputs for the workflow execution. Uses component identifiers with dot notation (e.g., `ChatInput-abc.input_value`). See [Component identifiers and input structure](#component-identifiers-and-input-structure) for detailed information. |
|
|
| `globals` | `object` | No | `{}` | Request-level global variables available to workflow components. Use this body field for arbitrary strings, including Unicode values. Keys are limited to 256 characters and values to 64 KB. See [Migrating from `X-LANGFLOW-GLOBAL-VAR-*` headers](#migrating-from-x-langflow-global-var--headers). |
|
|
|
|
### Example response
|
|
|
|
```json
|
|
{
|
|
"flow_id": "flow_67ccd2be17f0819081ff3bb2cf6508e60bb6a6b452d3795b",
|
|
"job_id": "job_id_1234567890",
|
|
"object": "response",
|
|
"created_at": 1741476542,
|
|
"status": "completed",
|
|
"errors": [],
|
|
"inputs": {
|
|
"ChatInput-abc.input_type": "chat",
|
|
"ChatInput-abc.input_value": "what is 2+2",
|
|
"ChatInput-abc.session_id": "session-123"
|
|
},
|
|
"globals": {
|
|
"FILENAME": "relatório—final.pdf",
|
|
"OWNER_NAME": "José"
|
|
},
|
|
"outputs": {
|
|
"ChatOutput-xyz": {
|
|
"type": "message",
|
|
"component_id": "ChatOutput-xyz",
|
|
"status": "completed",
|
|
"content": "2 + 2 equals 4."
|
|
}
|
|
},
|
|
"metadata": {}
|
|
}
|
|
```
|
|
|
|
### Response body
|
|
|
|
The response includes an `outputs` field containing component-level results. Each output has a `type` field indicating the type of content:
|
|
|
|
| Type | Description | Example |
|
|
|------|-------------|---------|
|
|
| `message` | Text message content. | Chat responses, summaries |
|
|
| `image` | Image URL or data. | Generated images, processed images |
|
|
| `sql` | SQL query results. | Database query outputs |
|
|
| `data` | Structured data. | JSON objects, arrays |
|
|
| `file` | File reference. | Generated documents, reports |
|
|
|
|
## Get workflow status endpoint
|
|
|
|
**Endpoint:** `GET /api/v2/workflows`
|
|
|
|
**Description:** Retrieve the status and results of a workflow execution by job ID.
|
|
|
|
### Example request
|
|
|
|
<Tabs>
|
|
<TabItem value="Python" label="Python" default>
|
|
|
|
<CodeBlock language="python">{examplePythonWorkflowsApiExampleRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
<TabItem value="JavaScript" label="JavaScript">
|
|
|
|
<CodeBlock language="javascript">{exampleJavascriptWorkflowsApiExampleRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
<TabItem value="curl" label="curl">
|
|
|
|
<CodeBlock language="bash">{exampleWorkflowsApiExampleRequest}</CodeBlock>
|
|
|
|
</TabItem>
|
|
</Tabs>
|
|
|
|
### Query parameters
|
|
|
|
| Parameter | Type | Required | Description |
|
|
|-----------|------|----------|-------------|
|
|
| `job_id` | `string` | Yes | The job ID returned from a workflow execution. |
|
|
| `stream` | `boolean` | No | If `true`, returns server-sent events stream. Default: `false`. |
|
|
| `sequence_id` | `integer` | No | Optional sequence ID to resume streaming from a specific point. |
|
|
|
|
### Example response
|
|
|
|
```json
|
|
{
|
|
"flow_id": "flow_67ccd2be17f0819081ff3bb2cf6508e60bb6a6b452d3795b",
|
|
"job_id": "job_id_1234567890",
|
|
"object": "response",
|
|
"created_at": 1741476542,
|
|
"status": "completed",
|
|
"errors": [],
|
|
"outputs": {
|
|
"ChatOutput-xyz": {
|
|
"type": "message",
|
|
"component_id": "ChatOutput-xyz",
|
|
"status": "completed",
|
|
"content": "Processing complete..."
|
|
}
|
|
},
|
|
"input": [
|
|
{
|
|
"type": "text",
|
|
"data": "Input text prompt for the workflow execution",
|
|
"role": "User"
|
|
}
|
|
],
|
|
"metadata": {}
|
|
}
|
|
```
|
|
|
|
### Response body
|
|
|
|
The response includes a `status` field that indicates the current state of the workflow execution:
|
|
|
|
| Status | Description |
|
|
|--------|-------------|
|
|
| `queued` | Job is queued and waiting to start. |
|
|
| `in_progress` | Job is currently executing. |
|
|
| `completed` | Job completed successfully. |
|
|
| `failed` | Job failed during execution. |
|
|
| `error` | Job encountered an error. |
|
|
|
|
## Stop workflow endpoint
|
|
|
|
**Endpoint:** `POST /api/v2/workflows/stop`
|
|
|
|
**Description:** Stop a running workflow execution by job ID.
|
|
|
|
### Example request
|
|
|
|
<Tabs>
|
|
<TabItem value="Python" label="Python" default>
|
|
|
|
<CodeBlock language="python">{examplePythonWorkflowsApiExampleRequest2}</CodeBlock>
|
|
|
|
</TabItem>
|
|
<TabItem value="JavaScript" label="JavaScript">
|
|
|
|
<CodeBlock language="javascript">{exampleJavascriptWorkflowsApiExampleRequest2}</CodeBlock>
|
|
|
|
</TabItem>
|
|
<TabItem value="curl" label="curl">
|
|
|
|
<CodeBlock language="bash">{exampleWorkflowsApiExampleRequest2}</CodeBlock>
|
|
|
|
</TabItem>
|
|
</Tabs>
|
|
|
|
### Request body
|
|
|
|
| Field | Type | Required | Default | Description |
|
|
|-------|------|----------|---------|-------------|
|
|
| `job_id` | `string` | Yes | - | The job ID of the workflow to stop. |
|
|
|
|
### Example response
|
|
|
|
```json
|
|
{
|
|
"job_id": "job_id_1234567890",
|
|
"message": "Job job_id_1234567890 cancelled successfully."
|
|
}
|
|
```
|
|
|
|
## Migrating from `X-LANGFLOW-GLOBAL-VAR-*` headers
|
|
|
|
Earlier preview releases of the Workflow API accepted request-level global variables via `X-LANGFLOW-GLOBAL-VAR-*` HTTP headers. HTTP headers cannot reliably carry arbitrary Unicode values, so the v2 Workflow API now accepts globals as a typed `globals` field in the JSON request body.
|
|
|
|
For backwards compatibility, the previous header transport is still honored for one release:
|
|
|
|
- Body globals always win when the same key is sent both ways.
|
|
- A deprecation warning is logged on every request that carries `X-LANGFLOW-GLOBAL-VAR-*` headers.
|
|
- Header-based globals will be **removed in a future Langflow release**. Migrate to the `globals` body field at your earliest convenience.
|
|
|
|
**Before (deprecated):**
|
|
|
|
```bash
|
|
curl -X POST "$LANGFLOW_URL/api/v2/workflows" \
|
|
-H "x-api-key: $LANGFLOW_API_KEY" \
|
|
-H "Content-Type: application/json" \
|
|
-H "X-LANGFLOW-GLOBAL-VAR-FILENAME: relatorio-final.pdf" \
|
|
-H "X-LANGFLOW-GLOBAL-VAR-OWNER_NAME: Jose" \
|
|
--data '{"flow_id": "..."}'
|
|
```
|
|
|
|
**After:**
|
|
|
|
```bash
|
|
curl -X POST "$LANGFLOW_URL/api/v2/workflows" \
|
|
-H "x-api-key: $LANGFLOW_API_KEY" \
|
|
-H "Content-Type: application/json" \
|
|
--data '{
|
|
"flow_id": "...",
|
|
"globals": {
|
|
"FILENAME": "relatório—final.pdf",
|
|
"OWNER_NAME": "José"
|
|
}
|
|
}'
|
|
```
|
|
|
|
Keys may use the same characters supported by the global variables panel in the Langflow UI; they are bounded to 256 characters, and values are bounded to 64 KB.
|
|
|
|
## Component identifiers and input structure
|
|
|
|
The Workflows API uses component identifiers with dot notation to specify inputs for individual components in your workflow. This allows you to pass values to specific components and override component parameters.
|
|
|
|
Component identifiers use the format `{component_id}.{parameter_name}`.
|
|
When making requests to the Workflows API, include component identifiers in the `inputs` object.
|
|
For example, this demonstrates targeting multiple components and their parameters in a single request.
|
|
|
|
```json
|
|
{
|
|
"flow_id": "your-flow-id",
|
|
"inputs": {
|
|
"ChatInput-abc.input_type": "chat",
|
|
"ChatInput-abc.input_value": "what is 2+2",
|
|
"ChatInput-abc.session_id": "session-123",
|
|
"OpenSearchComponent-xyz.opensearch_url": "https://opensearch:9200",
|
|
"LLMComponent-123.temperature": 0.7,
|
|
"LLMComponent-123.max_tokens": 100
|
|
}
|
|
}
|
|
```
|
|
|
|
To find the component ID in the Langflow UI, open your flow in Langflow, click the component, and then click **Controls**. The component ID is at the top of the **Controls** pane.
|
|
|
|
You can override any component's parameters.
|
|
|
|
## Error handling
|
|
|
|
The API uses standard HTTP status codes to indicate success or failure:
|
|
|
|
| Status Code | Description |
|
|
|-------------|-------------|
|
|
| `200 OK` | Request successful. |
|
|
| `400 Bad Request` | Invalid request parameters. |
|
|
| `401 Unauthorized` | Invalid or missing API key. |
|
|
| `404 Not Found` | Flow not found or developer API disabled. |
|
|
| `500 Internal Server Error` | Server error during execution. |
|
|
| `501 Not Implemented` | Endpoint not yet implemented. |
|
|
|
|
### Error response format
|
|
|
|
```json
|
|
{
|
|
"detail": "Error message describing what went wrong"
|
|
}
|
|
```
|