Appearance
Start & End nodes
Start is where a flow begins — it declares which HTTP method triggers the flow and validates the incoming request into references. End is where a flow finishes — it shapes the HTTP response that goes back to the caller.
Every runnable flow needs exactly one Start (per method) and, to return a shaped response, at least one End. A flow with no Start cannot be triggered; a flow with no End still runs but returns a generic { ok: true, inputs } payload.
Start
Component id: flowrunner/start.
The Start node is handled by the run endpoint before the engine walks the graph. When a request arrives at your flow's URL, FlowRunner:
- Finds the Start node whose
methodmatches the request method — if none matches, the request404s. - Runs the auth check declared in the Start config (see HTTP triggers).
- Validates the request against the Start's input schema, bucketed into path, query, headers, and body.
- Merges the validated values into a single object and seeds it under the Start's namespace.
Config
| Field | Required | Description |
|---|---|---|
method | No (default GET) | The HTTP method that triggers this flow: GET, POST, PUT, PATCH, or DELETE. Matched case-insensitively against the request. |
auth | No | Authentication rule for the endpoint (none, API key, bearer, or basic). See HTTP triggers. |
params | No | Schema for query-string inputs. |
body | No | Schema for the JSON request body (only read for non-GET/HEAD methods). |
headers | No | Schema for request headers (matched case-insensitively). |
path | No | Schema for positional path segments after the flow's base URL. |
NOTE
The request body is only parsed when the method allows a body and the body schema declares at least one property. Extra path segments beyond the declared path params cause a 404.
The Start namespace
Validated inputs land under a namespace derived from the Start node's name, lower-cased and slugified — start by default. Everything from all four buckets is flattened into that one namespace, so a query param email and a body field email both read as start.email.
text
# request: POST /contact?source=web body: { "email": "a@b.com" }
start.source → "web"
start.email → "a@b.com"Ports
Start has a single output. Connections leaving Start are followed regardless of port label, so you don't need to name the port — just wire Start to the first node of your flow.
End
Component id: flowrunner/end.
End is terminal: reaching it stops that branch of the flow, and its config decides the HTTP response. The engine records the End node it reached; the run endpoint then builds the response from statusCode and responseBody.
Config
| Field | Required | Description |
|---|---|---|
statusCode | No (default 200) | The HTTP status to return. Must be in the range 100–599; anything else falls back to 200. |
responseBody | No | A schema describing the JSON body to return. Each property is bound to either a literal value or a reference (variable.field), and the engine composes the object from the flow's refs at run time. |
If responseBody is omitted, the response body is {} with the chosen status. If the flow reaches no End node at all, the endpoint returns { ok: true, inputs } with the request inputs echoed back.
TIP
You can have several End nodes — one per branch — each with its own statusCode. A validation branch might End with 400, a success branch with 200.
Ports
End has no output ports. It is the terminus of a branch.
How they bracket a flow
Example
A POST contact endpoint that validates an email and returns a confirmation:
text
Start (method: POST, body: { email: string, message: string })
→ Set / Email / MongoDB nodes ...
→ End (statusCode: 200, responseBody: { ok: true, received: start.email })