Skip to main content

​
Jobs and event streams

​
What this lets you do

Follow a durable execution, reconnect after a dropped stream, and avoid duplicate work.

​
What you need

  • An execution_id from the started event
  • The latest received event ID
  • The same authenticated account that created the execution

​
Steps

​
1. Handle the closed event set

The closed public set is started, thinking, progress, job, question, asset, and done. Do not branch on display text. Branch on event name and documented status fields.

​
2. Resume after disconnect

Read GET /v1/executions/{execution_id} before deciding whether to retry. The canonical status is one of needs_input, queued, running, completed, failed, or cancelled. The beta permits two active managed jobs per account.

​
Confirm it worked

The resumed stream continues after the supplied event ID without creating a second execution or charge.

​
Common errors

  • 404: use an execution owned by the authenticated account.
  • 409: read canonical state and stop applying an invalid state transition.
  • 429: wait until active managed work drops below the account limit.

​
Troubleshooting

Persist the execution ID and latest event ID before updating the interface. If state is uncertain, read canonical state before submitting anything new.

​
Next steps