Absorb behind your API gateway
Absorb runs behind the gateway you already operate. The gateway authenticates the caller and shapes traffic, and Absorb decides which operations exist for the agent behind it. Each release ships a configuration for Kong, Apigee and MuleSoft.
Absorb behind Kong
A declarative, DB-less configuration with three routes, 900 second timeouts, rate limiting and a correlation ID.
Absorb behind Apigee
A proxy bundle with response streaming enabled, so server-sent events are not buffered.
Absorb behind MuleSoft
A Mule 4 flow that passes Absorb error bodies through instead of converting them to exceptions.
Requirements every gateway must meet
These are what actually break integrations. The shipped configurations for Kong, Apigee and MuleSoft meet all six.
| Requirement | Consequence if missed |
|---|---|
Pass Authorization through unchanged | Agents cannot authenticate |
Pass Mcp-Session-Id both ways | Sessions break after initialize |
No buffering on /sse | The agent hangs waiting for the stream |
| Read timeout above the approval wait | Held calls time out at the gateway |
Allow DELETE on the MCP path | Clients cannot end sessions |
| Preserve the path after the stripped prefix | Requests hit the wrong route, unless --path is set to match |
Other gateways and no gateway
Any gateway that meets the six requirements above works. Without a gateway, Absorb runs as a sidecar in the same pod as the API, as a service behind your ingress, or as a single binary on a virtual machine, with a Helm chart for Kubernetes.
How a gateway and Absorb divide the work is covered in Absorb vs API gateways.
Compile your own API and assess the result
Send a specification. We will show the tools it produces, the operations it withholds, and the document your security function would review.