Fine-tuned models no longer need a second integration: OpenRouter private endpoints keep your team's deployments on the same model slug
Synopsis
OpenRouter launched Private Endpoints, letting enterprises register fine-tuned models, dedicated deployments, or reserved capacity as endpoints visible only inside their organization, while continuing to call them through the existing API, model slug, and routing preferences. Previously such deployments meant maintaining a second integration alongside OpenRouter; now an organization's traffic prefers the endpoint by default and can fall back to public providers under existing preferences when it is rate-limited or unavailable. Endpoints must be hosted by a BYOK-supported provider and serve a model already in the catalog, and activation requires one real request that verifies the key, streaming, usage reporting, and model ID.
Interpretation
A team's own fine-tuned models and reserved capacity can now join the single API the team already uses, with no change to how apps call them. Fine-tuned models and reserved capacity previously meant a second integration next to OpenRouter. Once registered as a private endpoint, apps keep calling the same model slug, the endpoint moves to the front of the provider list for that organization by default, and Model Fallbacks and Provider Selection work as for any provider.
A private endpoint is visible only to approved organizations and never appears in public model lists, rankings, search, charts, or benchmarks. Models in the public catalog are visible to all users, while a team's own deployment was previously outside what OpenRouter could call. For a dedicated Azure deployment of DeepSeek V4 Pro, registering it as a private endpoint for deepseek/deepseek-v4-pro lets OpenRouter reach it with your Azure key through BYOK, so Azure bills you directly.
An endpoint must pass a real-request connectivity check between registration and activation, staying hidden and uncallable until it does. Connecting a self-hosted deployment to a unified API previously required confirming the key, protocol, and billing path yourself. OpenRouter sends one real request through the provider key saved in one of your workspaces, proving the key is accepted, the deployment speaks the OpenAI-compatible format, streaming works, usage comes back for billing, and the model ID matches what you registered.
The endpoint lifecycle can be managed entirely from code rather than the settings page. Configuring a self-hosted deployment previously meant manual work in a console. The Private Endpoints API covers registering a draft, running test checks, activation, pricing updates, pausing, and deletion, authenticated with an organization Management API key, and one create call registers, tests, and activates; the Terraform provider wraps this in an openrouter_private_endpoint resource.
Perspective
The capability targets organizations on the Enterprise plan as an add-on enabled by an account representative, after which an organization admin registers endpoints from the Private Endpoints page or through the Management API. It requires the deployment to be hosted by a BYOK-supported provider and to serve a model already in the OpenRouter catalog, since the endpoint inherits that model's slug and capabilities. Each organization can have up to 10 private endpoints by default, and endpoints still being set up count toward that limit.
Marking an endpoint private does not make it a Zero Data Retention endpoint: prompts are handled by the provider exactly as before, and OpenRouter records the data policy declared at registration. Each workspace that calls the endpoint must save the provider key under BYOK, and the setup test request needs it there too. In-Region Routing applies only when OpenRouter can work out a region from its address or you declare one during setup.