Errors

Every error has the same body: a human-readable English error and a stable machine-readable code.

{ "error": "No such booking.", "code": "not_found" }

Branch on code, never on error. The messages are written for a person reading a log and we improve them without notice; the codes are part of the contract. Some codes carry extra fields next to error and code — they are listed in the table.

Error codes#

Which of these a given endpoint can return is listed per operation in the API reference.

Validation errors#

validation_failed is 400 for unparseable JSON, a bad query parameter or a starting_after cursor that was modified (cursors are signed — pass them back untouched). It is 422 when the body parsed but is not acceptable. Either way it lists what was wrong, field by field:

{
  "error": "The request body is not valid.",
  "code": "validation_failed",
  "issues": [
    { "path": "guests.0.count", "message": "Expected number, received string" },
    { "path": "customer.email", "message": "Invalid email" }
  ]
}

What to retry#

401 api_key_revoked, 401 api_key_expired and 403 site_unavailable in particular will not fix themselves — stop and alert a person. See Idempotency for why a retry with the same key is always safe.

Getting help#

When you contact Awrora support about an error, bring the code from the response, roughly when the request was made, and the key's prefix (the first twelve characters shown in Awrora). Never send the whole key. Every authenticated call is logged with its path, status and duration, so the request can usually be found quickly. 429 responses are sampled — at most one log row per key per minute.