Skip to main content

Error handling

REST endpoints return JSON errors in a consistent envelope. Branch first on the HTTP status, then on error.code when your integration needs a more specific recovery path.
404 Not Found

Envelope fields

Nested codes such as error.details.validationErrors[].code describe an individual validator rule and are not part of the top-level error-code contract. FHIR endpoints return a FHIR OperationOutcome; its issue[].code values follow the FHIR code system rather than this REST convention.

HTTP status codes

validation_error uses 400, and invalid_api_key uses 401. These are the runtime contract; older documentation that listed 422 and 403 respectively was incorrect. JSON (including FHIR JSON) and URL-encoded request bodies are limited to 256 KiB (262,144 bytes). The limit is enforced while the body is read and before JSON deserialization. REST requests over the limit return 413 payload_too_large; FHIR routes represent the same status as an OperationOutcome.

Authentication and authorization

Request validation and safety

Resources, vocabularies, and mappings

Licence-restricted vocabularies

vocabulary_restricted (403) means the caller has not been authorized for the requested licensed vocabulary. The current policy is:
403 Restricted vocabulary
A successful CPT4 validation applies to all API keys owned by that Dashboard user. It never applies across users. OMOPHub does not retain the submitted UMLS key. See CPT4 access for setup and licensing details.

Vocabulary releases

version_not_found replaces the legacy, documentation-only version_not_supported code. Unknown vocabulary releases have resource-not-found semantics and return 404.

Limits and business rules

Search and operational errors

Administrative endpoint errors

These codes are returned by authenticated API-key management and performance diagnostic endpoints.

Client handling