API Policies are reusable governance and transformation rules applied to the requests and responses of your managed APIs — without changing the backing automation.
Overview
A policy is defined once and attached wherever it is needed — to an access profile, an endpoint, or a collection. The platform enforces it automatically on every matching call. Policies let you add rate limiting, authentication checks, validation, transformations, and access controls to any API without touching the automation that backs it. The same automation can be exposed with strict limits to a partner and looser ones internally just by attaching different policies.
Policy Types
The available types cover the common API gateway needs:
Policy Type | What It Does |
|---|---|
Rate limiting | Caps how many requests are allowed within a time window (see Rate Limiting & Quotas for detail). |
Usage quota | Caps total requests over a longer period — a daily or monthly allowance. |
Request validator | Checks the incoming request's structure (required fields, types) and rejects malformed ones before the backing resource runs. |
JWT validation | Verifies a JWT present in the request — beyond or separate from the access profile's authentication method. |
CORS | Controls cross-origin browser access: allowed origins, methods, and headers. |
IP-based access control | Allows or blocks requests based on the caller's source IP address. |
Request transformer | Modifies the incoming request — headers, body, or parameters — before the backing resource runs. |
Response transformer | Modifies the outgoing response before it is returned to the caller. |
Custom (workflow) policy | Runs one of your automations as part of the request pipeline to enforce bespoke rules or enrichments. |
Inbound vs Outbound Policies
Every policy has a direction:
Inbound — runs on the request, before the backing resource is invoked. Can reject the call or modify the request. Rate limiting, validation, CORS, JWT validation, IP control, and request transformers are inbound.
Outbound — runs on the response, after the resource produces it. Can modify what is returned. Response transformers are outbound.
This split is why a request can be blocked before your automation ever runs, and a successful result can still be reshaped on the way out.
Attaching Policies and Execution Order
Policies attach at three levels and run in this order on every request: access profile first, then endpoint, then collection. A single request can be subject to policies from all three levels simultaneously. If any inbound policy rejects the request, the chain stops — remaining policies do not run — and the caller receives that policy's status code (commonly 400 or 429). Any limit counted for the rejected request is rolled back so it does not reduce the caller's future allowance. Attach broad baseline rules at the collection and tighten per endpoint or per client as needed.
Custom (Workflow) Policies
Beyond the built-in types, a custom (workflow) policy runs one of your automations as part of the request pipeline. The automation receives the request (and, for outbound policies, the response), evaluates your bespoke logic, and returns whether to proceed along with any changes to the request or response. This lets you enforce rules that the built-in types cannot cover — custom authorisation, dynamic routing decisions, enrichment from another system — using the same automation tools you already know. Use built-in types for standard API gateway concerns; use custom policies for business-specific governance.
Notes
Define policies once and reuse them — attach the same rate-limit policy to multiple access profiles rather than creating duplicates.
Apply a baseline rate limit at the collection level and override per access profile for clients with different entitlements.
CORS policies must be applied to every collection that browser-based callers will reach — omitting it blocks all cross-origin browser requests.
Use request validator policies to enforce structural contracts at the gateway; use custom policies for business logic that depends on runtime data.
Test policies on a non-live endpoint before applying them to a production collection — a misconfigured policy can block all traffic.