Private Endpoints

OpenRouter sells one API that reaches many models from many hosting providers. Private Endpoints, an add-on to its Enterprise plan, lets an organization add a deployment that only it has, such as a fine-tuned model, a dedicated copy of a public model, or capacity it has reserved with a provider, and call it through that same API (OpenRouter). The endpoint is visible only within the organization and never appears in OpenRouter's public model lists, rankings or benchmarks.

The key constraint is that the deployment must serve a model already in OpenRouter's catalog and be hosted by a provider OpenRouter supports for bring-your-own-key access, because OpenRouter reaches it with the organization's own provider key and the endpoint inherits that model's existing name and capabilities. In OpenRouter's example, a company with its own Azure deployment of DeepSeek V4 Pro registers it under the existing deepseek/deepseek-v4-pro name, so its apps keep calling that name, the private deployment is tried first by default, and Azure bills the company directly. If the deployment is rate-limited or down, traffic can overflow to public providers within the fallback settings the team has chosen. Before an endpoint can take traffic, OpenRouter sends one real request to confirm the key works, the deployment speaks the OpenAI-compatible request format, streaming and usage reporting work, and the model ID matches.

Private here means hidden from other customers, not a privacy guarantee for prompts. OpenRouter says marking an endpoint private does not make it a zero-data-retention endpoint: the provider handles prompts exactly as before, and OpenRouter records whatever data policy the organization declares when it registers the deployment.