What is the difference between an API Filter and a Response Transformer?

An API Filter runs your own automation. An inbound API Filter runs before the backing resource is invoked and can accept, reject, or modify the incoming request. An outbound API Filter runs after the backing resource returns and can modify the response. A Response Transformer is a built-in outbound policy that modifies the response using a declarative, field-by-field configuration, with no automation required. Use an API Filter when you need custom logic; use Response Transformer for straightforward response-shaping on the way out.

Can an API Filter reject a request?

Yes. An inbound API Filter automation can return a reject decision, which immediately stops the policy chain and returns an error to the caller — the backing resource is never invoked. API Filters can also run on the outbound side: an outbound API Filter receives the response after the backing resource returns and can change it.

What data does my automation receive?

An inbound API Filter automation receives the full incoming request — headers, body, query parameters, path, HTTP method, and caller metadata. An outbound API Filter automation runs after the backing resource returns and receives the response, which it can modify.

How is an API Filter different from a Request Transformer?

A Request Transformer modifies specific request fields — headers, body, parameters — using a declarative field-by-field configuration with no custom code. An API Filter runs a full automation, giving you access to external systems, conditional logic, and any transformation the platform can express. Use Request Transformer for straightforward field operations; use an API Filter when you need to call another system or apply complex business logic.

What is the difference between API Filter and Response Transformer, and what status codes can a policy failure return?

API Filter is the custom-logic policy type — it runs your own automation on the inbound request or, for an outbound API Filter, on the response. Response Transformer is a built-in outbound policy type — it reshapes the response declaratively, without a custom automation. If an API Filter automation fails or rejects without a status, the caller gets 400. Other policy types enforcing their own limits may return 403 (authorization) or 429 (rate limit) instead.

Run your own automation as part of the API request pipeline to enforce governance rules that built-in policy types cannot cover.

Overview

An API Filter policy connects an automation you have built to the API request pipeline. An API Filter can be inbound or outbound. An inbound API Filter runs before the request reaches the backing resource. Your automation decides whether to proceed or reject the call and can modify the request in any way your business logic requires. An outbound API Filter runs after the backing resource returns. It receives the response and can change it. You don't create this policy by hand: the platform creates an API Filter policy for you when you deploy an automation built on the inbound or outbound API Filter trigger interface. The Policies list shows these as API Filter (Inbound) and API Filter (Outbound).

Use API Filters when standard governance needs — rate limiting, CORS, JWT validation, IP control — are not enough. Common scenarios include bespoke authorization against an internal system or dynamic request enrichment from a database.

API Filter

An inbound API Filter 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.

An outbound API Filter runs after the backing resource returns. Your automation receives the response and can modify it before it reaches the caller.

Use API Filters for custom authorization checks, dynamic header enrichment before the backing automation runs, or any pre-processing logic specific to your organization.

Setting Up an API Filter

Build a callable automation whose trigger uses the inbound or outbound API Filter interface.
Deploy the automation. The platform creates an API Filter policy with the automation's name. Renaming the automation renames the policy.
Attach the policy to an API Group, an API, or an access profile.

The policy has one field, Automation — the callable automation it runs. The automation receives the full request context and must return a proceed or reject decision along with any request modifications.

How It Works

Policy chain reached — the platform reaches the API Filter's position in the policy execution order.
Automation invoked — the selected automation runs, receiving the full request context.
Decision returned — the automation returns a proceed or reject signal, along with any modifications to the request 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.

Attaching the Policy

Once the platform has created the policy, attach it to one or more API Groups, APIs, or Access Profiles from their respective policy settings. Execution order across levels is fixed — access profile, then API, then API Group — so you can only drag policies into a new order within the same level when multiple policies are applied there. An inbound API Filter policy runs before the backing resource on every matched call. An outbound API Filter policy runs after it.

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 API Filters for business-specific logic that the built-in types cannot express.
Keep automation logic fast — an API Filter runs synchronously on every matched API call, and its latency is added to the caller's response time.
If the automation fails, the call is rejected with 400 ("Failure in API policy enforcement"). If it returns proceed = false without setting a status, the caller also gets 400. Test the automation thoroughly before attaching it to a production API Group.
If the automation is undeployed or deleted, the API Filter policy is skipped — every call is let through without running the check. Treat this as a security gap: keep the automation deployed while the policy is attached, especially for authorization logic. Deleting the automation also deletes the policy.
An API Filter automation has access to the full incoming request — headers, body, query parameters, path, method, and caller metadata.

Custom Policy