Triggers
A trigger is the node that starts a run. Flowdrome ships eight:
| Trigger | Starts a run when… |
|---|---|
| HTTP Trigger | a request hits the workflow’s webhook path (method, path and content type are configurable) |
| Telegram Trigger | the bot receives an update — long-polling (no public URL needed) or webhook mode |
| WebSocket Trigger | a message arrives on the workflow’s WebSocket endpoint |
| Schedule | a 5-field cron expression or fixed interval fires (IANA timezone aware) |
| File Event | a watched path sees a file created/changed/deleted |
| Receive Message | a message lands on an internal queue (paired with Send Message) |
| Inject | you press the button — a test fixture with a configurable payload |
| Manual | the app is invoked as a run-once job |
| Error Trigger | another run in the workflow fails — it starts the recovery lane |
The production trigger model
The same workflow behaves differently in the editor and in a deployed app — deliberately:
- Inject is an inert test fixture. It exists to hand the graph a payload while you build. In a compiled, deployed app it never fires — it is dead weight by design, so you can leave your test scaffolding in the document.
- Manual is the run-once entry. A deployed app started in job mode executes once from the Manual trigger and exits — cron-from-the-outside, CI steps, batch jobs.
- Real triggers serve. In serve mode the deployed app binds its HTTP/WebSocket endpoints, starts its schedules, polls Telegram, watches files — continuously, with its own status server, run history and health endpoint.
This means “promote to production” is not a rewrite: you test with Inject next to the real trigger, deploy, and the real trigger takes over.
Responding to HTTP early
By default an HTTP-triggered run answers the caller when the run finishes. The HTTP Response node flips that: the first one executed answers the caller mid-flow (status, headers, body) and the run continues — acknowledge in milliseconds, keep working for minutes. An approval gate downstream can then hold the rest of the flow for a human without holding the caller.
Webhook security
The HTTP trigger validates content types and supports signed-webhook patterns (see the crypto node’s HMAC + timing-safe compare for verifying signatures like a payment provider’s). Outbound HTTP from workflows passes an SSRF guard.