When multiple policies govern an API, the platform applies them in a fixed order — Client first, then Endpoint, then API Group — giving you predictable, layered control over every request.
Overview
Policies can be attached at three levels in the API Manager: the Client (access profile), the Endpoint, and the API Group. The platform evaluates all attached policies on every incoming request, in that order. A single request can be subject to policies from all three levels simultaneously.
Understanding this order lets you build a layered governance model — broad baseline rules at the API Group, narrowed per endpoint, and tightened further per client — without duplicating configuration.
Diagram showing policy execution order: Client to Endpoint to API Group
Client → Endpoint → API Group
Policies run in this sequence on every request:
Client
→
Endpoint
→
API Group
Level | What It Covers | Typical Use |
|---|---|---|
Client | Policies attached to the access profile of the calling client. These run first and apply only to requests made with that profile's credentials. | Per-client rate limits, client-specific JWT checks, partner-level IP restrictions. |
Endpoint | Policies attached to a specific API operation. Run second, after client-level policies pass. | Request validation for a specific route, endpoint-level transformations, operation-specific access control. |
API Group | Policies attached to the collection (API Group). Run last, as the broadest baseline that applies to all traffic reaching that group. | CORS policy for all endpoints in the group, global rate limit, response transformation applied to every response. |
All three levels run on every matched request unless the chain is stopped early by a rejection at one of the levels.
Rejection and Chain Stopping
If any inbound policy — at any level — rejects a request, the chain stops at that point. Remaining policies are skipped, and the backing resource is never invoked. The caller receives the error response configured by the policy that rejected the request (commonly 400 for validation failures or 429 for rate limit exceeded).
Any counter or limit that was incremented for the rejected request is rolled back automatically, so a rejected call does not consume the caller's future allowance.
Ordering Within a Level
Within a single level — for example, when multiple policies are attached to one Endpoint — you control the execution sequence by dragging policies into the desired order in the policy settings panel. The platform runs them top-to-bottom as arranged.
The drag order applies independently at each level. The Client-level order, Endpoint-level order, and API Group-level order are each configured separately.
Notes
Attach broad baseline rules (CORS, a global rate limit) at the API Group level so they apply to all callers without repetition.
Narrow per-endpoint with operation-specific validation or transformation policies.
Use Client-level policies for entitlements that differ per consumer — a per-client rate limit is the most common example.
The first rejection in the chain stops all further evaluation — place the cheapest checks (IP control, rate limiting) before expensive ones (custom automation policies) so fast rejections avoid unnecessary processing.
A rejected request does not count against any limit — rollback is automatic and immediate.