Events

Events are automations: when something happens, run a flow. The flow is the same step pipeline custom endpoints use — the difference is what starts it, and that nobody waits for a response.

Triggers

Trigger	Fires when	The flow receives
Form submission	A form receives a (validated) public submission	The submitted fields
Record created / updated / deleted	A record changes via the dashboard or records API	The record's fields plus `schema` and `recordId`
Manual	You press Run now, or call the execute API	Whatever JSON you provide

Form and record triggers can be scoped to one form or one schema, or left to fire for all of them. Record events deliberately do not fire for writes made by a flow's own record steps — automations cannot trigger automations, so there are no chain reactions to reason about.

Building the flow

The editor is the same canvas as endpoints: steps run top to bottom, each step's output lands in the shared context under its output name, and templates reference anything earlier — {{email}} from the trigger, {{steps.lookup.0.plan}} from a step. The full step and template reference lives in the Endpoints guide; everything there applies to events, including conditions (which end a run early) and the transform step.

A typical shape:

Condition — only continue if {{budget}} is greater than 1000
Create record — file the submission as a Lead
Send email — notify sales using a saved template, to set from {{steps.…}} or a fixed address
Webhook — ping Slack or your own service

Two execution rules worth knowing:

A failed step stops the flow, since later steps may depend on its output — except steps marked continue on error, and legacy webhook/email actions from older events, which keep their historical keep-going behaviour.
An automation failure never fails the action that triggered it. A form submission is accepted even if its event errors; the error goes to the log.

Running and debugging

Run now executes the event immediately with an empty (or API-supplied) payload — the fastest way to try a flow.
Log shows every execution: what triggered it, each step's outcome and a preview of its output, so a failure reads as "stopped here, having computed this". Execution logs live in your project database (event_executions) and inherit the sensitivity of whatever payload triggered them.

The API

Events are manageable programmatically (list/create/edit/delete under /api/projects/{project}/events), and any event can be executed with:

POST /api/projects/{project}/events/{event}/execute

with a JSON body as the trigger payload — useful for wiring external systems to a flow without exposing a public endpoint. (When you do want a public, response-returning URL, that's exactly what endpoints are.)