Key concepts
The object model behind Gateway: organizations, projects, keys, policies, and budgets
Gateway has a small object model, but several objects come in scoped variants that look alike. This page defines each one once.
Organization
Your account. Every key, project, policy, and budget belongs to one organization, and spend rolls up to it.
Project
The unit you organize traffic by: a team, product, or environment. A project can carry its own routing policy, budget, and compression settings, and its spend is reported separately. Its ID is a UUID shown on its Overview tab. See Projects for how requests attach to one.
API keys: the three types
Any key can carry a spend limit; see Management API keys.
Routing policy
The rules that pick a provider and model per request. A policy attaches to an Embedded Routing customer, a project, or the organization (as the default), and the narrowest applicable one wins. Policies never attach to individual keys; to give one key its own routing, scope the key to a project. See Routing policies.
Customer vs customer identifier
Two unrelated things share a word:
- A Customer is an Embedded Routing object: if you resell Gateway, each of your end customers is provisioned as one, with its own policies, credentials, and budget. A Customer is to your end customer what a project is to your own team.
- The customer identifier on blocklist rules is a plain string on the request. No provisioned object required.
Tags
Org-defined key-value pairs attached to requests, used for tag-based routing rules and spend breakdowns. Per-request metadata, not configuration.
Budgets: the four scopes
All four are independent; the first one exhausted blocks the request. See Budgets.
Model names
Models are addressed as provider/model (anthropic/claude-opus-5, openai/gpt-5.5). A bare name (gpt-5.5) is resolved server-side and rejected if ambiguous. Omitting model, or sending default_routing, hands the choice to your routing policy. Browse the catalog with GET /v1/models or the models tab.