Appearance
Triggers overview
A trigger is whatever starts a flow running. FlowRunner gives you three, and every one of them ends up in the same place: your flow's Start node, with some input data attached.
The three ways a flow runs
You never write glue code to connect a trigger to a flow. Each trigger is a doorway that finds the flow's Start node and hands it inputs.
| Trigger | Fires when | Inputs the flow receives |
|---|---|---|
| HTTP request | Something calls the flow's endpoint at /api/run/… | Validated query, body, header, and path values |
| Form submission | A visitor submits one of your published forms | The submitted field values |
| Schedule (cron) | A minute matches the flow's cron expression | None — the flow runs from Start with an empty input |
All three share one engine. Once the Start node has its inputs, the flow runs exactly the same way no matter what opened the door — the same nodes, the same error handling, the same run history.
How the three differ
HTTP is the general case. Every flow is automatically an HTTP endpoint. The Start node decides which method it answers to (GET, POST, …), what inputs are required, and whether a caller must authenticate. This is what you use to build an API, a webhook receiver, or the backend for a custom integration. See HTTP endpoints.
Forms are a friendlier front door. A published form has its own submit endpoint that always stores the submission first, then optionally forwards it to a flow you choose. That store-first design means a form never silently loses data, even if the flow errors. Spam protection and required-field checks are built in. See Form submissions.
Schedules run a flow on a clock. You give a flow a cron expression (in UTC) and the platform fires it once when the minute matches — no request, no inputs, just the flow doing its work. This is how you send a nightly report or poll an external system. See Scheduled (cron).
TIP
Because HTTP and schedule triggers can point at the same flow file, you can build a flow once and both expose it as an endpoint and run it on a timer. Whatever fires it, the run shows up in the same history.
Secrets go alongside triggers
Triggers often need credentials — a bearer token to protect an endpoint, an API key for an outbound call. FlowRunner stores those in a per-workspace, encrypted secrets vault and resolves ${secrets.NAME} at run time, so no password ever lives in a flow's saved configuration.