# Developer Settings > Trigger workflows from your own systems and read back execution history over the REST API. 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](/build/triggers/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. ```bash curl -X POST https:// \ -H "Content-Type: application/json" \ -d '{ "customer_email": "ada@example.com", "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](/reference/system-limits#data-retention). 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. ```json [ { "elementKey": "trigger", "status": "pass", "start": "2026-07-30T20:00:01.533Z", "end": "2026-07-30T20:00:02.811Z", "result": { "customer_email": "ada@example.com" }, "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](/reference/variable-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 ```bash curl "https://api.getglow.ai/api/v1/flows/clwyo3ggd000008l353t02aig/executions?elementNumbers=1,3" \ -H "x-glow-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](/build/triggers/webhook) for setup. ## What's Next? - Configure trigger URLs and signature verification in [Webhook Triggers](/build/triggers/webhook). - Check the ceilings that apply to your plan in [System Limits](/reference/system-limits).