> ## Documentation Index
> Fetch the complete documentation index at: https://unkey.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Unkey is two separate products. Compute builds, deploys, and runs apps behind a gateway. API Management issues API keys, enforces rate limits, manages identities and permissions, and reports usage. Say which product a page belongs to; a reader can use either without the other.
> Every Unkey API endpoint is an HTTP POST to https://api.unkey.com/v2/{service}.{procedure} with a root key in the Authorization: Bearer header. Root keys are workspace scoped.
> Error codes have the form err:{system}:{category}:{specific} and each has a page at /errors/{system}/{category}/{specific}.
> The word environment means production or preview in Compute. Rate limiting has four meanings on this site; the glossary lists them.

# Gateway

> What the gateway in front of every deployment does, and how policies control it.

export const ProductLink = ({product, href, title, children}) => {
  const productNames = {
    compute: "Compute",
    "api-management": "API Management",
    platform: "Platform"
  };
  return <div className="card unkey-product-card" data-card-href={href}>
      <div data-component-part="card-content-container">
        <h2 data-component-part="card-title">
          <a className="unkey-product-card-title" href={href}>
            {title}
          </a>
        </h2>
        <div data-component-part="card-content">
          <strong>{productNames[product]} docs.</strong> {children}
        </div>
      </div>
    </div>;
};

Every <Tooltip tip="One built and running version of an app in one environment.">deployment</Tooltip> on Unkey Compute sits behind the gateway, and there's no other way to reach it. So the gateway can check API keys, <Tooltip tip="Here: a gateway rate limit policy or a per-key limit the gateway enforces. Not the standalone ratelimit API.">rate limit</Tooltip> callers, block requests, validate them against your OpenAPI spec, and log them before they reach your <Tooltip tip="A Compute app: a deployable service inside a project. Not 'your application' in general.">app</Tooltip>. You set this up with policies. With no policies, the gateway just passes requests through.

<Warning>
  Each deployment keeps the policies it was created with. Adding, editing, or turning off a policy only affects the **next** deployment. To apply a change, redeploy (**Redeploy** in the dashboard, or `deployments.createDeployment`).
</Warning>

## 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:

| Type | What it does | On rejection |
| - | - | - |
| [API key authentication](/docs/compute/gateway/api-key-auth) | Checks an Unkey API key on the request and tells your app who's calling with the [principal header](/docs/compute/gateway/principal). | `401`, `403`, or `429` |
| [Rate limit](/docs/compute/gateway/rate-limiting) | Counts requests per client IP, header, path, authenticated caller, or principal field, and rejects when the limit is used up. | `429` |
| [Firewall](/docs/compute/gateway/firewall) | Blocks every request its match expressions select. | `403` |
| [OpenAPI validation](/docs/compute/gateway/openapi-validation) | Checks the path, query, headers, and body against the OpenAPI spec your deployment serves. | `400` |
| [Logging](/docs/compute/gateway/logging) | Saves headers, query data, and bodies of matched requests in the request log. | Never rejects |

See [Gateway policies](/docs/compute/gateway/policies) to add them from the dashboard, API, or CLI.

## What happens to a request

1. The request arrives at one of your domains, and the gateway finds the deployment it belongs to.
2. The deployment's policies run in list order. Turned-off policies, and policies whose match expressions don't fit the request, are skipped.
3. If a policy rejects the request, the caller gets a `4xx` with an `err:frontline:...` code. The request never reaches your app and doesn't appear in your request log. See [Gateway errors](/docs/compute/gateway/errors) for every code.
4. If every policy passes, the gateway forwards the request to your app with the headers below.

## What your app receives

The gateway keeps the original `Host` header and adds these:

| Header | Value |
| - | - |
| `X-Unkey-Request-Id` | The request ID. The caller sees the same value on the response and in error bodies. |
| `X-Unkey-Region` | The gateway's platform and region as `<platform>::<region>`. |
| `X-Unkey-Frontline-Id` | The ID of the gateway that handled the request. |
| `X-Unkey-Principal` | Who's calling, as JSON. Only present when an API key authentication policy succeeded. |
| `X-Forwarded-For` | The client IP. |
| `X-Forwarded-Host` | The hostname the client requested. |
| `X-Forwarded-Proto` | Always `https`. |

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](/docs/compute/gateway/api-key-auth). The same keys also work if your own code calls `keys.verifyKey`.

<ProductLink product="api-management" href="/docs/api-management/keys/creating-keys" title="Keyspaces and keys">
  Create the keyspace and keys an authentication policy verifies against, and manage their permissions, rate limits, and credits.
</ProductLink>

## Next steps

<Columns cols={2}>
  <Card title="Gateway policies" icon="list-check" href="/docs/compute/gateway/policies">
    Match expressions, evaluation order, limits, and how to set policies.
  </Card>

  <Card title="API key authentication policy" icon="key" href="/docs/compute/gateway/api-key-auth">
    Verify Unkey keys at the edge and forward the identity to your app.
  </Card>

  <Card title="The principal header" icon="id-badge" href="/docs/compute/gateway/principal">
    The JSON your app reads to know who is calling.
  </Card>

  <Card title="Gateway errors" icon="triangle-exclamation" href="/docs/compute/gateway/errors">
    Every code the gateway returns, with its status and cause.
  </Card>
</Columns>