Flow Executions
Every time a published flow runs — triggered by an inbound message, a campaign send, an API call, or a scheduled cron — Orbit records a complete execution trace: which nodes ran, what their inputs and outputs were, how long they took, and any errors raised. Use the Executions API to debug flow logic in production, and forward execution events to your observability stack over webhooks.List recent executions
Response
Pagination is keyset-based: pass
meta.pagination.cursor back as the cursor query parameter to fetch the next page, and stop when has_more is false.
Get a single execution
trigger_data context and a steps array — one entry per node that ran, in execution order:
steps carries a readable name, the originating node_id and node_type so you can correlate against the flow definition, a status (completed, running, failed, skipped, or pending), a duration_ms, and — when the executor recorded them — the step input, output, and a surfaced error message. A pending step has been reached but has not started executing yet; a running step is in progress, which also covers a node parked on a long delay or send-time schedule that will resume automatically. These per-step statuses are narrower than the run-level status values below: a step never reports waiting, completed_with_errors, timeout, or info.
Subscribe to execution events
Orbit does not expose a streaming (SSE) endpoint for executions. Execution lifecycle events are delivered over webhooks — subscribe an endpoint and Orbit will POST each event as the run progresses:
See Webhook Events for the full catalog and Event Payloads for the body shape. To pull current state on demand instead, poll
GET /flows/executions/:id.
Status values
Common errors
Both responses use the standard error envelope —
error.code carries the value above, and meta.request_id echoes the X-Request-Id for support correlation.