Error Envelope

Every error response uses a single nested error object:
Switch on error.code, not error.message. Messages may be reworded for clarity; codes are stable contracts. The HTTP status line tells you the class of failure; error.code tells you exactly which one.

Code format

Each code is a per-domain prefix and a numeric identifier joined by an underscore: <PREFIX>_<ID> (for example AUE_301, UE_101, MR_1101). The prefix names the domain that raised the error and the identifier is unique within that domain, so error.code is globally unambiguous.

HTTP Status Conventions

The status line is derived from the error variant. Codes from any domain map onto this fixed set:
Authentication and ownership failures on a specific resource surface as that domain’s own code (for example MR_1102 for an MRN the caller does not own), not as a single generic forbidden code.

Error-Code Catalogue

Codes are grouped by domain prefix. The table below lists the prefix, the domain it covers, and representative real codes. This is not exhaustive — every domain also has an internal-error code (e.g. AUE_300, UE_100) for unexpected failures.
The numeric identifier carries the HTTP status implicitly via its variant, not via the number itself. Always read the HTTP status line alongside error.code.

Common Codes by Status

A few high-traffic codes you will handle in most clients:

400 — Bad Request

401 — Unauthorized

403 — Forbidden

404 — Not Found

409 — Conflict

422 — Unprocessable Entity

500 / 502 — Server and Upstream

500 errors are logged with full context on the server side. They never expose internal details (stack traces) in the response body. If you hit a persistent 500, report the failing request to the Aarokya team for log correlation.

When to Retry vs When to Show the User


Debugging Guide

Step 1: Check error.code

error.code is your primary signal. Match it against the catalogue above before reading error.message.

Step 2: Read the HTTP status line

The status code tells you the class of failure (auth, not-found, conflict, server). If you receive a non-JSON body (e.g. HTML), a proxy or load balancer likely rejected the request before it reached the backend — the API always returns the JSON error envelope for failures it handles.

Step 3: Common misconfigurations


Client-Side Error Handling