Skip to main content
When an AuditRails API request cannot be completed, the response body always contains a structured error object. Every error carries a stable machine-readable code, a human-readable message, and a request_id you can share with support. Familiarizing yourself with the error taxonomy makes it straightforward to write robust error-handling logic in your integration.

Error Response Structure

All errors — regardless of category — follow the same JSON envelope:
string
A slash-namespaced, stable identifier for the error (e.g. auth/key_not_found). Use this field in your error-handling switch statements — message text may change without notice.
string
A plain-English description of the problem and, where relevant, how to fix it. Suitable for logging but not for display to end users.
string
A unique identifier for the specific API request that failed. Always include this when contacting support.
string
Always points to this page. Useful when surfacing errors in dashboards or alerting systems.
Errors in the action/* namespace may include two additional fields: suggestion (a recommended fix) and valid_actions_url (a direct link to your project’s action catalog). Check for these fields when handling action validation errors.

Authentication Errors — 401 Unauthorized

These errors occur before any request processing. Check your API key configuration first.
Never log your full API key in error reports or support tickets. When contacting support, share only the first 10 characters of the key prefix (e.g. at_live_abc). This is enough for the support team to identify the key without compromising your account.

Subscription Errors — 402 Payment Required


Rate Limiting Errors — 429 Too Many Requests

All 429 responses include a Retry-After header indicating the number of seconds to wait before retrying. See the Rate Limits reference for full details on limits by plan and key type.
All AuditRails SDKs automatically retry rate limit errors with exponential backoff — you do not need to implement this yourself when using the log() batch method. Only logDirect() surfaces rate limit errors as exceptions.

Validation Errors

These errors indicate a problem with the structure or content of your request payload. They must be fixed in your code before retrying — retrying without changes will produce the same error.

Event Errors


Read Errors


Action & Framework Errors

These errors relate to the action catalog and compliance framework configuration for your project.

Server Errors — 500 Internal Server Error

All AuditRails SDKs automatically retry 5xx errors using exponential backoff. You only need to handle these manually if you are integrating directly with the HTTP API.

Contacting Support

If you need to escalate an error to the AuditRails support team, include the following in your report:
  1. The request_id from the error response (e.g. req_01HX...)
  2. The timestamp of the failed request
  3. The first 10 characters of your API key prefix (e.g. at_live_abc) — never the full key
  4. The full error code (e.g. server/internal)
Reach the support team at auditrails.io/contact.