Overview

How it works

The Gateway sits between your client and the upstream model providers. Every request flows through the same four stages, whichever SDK format you use.

1

Authenticate

The project API key is validated and then stripped before anything is forwarded upstream — providers never see your ATP key. Missing, disabled, or expired keys are rejected with 401. See Authentication.

2

Authorize the model

The requested model must be on the project's allowed list. If it isn't, the request is rejected with 403 before reaching any provider — model access is enforced per project, not per key. See Models.

3

Route to a provider

The Gateway picks a provider from the pool configured for that model and fails over to another on a provider error or timeout, so one model id stays stable across providers. See Provider routing & fallbacks.

4

Meter and bill

Input and output tokens are metered and charged in credits against the project's balance. If the balance is exhausted the request is rejected with 402. See How credits work.

What the Gateway changes — and what it doesn't

The Gateway translates authentication and routing, but leaves your request and response bodies in the shape your SDK already expects.

Handled for youLeft unchanged
Key validation and provider authRequest body schema (per SDK format)
Model access checksResponse body schema
Provider selection and fallbackStreaming event sequence
Metering and credit deductionModel behavior and outputs

Because the wire formats pass through unchanged, migrating an existing OpenAI, Anthropic, or Gemini integration is usually just a base-URL and key change.