Skip to main content
Unkey Deploy is currently in private beta. To get access, reach out on Discord or email support@unkey.com.
A policy is a rule that the Sentinel evaluates on incoming requests. Each policy combines a condition (which requests to match) with an action (what to do). Policies are the building blocks for all of the Sentinel’s request processing, including authentication, rate limiting, and access control.

​
Policy structure

Every policy has four components:
FieldDescription
nameHuman-readable label for identification
enabledToggle to disable the policy without removing it
matchConditions that determine which requests the policy applies to
configThe action to perform (authentication, rate limiting, IP rules, or validation)
You can disable a policy by setting enabled to false. This is useful during incidents when you need to bypass a misbehaving policy without deleting its configuration or triggering a redeploy.

​
Evaluation order

The Sentinel evaluates policies in the order they appear in the configuration:
  1. Skip the policy if enabled is false.
  2. Evaluate all match conditions. Skip the policy if any condition doesn’t match the request.
  3. Execute the policy action. If the action rejects the request, return an error response immediately.
  4. Move to the next policy.
If all matching policies pass, the Sentinel forwards the request to your app. Order matters. Place authentication policies before policies that depend on an authenticated identity (for example, rate limiting by authenticated subject).

​
Match expressions

Match expressions are coming soon. Policies configured through the dashboard apply to all requests. Contact support@unkey.com for custom match expression configuration.
Match expressions control which requests a policy applies to. A policy can have multiple match conditions, and all conditions must match for the policy to run (AND logic). An empty match list applies the policy to all requests.

​
Available match types

TypeMatches onExample use case
PathURL pathApply auth to /api/v1 paths only
MethodHTTP methodRate limit POST requests but not GET
HeaderRequest header and valueEnforce policies when X-Custom-Header is present
Query parameterURL query parameterMatch requests with a specific version parameter
All string matching supports three modes:
  • Exact: The value must match exactly (for example, /healthz)
  • Prefix: The value must start with the specified string (for example, /api/v1)
  • Regex: The value must match an RE2 regular expression (for example, ^/users/[0-9]+$)
Each mode supports optional case-insensitive matching.

​
Combine conditions

To create AND conditions, add multiple match expressions to a single policy. All expressions must match for the policy to run. To create OR conditions, create separate policies with the same action but different match expressions.

​
Policy types

TypeStatusDescription
API key authenticationAvailableVerify Unkey API keys and forward identity to your app
LoggingAvailableRecord full HTTP requests and responses for debugging
JWT authenticationComing soonValidate Bearer JWTs using JWKS, OIDC, or PEM public keys
Rate limitingComing soonEnforce per-IP, per-key, or per-subject rate limits
IP rulesComing soonAllow or deny requests based on CIDR ranges
OpenAPI validationComing soonValidate requests against an OpenAPI 3.0/3.1 specification

​
Error response format

When a policy rejects a request, the Sentinel returns a structured JSON error following the RFC 7807 Problem Details format: 
{
  "meta": { "requestId": "req_abc123" },
  "error": {
    "title": "Unauthorized",
    "detail": "API key is invalid or expired",
    "status": 401,
    "type": "https://unkey.com/docs/errors/sentinel/unauthorized"
  }
}
The type URI is stable per error kind and suitable for programmatic handling. Each policy type maps to a standard HTTP status code:
Policy typeRejection status
Authentication (missing or invalid)401
Authentication (insufficient permissions)403
Rate limiting429
IP rules403
OpenAPI validation400
Last modified on March 30, 2026