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.
Client → Endpoint → API Group
Policies run in this sequence on every request:
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 — policies are evaluated according to the configured order where supported. Confirm and adjust the order in the policy settings panel for that level.
Where ordering is configurable, it applies independently at each level — check the policy settings panel for the Client, Endpoint, and API Group levels 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 cheap checks such as rate limiting before expensive ones (custom automation policies) so fast rejections avoid unnecessary processing. The response cache check happens after inbound policies run: when a matching cached response exists, the backing resource is skipped, but Client, Endpoint, and API Group policies still run first. IP-based access checks run before any policy in the chain.
A rejected request does not count against any limit — rollback is automatic and immediate.