What policies can do
A policy has a name, an on/off switch, up to ten match expressions that pick which requests it applies to, and one rule. There are five kinds of rule:
See Gateway policies to add them from the dashboard, API, or CLI.
What happens to a request
- The request arrives at one of your domains, and the gateway finds the deployment it belongs to.
- The deployment’s policies run in list order. Turned-off policies, and policies whose match expressions don’t fit the request, are skipped.
- If a policy rejects the request, the caller gets a
4xxwith anerr:frontline:...code. The request never reaches your app and doesn’t appear in your request log. See Gateway errors for every code. - If every policy passes, the gateway forwards the request to your app with the headers below.
What your app receives
The gateway keeps the originalHost header and adds these:
Callers can’t fake these. We remove any
X-Unkey-* header a client sends before policies run. To get the deployment ID, read the UNKEY_DEPLOYMENT_ID environment variable.
The response to the caller includes X-Unkey-Request-Id, X-Unkey-Region, and X-Unkey-Frontline-Id, plus X-Unkey-Timing entries for time spent in the gateway. Rate limit headers are added when a rate limit applied.
Use keys from API Management
The API keys the gateway checks live in API Management. To require a key, create a keyspace and keys in API Management, then add the keyspace to an API key authentication policy. The same keys also work if your own code callskeys.verifyKey.
Next steps
Gateway policies
Match expressions, evaluation order, limits, and how to set policies.
API key authentication policy
Verify Unkey keys at the edge and forward the identity to your app.
The principal header
The JSON your app reads to know who is calling.
Gateway errors
Every code the gateway returns, with its status and cause.