Skip to main content
Frontier Gateway provides one OpenAI-compatible base URL for models hosted on Baseten, third-party providers, and custom OpenAI-compatible servers. Use it when teams, applications, or customers need access to models across several providers. Groups, federated API keys, and per-model limits control which models each caller can use. A stable model slug routes requests to a Dedicated deployment, Baseten Model API, supported third-party provider, or OpenAI-compatible HTTPS server.
To enable Frontier Gateway for your workspace, talk to us.

​
How Frontier Gateway works

Frontier Gateway separates routing from access control. Endpoints map stable model slugs to upstream targets. Groups define which slugs callers can use and which rate and usage limits apply. 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 has an external identifier (metadata.external_entity_id), an allowed set of model slugs, and rate and usage limits. Groups can nest beneath a parent, with limits inherited according to limit_enforcement. API keys created under a group inherit its effective configuration, so you can rotate a key without changing those controls. For each request, Baseten validates the federated key, calculates effective limits from the group’s hierarchy, and enforces them for the requested model slug. The gateway then sends an allowed request to the endpoint’s target. Baseten separately sends a signed billing event with token counts and request metadata to your webhook.

​
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.