Skip to main content
When models run across multiple providers, each provider has its own credentials and access controls. Baseten Frontier Gateway gives your teams, applications, or customers one OpenAI-compatible base URL for models hosted on Baseten, third-party providers, and your own OpenAI-compatible servers. Use groups, federated API keys, and per-model limits to control who can call each model. Each stable model slug routes to a Dedicated deployment, a Baseten Model API, Anthropic, OpenAI, Google Vertex AI, or an OpenAI-compatible HTTPS server.
To enable Frontier Gateway for your workspace, talk to us.

​
How Frontier Gateway works

Frontier Gateway separates model routing from access control. Endpoints map stable model slugs to upstream targets. Groups define which slugs callers can use and the rate and usage limits applied to their keys. An endpoint is a routing slug (for example my-org/glm-5.2) and the target it points to. The target can be a Dedicated deployment, a Baseten Model API, a third-party provider, or a custom OpenAI-compatible server. The slug stays the same when you move it between targets, so callers do not need to change their requests. You create, re-point, and delete endpoints yourself through the REST API. For more information, see Endpoints. Each group owns an external identifier (metadata.external_entity_id), the set of model slugs its callers can use, and the rate and usage limits enforced on every call. Groups can nest under a parent group, and limits flow down the tree according to the group’s limit_enforcement mode. You then mint one or more API keys under any group; callers use those keys. Every key inherits the effective configuration of its group, so rotating credentials never changes the group’s controls. When a request hits the gateway with one of your federated keys, Baseten validates the key, walks up the owning group’s hierarchy to compute effective limits, and enforces them per model slug. Valid requests route to the target the slug’s endpoint points to, and the response returns to the caller. For each request, Baseten emits a signed billing event out-of-band to your webhook endpoint with token counts and request metadata, so your billing pipeline runs independently of the inference path.

​
Key features

  • Self-service endpoints: Map a routing slug to a target, re-point it, or retire it through the REST API. For more information, see Endpoints.
  • Baseten, third-party, and custom targets: Route a slug to a Dedicated deployment, a Baseten Model API, a third-party provider, or a custom OpenAI-compatible server. Groups, limits, keys, and billing webhooks work the same way for every target. For more information, see Supported targets.
  • Hierarchical groups: Model your organization however your billing structure fits, whether that’s orgs and projects, plans and customers, or tenants and seats. Groups carry the model set and the limits; keys hang off groups and inherit them. For more information, see Manage groups and API keys.
  • Two inheritance modes: Pick an enforcement mode per hierarchy. An independent hierarchy lets children override their parents and meters each group’s usage separately; a cascading hierarchy makes a group’s usage count against every ancestor at once. For more information, see Inheritance modes.
  • Per-group, per-model rate and usage limits: Configure TOKEN or REQUEST limits on each group, scoped per model slug. Every key minted under the group inherits the group’s effective limits.
  • Billing webhooks: Receive signed per-request token usage events you can pipe into Stripe, Orb, or your own billing system. For more information, see Billing webhooks.
  • White-label routing (limited availability): Use a custom domain for inference traffic. Contact your onboarding engineer for current availability.

​
Frontier Gateway versus Model APIs

Frontier Gateway and Model APIs are distinct products with different authentication and call paths. Choose Frontier Gateway when you need a shared access and policy layer; choose Model APIs to call Baseten-hosted open models directly.

​
Distribute models through Baseten

Use Frontier Gateway when you operate the access and policy layer for your teams, applications, or customers. To publish a custom-trained model for Baseten customers to deploy, use the Distribution Platform. Compare both paths in Baseten for Model Labs.

​
Next steps

  • Get started: Walk through your first endpoint, group, API key, and inference call.
  • Endpoints: Map routing slugs to supported targets and manage them through the REST API.
  • Manage groups and API keys: Create groups, build a hierarchy, and mint or revoke keys.
  • Rate and usage limits: Control per-group, per-model usage and pick an inheritance mode.
  • Billing webhooks: Meter usage by consuming signed per-request events.