OpenRouter launches Private Endpoints for fine-tuned models and reserved capacity
OpenRouter has launched Private Endpoints, an add-on to its Enterprise plan that lets organizations route their own fine-tuned models, dedicated deployments and reserved provider capacity through the same API they use for public models. The endpoints are visible only within the organization and can fall back to public providers if needed.
- OpenRouter launched Private Endpoints, an add-on to its Enterprise plan, on 10/14/2026.
- Organizations can route fine-tuned models, dedicated deployments and reserved capacity through the same API and model slugs.
- Private endpoints are visible only to approved organizations and never appear in public lists, rankings, search, charts or benchmarks.
- Public providers can serve as a backup when the private deployment is down or rate-limited.
- Each organization can have up to 10 private endpoints by default, and a private endpoint is not a Zero Data Retention endpoint.
One API for public and private deployments
OpenRouter already offers the public models a team uses behind a single API. According to the company, Private Endpoints extends that to deployments only a given team has access to: a fine-tuned model, a dedicated deployment of a public model, or capacity reserved with a provider.
Until now, OpenRouter says, fine-tuned models and reserved capacity meant a second integration next to OpenRouter. With the new feature, an organization registers the deployment as a private endpoint and calls it through the existing API, keeping its model slug and routing preferences. Public providers can serve as an optional backup if the private deployment goes down or hits its rate limit.
Only organizations the customer approves can see a private endpoint. It never appears in public model lists, rankings, search, charts or benchmarks.
OpenRouter gives an example: an organization with a dedicated Azure deployment of DeepSeek V4 Pro can register it for deepseek/deepseek-v4-pro, and its apps keep calling that slug. For that organization, the endpoint moves to the front of the provider list by default, while Model Fallbacks, Provider Selection and the rest of routing work as they do for any provider. OpenRouter reaches the deployment with the customer's Azure key through BYOK, so Azure bills the customer directly.
Reserved capacity is handled the same way. Traffic from the organization goes to the private endpoint first by default. When it is rate-limited or unavailable, OpenRouter can send the overflow to public providers, within the provider preferences and BYOK fallback settings the customer has set.
Setup, testing and the API
Once the feature is enabled, an organization admin registers the deployment on the Private Endpoints page in the account. Two requirements apply. The deployment must be hosted by a provider supported for BYOK, since OpenRouter uses the customer's own key. It must also serve a model already in the OpenRouter catalog, because the endpoint inherits that model's slug and capabilities.
Admins can attach their own pricing so the endpoint appears accurately in cost reporting, and they declare whether the deployment retains prompts.
Before any traffic is routed, OpenRouter sends one real request through the provider key saved in one of the organization's workspaces. According to the company, this confirms that:
- the key is accepted
- the deployment speaks the OpenAI-compatible format
- streaming works
- usage comes back for billing
- the model ID matches what was registered
After the test passes, the admin activates the endpoint and workspaces in the organization can call it by model slug. Until then it stays hidden and cannot be called.
Teams with many endpoints or infrastructure kept in code can use the Private Endpoints API instead. It covers the full lifecycle: registering a draft, running the test checks, activation, pricing updates, pausing and deletion. It is authenticated with an organization Management API key, and a single create call registers, tests and activates an endpoint. If the checks fail, the draft is kept and returned with the failed checks so it can be patched and retried. An Idempotency-Key header makes retries safe, since a repeated key returns the endpoint created by the first request. The OpenRouter Terraform provider wraps this in an openrouter_private_endpoint resource, so terraform apply registers, tests and activates an endpoint and terraform destroy removes it.
Data handling, limits and availability
OpenRouter stresses that marking an endpoint private does not make it a Zero Data Retention endpoint. The provider handles prompts exactly as before, and OpenRouter records the data policy the customer declares at registration.
A private endpoint can use In-Region Routing if OpenRouter can work out a region from its address, or if one is declared during setup. Requests to us.openrouter.ai or eu.openrouter.ai are then routed to the deployment inside that region. The supported providers are listed in the In-Region Routing guide.
The provider key must be saved under BYOK in each workspace that calls the endpoint, and the setup test request needs it there too. By default each organization can have up to 10 private endpoints, and endpoints still being set up count toward that limit.
What it means for Enterprise customers
For organizations that already run fine-tuned models or reserved capacity, the change removes the need for a separate integration alongside OpenRouter. Teams can keep one API, one set of slugs and their existing routing rules, with public providers as a safety net.
Private Endpoints is available as an add-on to the Enterprise plan. Customers need to ask their account representative to enable it. After that, an organization admin can add the first endpoint from the Private Endpoints page or through the Private Endpoints API with a Management API key.
