REST API & Webhooks

Start automations with webhook triggers and read step execution history over the REST API. Configure the trigger URL and its automation API key in the Webhook Step’s App drawer, not in a workspace-wide developer settings page.

At a glanceVerified in app · Oct 30, 2026

Use it to: Trigger Live automations via HTTP POST with a correlation ID and poll step-by-step execution records over the REST API
Find it: Webhook Step App drawer → Webhook endpoint and Workflow API key
Limits: GET /api/v1/flows/{flowId}/executions returns up to 500 step records (default 100) · Retained for 30 days by default
Output: JSON array of step execution records with status, result, error, runCount, iterators, start, and end
Instead: Glow MCP (to list, build, validate, and inspect workspace automations programmatically)

Looking for workspace-wide automation management or failure webhooks? This page covers per-automation webhook triggers and execution polling. To list, build, validate, or inspect automations across a workspace, connect via Glow MCP using OAuth 2.1 or a scoped glow_mcp2_… token from Your account → MCP (/app/user/account?tab=mcp). To route workspace-wide failure events to PagerDuty, Slack, or an external SIEM, use an Error Trigger automation.

Triggering an Automation

Automations are started by sending a request to a webhook trigger’s URL.

Add a Webhook trigger

Add a Webhook trigger and switch the automation to Live. Confirm trigger readiness, then use Copy webhook URL under Webhook endpoint. The URL can be allocated in Draft, but the setup panel displays it only in Live mode. Running saved test data does not verify network delivery.

Send your payload

POST your JSON to that URL.

Add a correlation ID

Send the x-glow-correlation-id HTTP header with a unique ID for this intended delivery, such as a UUID. Use the same header to look up the run afterwards. Keep an order or customer ID in a separate business-data field if it may appear in multiple deliveries.

Existing clients can also pass the ID in the JSON body’s headers["x-glow-correlation-id"] field. On the native Webhook endpoint, the HTTP header takes precedence. A body-level headers object remains part of the payload; the transport header is not added to your business data.


curl -X POST https://<your-webhook-url> \
  -H "Content-Type: application/json" \
  -H "x-glow-correlation-id: ebc32db7-bab9-4aaa-bdb6-d201759c39ad" \
  -d '{
    "customer_email": "[email protected]",
    "total": 129.00
  }'

A correlation ID is not an idempotency key. Each accepted POST can start a separate run, even if another submission used the same ID. Use a distinct UUID for each delivery so every execution maps to a unique correlation ID. If a request times out, check execution history and any external side effects before resending. A new ID does not make a retry safe, and an empty lookup is not proof that the first request was rejected. Design duplicate protection around the business operation.

The webhook acknowledges receipt for asynchronous processing. With default settings, an active generic Webhook returns 200 with {"success": true}, while draft or paused endpoints return 202 without starting a run. See webhook responses for custom response codes and retry guidance.

The HTTP request can still fail or time out before you receive a response. Use test destinations before sending this request: a Live automation can perform real actions.

Reading execution history

Once a run is underway, the REST API returns its step-by-step history: a list with one record per step execution.


GET /api/v1/flows/{flowId}/executions

flowId is the automation ID from its canvas URL, after /workflows/. Run records follow the workspace retention policy, which is 30 days by default. Read or forward what you need while the record is available; see System Limits.

Each record carries the Step’s output under result, its status (pass, error, or ignored), runCount (1 for the first attempt, 2 for the first retry), iterators for loop passes, and start / end timestamps:


[
  {
    "elementKey": "trigger",
    "status": "pass",
    "start": "2026-07-30T20:00:01.533Z",
    "end": "2026-07-30T20:00:02.811Z",
    "result": { "customer_email": "[email protected]", "total": 129.0 },
    "error": null,
    "runCount": 1,
    "iterators": []
  }
]

Step or setting	API `result` shape	Canvas reference example
Webhook (`Body only` enabled)	Posted JSON sits directly at top level of `result`	`{{ 1.customer_email }}`
Webhook (default)	Posted JSON sits under `result.body`	`{{ 1.body.customer_email }}`
HTTP Request	Response wrapper sits under `result.ret`	`{{ 2.ret.data }}`
AI Steps	Model output sits under `result.result`	`{{ 2.result }}`

See Variable Reference Syntax for full reference rules. Execution records do not include a separate resolved-input field; inspect the Step in the canvas when investigating its inputs.

Authentication

Header	Required	Description
`x-glow-api-key`	Yes	The API key for this specific automation.
`x-glow-correlation-id`	Yes	The same correlation ID you sent when triggering the automation.

API keys are per automation, not per workspace. In the Webhook Step’s App drawer, expand result instruction to find Workflow API key. As the automation’s owner, a workspace Admin, or a Manager, use Replace workflow API key (or Generate secure workflow API key for an older key) and confirm the replacement. Copy and store the new key securely before closing the panel; it is shown only once. The previous key stops working immediately, so update every client that retrieves this automation’s results.

Query Parameters

Parameter	Description
`limit`	Maximum Step records, newest first. Defaults to 100; accepts positive whole numbers and caps values above 500 at 500.
`elementNumbers`	Comma-separated step numbers, e.g. `1,3`. These are the same numbers you reference on the canvas with `{{ 3.field }}`, so you can pull back only the steps you care about.

The endpoint evaluates limit (up to 500 newest Step records) before filtering by elementNumbers. Pass limit=500 when filtering multi-step runs by Step number, or forward final payloads to your system as the last Step of the automation.

Example


curl "https://api.getglow.ai/api/v1/flows/clwyo3ggd000008l353t02aig/executions?elementNumbers=1,3" \
  -H "x-glow-api-key: <your-flow-api-key>" \
  -H "x-glow-correlation-id: ebc32db7-bab9-4aaa-bdb6-d201759c39ad"

Responses

Status	Meaning
`200`	Execution history returned.
`400`	The correlation ID is missing, or `limit` is not a positive whole number.
`401`	The automation API key is missing or invalid, or the automation is unknown.
`404`	No matching execution was found after automation API-key validation.

For a 404, check the correlation ID, whether the run has started, and whether its history is still retained. Do not automatically submit another webhook request in response to a missing history record.

API Reference

Consult the published OpenAPI specification for endpoint details:

Interactive browser: https://api.getglow.ai/api
Machine-readable spec: https://api.getglow.ai/api/swagger.json

Use the spec to generate a typed client in your own language rather than hand-writing request code.

Securing inbound webhooks

Configure the shared secret and signature header to match the sender. The generic Webhook trigger supports HMAC-SHA256 over the raw request body, with a hex or base64 signature and an optional sha256= prefix. With verification configured, missing or invalid signatures are rejected. Without a secret, signature verification is off. A sender that signs a different message format needs a compatible verification arrangement; supplying its secret alone is not enough. See Webhook Triggers for setup.

Verify it works

Run: POST a JSON payload with x-glow-correlation-id to a Live Webhook URL, then GET /api/v1/flows/{flowId}/executions with x-glow-api-key and the same correlation ID
You should see: The webhook returns 200 OK with { success: true }, and the executions endpoint returns the step-by-step execution records for that correlation ID.

What’s Next?

Configure trigger URLs and signature verification in Webhook Triggers.
Check the ceilings that apply to your plan in System Limits.