Skip to main content
Errors follow RFC 9457 Problem Details, served with the media type application/problem+json. Branch on the HTTP status for flow control and on the code field for specifics.

Error shape

string
An RFC 9457 URN identifying the error class (urn:creatoraudit:error:…).
string
Short, human-readable summary of the error class.
integer
The HTTP status code, repeated in the body.
string
Human-readable explanation specific to this occurrence.
string
Stable, machine-readable identifier (for example, NOT_FOUND). Branch on this.
string
The path of the request that failed.
string
Correlation ID for this request, mirroring the X-Request-ID response header.

Validation errors

A 422 (code: VALIDATION_ERROR) additionally carries an errors array describing each field that failed validation (an example entry is shown below):

Status codes

Authentication-specific statuses are covered in Authentication; 429 handling and back-off live in Rate limits.

Handle errors robustly

  • Branch on status, then code. Use the HTTP status for coarse flow (retry, reauthenticate, surface to the user) and code for precise handling — for example, distinguishing INSUFFICIENT_SCOPE from QUOTA_EXCEEDED within 403.
  • Read errors on 422. Map each { field, message } back to the input that caused it.
  • Always capture X-Request-ID. Log it (or the request_id body field) with every failure so support can correlate a call to its server-side event.
  • Retry the right ones. Retry 429 and 503 with back-off and honor Retry-After; do not blindly retry 4xx validation or auth errors — fix the request instead.
  • Parse defensively. Treat any non-2xx as a problem document and read code rather than string-matching on detail.
If you hit an unexpected 5xx, include the X-Request-ID when you contact support@creatoraudit.com.