Summary: On October 14, 2026, OpenRouter launched Private Endpoints, an Enterprise plan add-on that lets you register your own model deployments — fine-tunes, dedicated capacity, reserved providers — and route them through the same API your apps already call. The endpoint inherits a catalog model’s slug, stays invisible outside your organization, and falls back to public providers when it’s saturated. For builders, this closes the gap between “our gateway handles the public models” and “our fine-tunes live in a second integration.”
The problem it removes
If you ran a fine-tuned model or a dedicated Azure deployment, you typically maintained a parallel integration next to your gateway. That meant separate auth, separate retry logic, and no shared failover story.
Private Endpoints collapse that. Per OpenRouter’s announcement, you register the deployment as a private endpoint under an existing catalog slug — say a dedicated Azure deployment of DeepSeek V4 Pro under deepseek/deepseek-v4-pro — and your apps keep calling the same model name. The endpoint moves to the front of your provider list by default, and Model Fallbacks and Provider Selection work as they would for any public provider. If it rate-limits or goes down, overflow can spill to public providers within your BYOK fallback settings.
OpenRouter reaches your deployment with your own provider key, so the upstream bills you directly. Visibility is org-scoped: private endpoints never appear in public model lists, rankings, search, or benchmarks.
How setup actually works
The flow is more rigorous than most “add a base URL” forms. An org admin registers the deployment, then OpenRouter sends one real request through the provider key saved in one of your workspaces. That probe verifies the key is accepted, the endpoint speaks OpenAI-compatible format, streaming works, usage data returns for billing, and the upstream model ID matches what you registered. Nothing routes to the endpoint until it passes.
Registration also asks you to attach pricing — so the endpoint shows up correctly in cost reporting — and to declare whether the deployment retains prompts.
If you manage infrastructure as code, the Private Endpoints API covers the full lifecycle with a Management API key: one create call registers, tests, and activates. Failed checks keep the draft and report back what broke. There’s also a Terraform resource, openrouter_private_endpoint, so terraform apply and terraform destroy handle the whole thing.
curl https://openrouter.ai/api/v1/private-endpoints \
-H "Authorization: Bearer $OPENROUTER_MANAGEMENT_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: gpt-4o-prod" \
-d '{
"model_permaslug": "openai/gpt-4o-2024-08-06",
"provider_slug": "openai",
"base_url": "https://api.openai.com/v1",
"upstream_model_id": "gpt-4o-2024-08-06",
"pricing": { "prompt": "0.0000025", "completion": "0.00001" },
"activate": { "workspace_id": "<workspace-id>" }
}'Tradeoffs worth knowing before you migrate
A few details change how you should plan:
- Privacy is not the same as data policy. Marking an endpoint private doesn’t make it Zero Data Retention. Your provider still handles prompts exactly as before; OpenRouter just records the policy you declare.
- Region routing is conditional. A private endpoint can use In-Region Routing only if OpenRouter can infer a region from its address or you declare one at setup.
- BYOK per workspace. Each workspace calling the endpoint needs the provider key saved, and the test request needs it too.
- A soft cap of 10 endpoints per organization, and drafts count against it.
Where this fits in your stack
I’ve argued before that the value of a routing layer is what your app stops owning — failover, provider preferences, cost attribution (see my piece on cheap-first routing). Private Endpoints extend that boundary to deployments you control. The practical consequence: a fine-tune stops being a special case in your codebase and becomes one more entry in your provider ordering.
The constraint to weigh is the Enterprise plan requirement and the BYOK dependency — if your deployment isn’t hosted by a BYOK-supported provider, or serves a model outside the OpenRouter catalog, this path isn’t available yet. If both check out, the Terraform route is the fastest way to make your fine-tune a first-class citizen in your existing routing config.