The no-proxy model

Apiable is not a proxy. Your API traffic runs on your own gateway, the same way it runs without Apiable. Apiable is a control plane that configures your gateway through its management API, then steps out of the request path. This page explains how that works and what coupling does to data flow.

Does Apiable proxy my API traffic?

No. Apiable does not sit between your consumers and your gateway. At request time, a consumer calls your gateway directly, your gateway validates the credential or token, and your backend responds. Apiable is the control plane that set that gateway up.

The request path with Apiable is the same path you already have:

1. Your consumer sends a request to your gateway with their API key or OAuth token.
2. Your gateway validates the credential and enforces the plan's limits and scopes.
3. Your gateway forwards the request to your backend.
4. Your backend responds through your gateway back to the consumer.

Apiable is not a step in that list. It configured the gateway ahead of time and it runs the portal where the consumer got their credentials.

What does Apiable do if it is not in the request path?

Apiable configures your gateway out of band. It calls your gateway's management API to read your APIs, create plans, and provision each subscriber's API key or OAuth client. Those are control-plane operations, separate from live API traffic.

On Amazon API Gateway, for example, Apiable uses the AWS API Gateway management client against your own AWS account to list your REST APIs and stages, deploy plans, rotate a subscription secret, enable or disable a key, and read usage. The same pattern applies per gateway through a gateway-specific adapter. None of this puts Apiable in the path of a live API call.

What is the difference between gateway-bound and catalog-bound for data flow?

A plan is either gateway-bound or catalog-bound. Gateway-bound plans provision credentials on one gateway and run traffic there. Catalog-bound plans never push to a gateway. They group catalog APIs as portal metadata and rely on scopes for access.

In the code, a gateway-bound plan binds to a single gateway and creates runtime credentials on it. A catalog-bound plan has no gateway binding and no rate limit. Catalog API entries are metadata references that explicitly cannot be pushed to a gateway. See APIs and coupling for how you choose between them on a plan.

Where does Apiable create my API keys and OAuth clients?

On your own gateway and your own authorization server. For a gateway-bound plan, Apiable provisions the subscriber's API key or OAuth client on the gateway. For scope-based access, Apiable registers an OAuth client per subscription on your authorization server through Dynamic Client Registration.

A gateway resolves OAuth one of two ways. It can issue and validate tokens natively, or it can bind an external Authorization Server such as Keycloak or Auth0 that issues the tokens. Either way, the gateway validates the token at request time, not Apiable. See Authorization Servers and Scopes.

What does no-proxy mean for data residency and latency?

Your live API payloads stay on your infrastructure, and your API calls take the same network path they take without Apiable. Apiable exchanges configuration and management calls with your gateway, not your API request and response bodies.

Because Apiable is not a hop in the request path, it adds no request-time latency to your API calls, and your API payload data is not routed through Apiable. For where Apiable's own control plane and API Portal run, and to confirm specifics for your deployment, see Hosting and infrastructure and contact Apiable.

Where to next