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
A422 (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) andcodefor precise handling — for example, distinguishingINSUFFICIENT_SCOPEfromQUOTA_EXCEEDEDwithin403. - Read
errorson422. Map each{ field, message }back to the input that caused it. - Always capture
X-Request-ID. Log it (or therequest_idbody field) with every failure so support can correlate a call to its server-side event. - Retry the right ones. Retry
429and503with back-off and honorRetry-After; do not blindly retry4xxvalidation or auth errors — fix the request instead. - Parse defensively. Treat any non-
2xxas a problem document and readcoderather than string-matching ondetail.
5xx, include the X-Request-ID when you contact
support@creatoraudit.com.