Developer Settings

Glow gives you two programmatic surfaces: webhook triggers to start a workflow from your own code, and a REST API to read back what happened during a run.

Triggering a Workflow

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

Add a Webhook trigger

Add a Webhook trigger to your workflow and switch the workflow to Live: the URL exists from that moment. Copy it from the trigger’s endpoint field. A test-data run sends nothing over the network and mints no URL.

Send your payload

POST your JSON to that URL.

Add a correlation ID

Include a headers object in your JSON body, carrying x-glow-correlation-id with a value unique to this one request: an order ID, a request ID, or a UUID (a randomly generated unique code). You look the run up by it afterwards. The ID travels inside the body, not as an HTTP header.

That headers object is stored with the rest of the payload, so it sits alongside your own fields in the trigger’s output and reads as {{ 1.headers }}. Pick a top-level field name other than headers for your own data. When you later read the results back, the same name is a real HTTP header on that request — inside the body to start a run, as a header to fetch it.


curl -X POST https://<your-webhook-url> \
  -H "Content-Type: application/json" \
  -d '{
    "customer_email": "[email protected]",
    "total": 129.00,
    "headers": { "x-glow-correlation-id": "order-4815" }
  }'

Use a fresh value every time. Sending the same correlation ID twice does not replace or deduplicate anything: each POST starts its own run. The lookup then returns the first run that ever used that ID, so reusing one means you keep reading back the oldest run rather than the one you just started. If your own system retries, add the attempt to the ID: order-4815-2.

The webhook acknowledges with 202 Accepted immediately and the workflow continues asynchronously. A slow workflow never times out the caller.

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 workflow’s id: the UUID in its canvas URL, between /workflows/ and the trailing slash. 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, and when it started and finished. For a step inside a loop, it also carries which iteration it was.


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

The shape of result depends on the step, and maps onto the canvas path after the step number: this webhook record is read as {{ 1.customer_email }}, an HTTP Request’s record carries ret inside result, an AI step’s carries result again. See Variable Reference Syntax. A step that failed carries the reason under error and a status of error; a step that never ran reports ignored. runCount tells you which attempt a record is: 1 is the first, 2 the first retry.

There is no field holding the input a step received. To see what went into a step, read the result of the step it drew from.

Authentication

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

API keys are per workflow, not per workspace. Find a workflow’s key in the Webhook step’s settings in the App drawer, alongside the trigger URL.

Query Parameters

Parameter	Description
`limit`	Caps how many step records come back. Omit it and you get the run’s full history.
`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.

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: order-4815"

Responses

Status	Meaning
`200`	Execution history returned.
`400`	A required header or parameter is missing.
`401`	The API key is invalid.
`404`	No matching flow or execution was found.

A 404 usually means the correlation ID does not match any run. Check that you sent the same value when triggering the workflow, and that the run has actually started.

API Reference

The complete, always-current API specification is published as OpenAPI:

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

For webhooks that receive data from third parties, configure a shared secret. Glow then verifies the HMAC signature of each request — a cryptographic proof that the sender knew the shared secret — and drops anything unsigned or tampered with. See Webhook Triggers for setup.

What’s Next?

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