Run your own automation as part of the API request pipeline to enforce governance rules that built-in policy types cannot cover.
Overview
A Custom Policy connects an automation you have built to the request pipeline. When the API Manager receives a call, it runs your automation either before the request reaches the backing resource (API Filter) or after the resource returns a response (Outbound API Policy Filter). Your automation decides whether to allow the call to proceed and can modify the request or response in any way your business logic requires.
Use custom policies when standard governance needs — rate limiting, CORS, JWT validation, IP control — are not enough. Common scenarios include bespoke authorization against an internal system, dynamic request enrichment from a database, or response redaction based on caller context.
Custom Policy configuration panel showing Filter Type and Automation fields
API Filter and Outbound API Policy Filter
A Custom Policy runs in one of two directions, selected when you create the policy:
API Filter
An API Filter is an inbound policy — it runs before the backing resource is invoked. Your automation receives the incoming request including headers, body, query parameters, and caller metadata. It returns whether to proceed or reject:
If it returns proceed, the request (with any modifications the automation applied) continues to the next policy in the chain or to the backing resource.
If it returns reject, the chain stops immediately. The backing resource is never invoked, and the caller receives the error response your automation specifies.
Use API Filters for custom authorization checks, dynamic header enrichment before the backing automation runs, or any pre-processing logic specific to your organization.
Outbound API Policy Filter
An Outbound API Policy Filter is an outbound policy — it runs after the backing resource has produced a response. Your automation receives both the original request and the response (body, status code, and headers). It can modify what is returned to the caller but cannot reject a completed invocation.
Use Outbound API Policy Filters for response masking or redaction based on caller context, adding computed metadata to the response body, or removing sensitive fields before the response leaves the gateway.
Field Reference
Field | Description |
|---|---|
Policy Name * | A unique identifier used across logs, dashboards, and policy attachment configurations. |
Tags | Custom labels to organize and filter the policy by environment, team, or functionality. |
Filter Type * | The direction the automation runs. Select API Filter to intercept the incoming request before the backing resource, or Outbound API Policy Filter to process the response after the backing resource returns. |
Automation * | The callable automation to invoke. The automation receives the request context (and, for Outbound API Policy Filters, the response context) and must return a proceed or reject decision along with any request or response modifications. |
How It Works
Policy chain reached — the platform reaches the Custom Policy's position in the policy execution order.
Automation invoked — the selected automation runs, receiving the full request context (and response context, for Outbound API Policy Filters).
Decision returned — the automation returns a proceed or reject signal, along with any modifications to the request or response it wants to apply.
Chain continues or stops — a proceed signal passes the modified request to the next policy or to the backing resource. A reject signal stops the chain and returns the error to the caller.
Response path — for Outbound API Policy Filters, the modified response is passed back through the remainder of the outbound chain before being returned to the caller.
Attaching to an API Group
Once a Custom Policy is created, attach it to one or more API Groups, Endpoints, or Access Profiles from their respective policy settings. Drag policies into the desired execution order when multiple policies are applied at the same level. API Filter policies run before the backing resource on every matched call; Outbound API Policy Filters run after.
Notes
Use built-in policy types (rate limiting, CORS, JWT validation, IP control) for standard API gateway concerns — they are optimized for those cases. Reserve custom policies for business-specific logic that the built-in types cannot express.
Keep automation logic fast — a Custom Policy runs synchronously on every matched API call, and its latency is added to the caller's response time.
If the automation errors or times out, the request is rejected with a server error. Test the automation thoroughly before attaching it to a production API Group.
An API Filter automation has access to the full incoming request; an Outbound API Policy Filter automation has access to both the request and the response.