Read a run's events
Returns the run's event log in order, starting after `afterSeq`. This is the paged counterpart to the SSE stream and is the right choice for a client that cannot hold a long-lived connection. The `nextCursor` it returns is exactly the value to send as the next `afterSeq`, or as `Last-Event-ID` when switching to the stream, so the two never skip or repeat an event. `done` is true once the run has reached a terminal state, which is the signal to stop polling.
Returns the run's event log in order, starting after afterSeq. This is the paged counterpart to the SSE stream and is the right choice for a client that cannot hold a long-lived connection. The nextCursor it returns is exactly the value to send as the next afterSeq, or as Last-Event-ID when switching to the stream, so the two never skip or repeat an event. done is true once the run has reached a terminal state, which is the signal to stop polling.
Path Parameters
The project the run belongs to.
The run whose events to read.
Query Parameters
Return only events whose seq is greater than this. Omit or pass 0 to start from the beginning.
0 <= valueMaximum events to return. Defaults to 200.
1 <= value <= 500Response Body
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/projects/string/runs/string/events"{ "events": [ { "seq": 0, "type": "run.started", "payload": null, "createdAt": "string" } ], "nextCursor": 0, "done": true}Approve or refuse a run step POST
Records a person's decision on one approval and releases the run step it was raised for. A step the plan marks as costing credits, needing a signature, publishing, or reading a secret DOES NOT RUN until a decision approves it — this endpoint is what ends that wait, so the approval card in the dashboard is the control that runs the work, not a record of it. What the caller must know: the run is resolved through its project, so a run owned by another user answers the same 404 as a run that does not exist — never a 403, which would confirm the run is real. The approval id must belong to the run in the path; one raised by a different run is the same 404. `approved: true` releases the step so the run performs it at its next check of the gate, which is the step after the one it was refused on; a run whose budget is already spent, or that has finished, will not come back to it — read the run's events to see what the run did with the answer. The decision is final. An approval already decided answers 409, because two people looking at the same card and both pressing a button must not produce two answers with different timestamps. Decide the approval, then re-read `GET /projects/{projectId}/runs/{runId}/events` to see the run's reaction rather than assuming the step ran.
Follow a run over SSE GET
Streams the run's event log as Server-Sent Events, one event per line of output, in `seq` order. Each event carries `id: <seq>`, so a browser that reconnects automatically replays from exactly where it left off by sending its last id back in the `Last-Event-ID` header; the server replays the missed events and then resumes live, with no gap and no duplicate. The same cursor is available as a `?afterSeq=` query parameter for a client that cannot set headers. The stream ends by closing when the run reaches a terminal state, after the final `run.finished` or `run.error` event has been sent. A client that must not hold a connection open should poll the paged endpoint instead — the two share the same cursor space, so a client may switch between them without skipping or repeating an event.