Sign in

v11

latestOpenAPI 3.0.3raw.githubusercontent.com2026-08-023710598.2 KB
Executions

Deliver an approval/external signal to a waiting execution

Resumes a WAITING execution (durable execution). The caller must own the workflow; the signal only counts against an actual pending wait whose kind it matches and which has not timed out. v1 is the external-signal (human approval) flavor — e.g. a Telegram approve/reject for a money-moving step.

post/executions/{id}:signal

Request body

decision'approve' | 'reject' required

The approver's decision.

payloadobject

Optional structured data delivered as the await step's output.

Response

The resumed (terminal or still-waiting) execution.

idstring required

ULID identifier (26-char Crockford base32).

workflowIdstring required

ULID identifier (26-char Crockford base32).

chainIdinteger

Numeric chain ID (e.g. 11155111 for Sepolia, 8453 for Base). On chain-aware trigger/node configs this is required and must be a configured chain; on query/filter params it is optional.

indexinteger

0-based run counter within the workflow.

startAtinteger required
endAtinteger
status'pending' | 'waiting' | 'success' | 'failed' | 'error' required

Outcome of an execution. pending is in-flight; waiting is suspended mid-workflow at an await node, durably parked until a signal arrives (a human approve/reject or an operator-observed chain event) or the wait times out — non-terminal, like pending, but distinguishable so a client can show "awaiting approval"; success is full success; failed is logical failure (e.g., a node returned an error, or a wait timed out); error is a system / infrastructure failure (e.g., RPC unreachable).

errorstring

Example response

{
  "id": "01JG2FE5MDVKBPHEG0PEYSDKAC",
  "workflowId": "01JG2FE5MDVKBPHEG0PEYSDKAC",
  "chainId": 11155111
}