conflict
conflict
Section titled “conflict”HTTP status: 409 Conflict
How to fix
Section titled “How to fix”- Re-fetch the latest state.
GET /api/v1/<resource>/{id}— the response gives you the currentupdatedAt, status, and any concurrency tokens. - Reconcile your change against the latest state. If a teammate updated the resource between your read and write, merge their change in before retrying.
- Retry the write with the fresh state. Most clients should treat 409 as a signal to re-read and retry, not as a fatal error.
- For idempotent submits (e.g. duplicate workflow names), use
already_existsas a hint — your record probably succeeded the first time and the retry is a no-op.
What this means
Section titled “What this means”The request was syntactically valid but conflicts with the resource's current state — usually because another caller mutated it concurrently, or because the change you're requesting (cancel a finished job, re-create an existing name) doesn't make sense for the resource's current status.
Related errors
Section titled “Related errors”already_exists— specific case: identifier collisionjob_terminal— specific case: mutating a finished jobworkflow_disabled— specific case: submitting against a disabled workflow
Still stuck?
Section titled “Still stuck?”Contact support with your request_id (looks like req_01HF3JKB...). We'll inspect the resource state both sides saw.