Poll the state

The state of an execution as an HTTP code, with no body. The cheapest way to poll, and the one to put in a loop. | Code | Meaning | What to do | | :--- | :--- | :--- | | `200` | Finished. Nothing about it will change. | Read the results, or [the state](api:GET/executions/handler/v1/{execution_id}) if you want to know how it went. | | `202` | Still working. | Ask again later. | | `423` | Waiting for an answer from your customer. | Fetch [the state](api:GET/executions/handler/v1/{execution_id}) for the form, then reply to [Resume an Execution](api:PUT/executions/handler/v1/{execution_id}). | | `404` | No such execution for your application. | Check the id — a deleted execution answers the same way. | <Note> **No answer from this endpoint has a body** — not the `200`, not the `404`. `HEAD` returns headers only, by definition, so the status line *is* the answer and there is nothing to parse. Whatever example a client library prints for an empty response, the socket carries no bytes. </Note> <Warning> **`200` does not mean *successful*, it means *closed*.** A failed execution is finished too, and this endpoint cannot tell you which it was: the reason lives in the state. Branch on `status_reason`, never on the fact that the poll stopped returning `202`. </Warning> <Tip> **Poll politely, or stop polling.** An engine that talks to a bank takes tens of seconds, not milliseconds — a few seconds between checks is plenty. [Webhooks](/direct-executions/webhooks) replace the loop entirely, and the `ended` event is the only one you have to handle. </Tip> <Note> **Server to server only.** This call is authorised with your application secret: it belongs in your backend, never in a browser, a mobile app or anything your customer can read. </Note>