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. 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.