error object instead of data:
Error format
The format follows RFC7807 Problem Details inside the Unkey envelope:- title: short summary
- detail: human-readable explanation
- status: HTTP status code
- type: URI for documentation
- errors: optional validation details
Common error types
| Status | Error type | Description |
|---|---|---|
| 400 | validation-error | Request body failed validation |
| 401 | unauthorized | Missing or invalid authorization |
| 403 | forbidden | Valid authorization but insufficient permissions |
| 404 | not-found | Resource not found |
| 409 | conflict | Conflicts with current state |
| 429 | rate-limited | Rate limit exceeded |
| 500 | internal-server-error | Unexpected server error |
Validation errors
For validation errors, Unkey returns:- location: where the error occurred
- message: what went wrong
- fix: suggestion for resolution when available
Error recovery
Error messages are designed to be actionable. Use therequestId when reporting issues.
Error handling best practices
- Check status codes first.
- Parse the error object for details.
- Retry only on 5xx errors when appropriate.
- Log the full error response for debugging.

