Skip to main content
When a request fails, the response has an 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

  1. Check status. A 4xx means fix the request. A 500 or 503 means retry.
  2. For a 4xx, branch on type if you need to tell causes apart. Show detail to developers, never to end users.
  3. For a 400, show each entry in errors with its location and message.
  4. Always log meta.requestId with the error, so support can find the exact request.
Every code has its own page with a “How to fix” section, under Errors in the Platform navigation.
Last modified on September 29, 2026