HTTP Trigger

Serves HTTP endpoints and starts the workflow with the request. One method+path by default — or add ROUTES (GET /users/{id} → its own output port) to serve a whole API from one trigger, with pathParams extracted and anything unclaimed leaving on the unmatched port.

Finding it in the library

Search the builder's node library for HTTP Trigger (it lives under Input). A single click opens the in-editor docs panel shown here — description, ports, and every property, without leaving the canvas. Double-click (or drag) to add it to the workflow.

Library capture pending — regenerate with npm run shots:nodes.

Wired up in the builder

HTTP Trigger in a real, runnable flow — captured live from the Studio editor, exactly as it looks on your canvas. This is the same workflow used for the example input & output below.

Canvas capture pending — regenerate with npm run shots:nodes.

How it’s configured

The node’s Configure panel as it opens in the builder when you select the step — every setting laid out with real values. Click any field to edit it.

Config capture pending — regenerate with npm run shots:nodes. See the full property reference below.

Ports

This is a trigger — it starts runs and takes no input wire.

Ports are the node’s contract with its neighbours. In the editor a port label renders bold when wired and italic when optional; ◈ ports accept attachment carriers rather than data wires.

How data flows through it

As a trigger, HTTP Trigger starts runs — it takes no input wire. What it emits is the request wrapper: the event’s body becomes the payload, and the wrapper carries the event metadata around it (for an HTTP-style trigger that’s headers.*, request.method, request.path and query). Downstream nodes consume the content — the wrapper is unwrapped at each node boundary, and expression roots like {{ headers.x }} still resolve against the wrapper when you need the metadata. See Runs & run data for the envelope model.

Expressions in the config

String-typed properties accept {{ }} expressions evaluated against the incoming item at run time — e.g. {{ $json.customer.email }}. On this node that’s path, specPath, authUser, authPassword, authHeaderName, authHeaderValue, authToken, jwtSecret, jwtPublicKey, ipAllowlist. JSON- and code-typed fields never interpolate — they are passed through literally.

Build it with AI

Every node in this reference is reachable through Flowdrome’s AI Copilot and the MCP tools — say what you want, and the graph surgery happens server-side. Node types resolve fuzzily, so the catalog label (HTTP Trigger) works as well as the exact type id (input.http.webhook).

In the Copilot panel (or any connected AI):

create a workflow that starts with http trigger and logs the result

As a step in a create_chain_workflow call:

{"type":"HTTP Trigger","config":{}}

curl -s -X POST http://localhost:48170/mcp -H "content-type: application/json" -d '{ "jsonrpc": "2.0", "id": "1", "method": "tools/call", "params": { "name": "add_node", "arguments": { "workflowId": "<id>", "type": "HTTP Trigger" } } }'

Example input & output

Captured from a real test run of the workflow above — this is what you see in the run data panel after pressing Test workflow.

{
  "body": {
    "x": 1
  }
}

{
  "body": {
    "x": 1
  }
}

Property reference

Every setting, with its type and default — the same fields shown configured in the panel above.

Using it

One endpoint (the default)

Leave Routes empty and the trigger is a classic webhook: one HTTP method + Path (POST /webhook/new), the parsed body arriving as $json, the request metadata riding the envelope (request.method, request.path, headers.*, query). Wire output into your flow and answer with an HTTP Response node — or let the run’s final output answer 200 with zero ceremony.

A whole API from one trigger

Add rows to Routes and the trigger becomes a multi-endpoint front door — each route is its own output port:

Leave the Output port blank and it’s auto-named from the method + path (GET /users/{id} → get_users_id) — a route gets its own output handle the moment you add it; name it only when you want a specific one.

Routes are checked top to bottom — first match wins. Template parameters land on the payload as pathParams ({{ $json.pathParams.orderId }}), the request body’s own fields stay on $json, and the envelope (headers, query, request metadata) survives the hop so a downstream Check can still read headers.authorization.

Anything no route claims leaves on the fixed unmatched port — wire your 404 branch there. When a known path was hit with the wrong verb, $json.methodMismatch is true, so an If on the unmatched lane splits a real-API 405 from the plain 404. This is exactly the shape the mock API wizard generates.

Securing it

Authentication gates every endpoint of the trigger before any routing: Basic, Bearer, custom header, or JWT. A request that fails auth leaves on the optional unauthorized port with the failure detail — wire it to a 401 response so the workflow (not the ingress) decides the answer. Ingress guards (body cap, per-IP rate limit) apply per trigger.

Publish an OpenAPI spec

Turn on Publish OpenAPI spec and the trigger serves a generated OpenAPI 3.0 document — built from its own routes — at the Spec path (default /openapi.json, GET). Callers (and Flowdrome’s own OpenAPI node) can discover every endpoint the trigger exposes without you hand-writing a spec. A real route always wins over the spec path, so it never shadows your API.

Tips

• Test without serving: the trigger tester (▶ on the node) pre-fills a wrapped request — edit request.method / request.path to drive a different route, or an unknown path to exercise the unmatched lane.
• Routed triggers register every verb for their path templates at the serve layer; the wrong verb still reaches the workflow so your 405 branch answers — like a real API, and unlike a hard ingress rejection.
• The Method/Path fields are ignored once Routes exist (the editor hides them) — routes are absolute path templates.
• Leave a route’s Output port blank to auto-name it from the method + path; set one only when you want a specific handle (keep it short — getOrder, not get order by id — v2).
• The retired Router node did this as a separate hop; existing workflows that still contain one keep running, but new graphs should put routes on the trigger.

Related nodes

The rest of the Input group — the same folder you’d scan in the editor’s library.

• Telegram Trigger Starts the workflow for every Telegram bot update — long-polls getUpdates (default) or serves a secret-token-v
• WhatsApp Trigger Starts the workflow when a WhatsApp message arrives (Meta Cloud API webhook)
• Slack Trigger Starts the workflow when a Slack event arrives (Events API)
• Discord Trigger Starts the workflow when a Discord message arrives — via the Gateway WebSocket (real-time messages) or an inte
• WebSocket Trigger Accepts a persistent WebSocket connection; each inbound message starts the workflow, and data sent to its feed
• Inject Injects static manual test payloads as workflow input.
• Manual Trigger Starts the workflow when run manually, passing your run/test data forward (empty item by default).
• Schedule Fires on a cron schedule or fixed interval, emitting a tick with the fire time.

This page is generated from the node registry by gen-node-docs.mjs on every site build — ports, properties, defaults and visibility rules cannot drift from the code. The screenshots and example data are captured from a live Flowdrome by npm run shots:nodes and npm run gen:examples. The hand-authored notes above are merged in.