error object instead of data. Every Unkey error has the same shape (Problem Details for HTTP APIs, RFC 7807), so one handler covers them all. The type field links to the page for that error.
Fields
string
required
A short summary, for example
Not Found or Insufficient Permissions. It doesn’t change for a given problem, but match on type in code.string
required
A plain explanation of what went wrong, written to help a developer fix it. It can name the field, resource, or permission involved. Don’t parse it, because the wording can change.
integer
required
The HTTP status code, repeated in the body.
string
required
A URL that identifies the error and links to its page. The last three path segments are the error code,
err:{system}:{category}:{specific}. Match on this field to handle a specific error. Error pages on this site shorten it to the path, but the API always sends the full URL.array
Sent with 400, 408, 413, and 499 responses. When the request fails validation, it has one entry per problem, so you can fix them all at once. Otherwise it’s an empty array.
Status codes
What each status means on this API, and the codes you’ll see most often with it:
An invalid key isn’t an HTTP error. When you verify a key that isn’t valid,
keys.verifyKey returns HTTP 200 with data.valid: false and a data.code, because your request worked. The HTTP errors above are for problems with your request or your root key. See Verifying keys.
Handling errors
- Check
status. A 4xx means fix the request. A 500 or 503 means retry. - For a 4xx, branch on
typeif you need to tell causes apart. Showdetailto developers, never to end users. - For a 400, show each entry in
errorswith itslocationandmessage. - Always log
meta.requestIdwith the error, so support can find the exact request.