Skip to main content
When a policy rejects a request, or the gateway can’t reach your , the gateway responds with an error code and a request ID. Use this page to find out what a code means and who needs to fix it. Most codes look like err:frontline:{category}:{specific}, and each one has its own page.

Response format

If the request’s Accept header includes application/json, application/*, or */* without text/html, the body is JSON:
Otherwise it returns an HTML page with the status, message, code, request ID, and a link to the code’s page. So browsers see a page and API clients see JSON. This format is different from the one the Unkey API uses. meta.requestId matches the X-Unkey-Request-Id response header. Quote it when you contact the API owner or Unkey support.

The codes

Codes are grouped by who needs to act.

Client: fix the request or the key

Configuration and capacity: you own the API

Upstream: your app or its connection

Platform: Unkey acts

Codes that are not err:frontline:*

A few err:user:* codes can also come from the gateway. Their pages describe how the Unkey API uses them, which can differ. For a Compute app, the status and cause are the ones below. Requests that fail before reaching your app don’t appear in your request log.

If you already use keys.verifyKey

An API key authentication policy checks keys like keys.verifyKey. If you already handle that endpoint’s code values, here’s what each one becomes at the gateway: A key from a keyspace the policy doesn’t list returns invalid_key, and a request with no key returns missing_credentials.

Next steps

Error catalog

All three error systems and both envelope shapes.

Gateway policies

Evaluation order determines which error a request gets first.
Last modified on September 29, 2026