Menu
Platform
AI
App store purchases
Database
Flags
Jobs and cron
Localization
Monitoring
Notifications
Payments
Queues
Sandboxes
Webhooks
Getting Started
Authentication
KV Store
Deploy & Infrastructure
Reference
On this page
Errors and conflicts
Branch on the code, retry with the same key, and re-read before you change anything after a 409
Every failed call on the surface that runs schedules answers with one shape.
Branch on error.code, log error.message for a person, and never parse the
message: it can name ids and revisions, and its wording is not a contract.
{
"error": { "code": "conflict", "message": "expected revision 1, current revision 2" },
"product": "Sylphx Compute",
"authority": "compute"
}An error caused by the server is logged where operators can read it and
returned to you only as internal. An error body is not a debugging channel.
#Statuses
| Field | Type | What it is |
|---|---|---|
201 | created | A schedule, or a new tick, was recorded. Keep the returned identity and revision. |
400 | invalid_argument | A field, cursor or limit is wrong, and the message names it. Retrying unchanged fails the same way. |
401 | missing_authorization | There is no bearer key on the request. Send a Sylphx Access key with the workflows scope the call needs. |
404 | not_found | The schedule does not exist, or is not visible to the key. |
409 | conflict | A fence or an idempotency digest disagrees with what is stored. See the conflicts below. |
503 | store_unavailable | The durable store is not usable. Nothing was admitted; retry when the service is ready. |
500 | internal | An unexpected failure. Retry with the same idempotency key. |
A schedule mutation can also succeed and report, on the operation it returns,
platform_place_cell_wake_unavailable. The schedule row was kept; the wake
that arms it could not be commanded, and the operation says why. That code is
read from the operation document rather than from a transport error, because
the request itself worked.
#Conflicts
A 409 always means the stored state disagrees with your request. What to do next depends on which fence disagreed.
| Field | Type | What it is |
|---|---|---|
Idempotency conflict | same key, different body | A key you already used arrived with a different request. Send the original body to get the original identity back, or a new key if your intent changed. |
Revision conflict | expectedRevision | The revision you sent is not the current one, for instance because a tick moved it. Read the schedule again and reapply the change on top of what you read. |
#Retrying safely
Resend the exact body, with the same idempotencyKey, after a timeout, a
dropped connection or a 500. If the first attempt landed you get that identity
back; if it did not, you create it now. Either way there is one record. A
changed body under a used key is a conflict and writes nothing, which is what
makes the retry safe to send.