The core objects
Everything in the API revolves around four objects:
A definition is written once and triggered many times. Each trigger creates exactly one batch, and each batch contains one or more executions. See triggers and batches and executions for the full lifecycle.
Request lifecycle
1
You trigger a definition
The API validates your request against the definition — the definition must be
active, and expressions and inputs are checked up front.2
A batch and its executions are recorded
The trigger creates a batch (status
pending, or scheduled if you passed scheduled_at) plus one execution per input set.3
Executions run durably
Each execution walks the definition’s steps in order. Tasks within a step run concurrently, and each task’s execution model controls when it fires — immediately, on a schedule, inside a time window, or on an external signal.
4
Results are tracked per execution
Task outputs feed later steps through expressions. When everything finishes, each execution records its
result or error, and the batch aggregates them into a final status.Durable execution
Executions run on a durable-execution engine: a run’s progress is persisted at every step — a task can sleep for hours inside a business-hours window or wait a day for a webhook signal without holding anything open, and infrastructure interruptions don’t lose your work — the run resumes exactly where it left off. This is what makes long-lived patterns like scheduled, windowed, and signaled tasks safe to build on.Flow definitions
The anatomy of a definition: inputs, variables, steps, and tasks.
Batches and executions
Status lifecycles, fan-out over records, and recurring triggers.
Triggers
The immutable audit anchor: type vs. source, and the read-only surface.
Execution models
Immediate, scheduled, windowed, and signaled tasks.
Build your first flow
Create, activate, and trigger a definition end to end.