Hoy lanzamos Private Endpoints. OpenRouter ya pone los modelos públicos que usa tu equipo detrás de una sola API. Ahora también puede servir los despliegues que solo tu equipo tiene. Si ejecutas un modelo afinado, un despliegue dedicado de un modelo público o una capacidad que has reservado con un proveedor, puedes enrutarlo a través de OpenRouter junto con todo lo demás del catálogo. Tu equipo conserva la API, el slug de modelo y las preferencias de enrutamiento que usa hoy. Los endpoints privados solo son visibles dentro de tu organización.
Private Endpoints es un complemento del plan Enterprise. Pide a tu representante de cuenta que lo habilite para tu organización, o habla con el equipo.
Qué puedes hacer con ello
Los modelos afinados y la capacidad reservada solían significar una segunda integración junto a OpenRouter. Ahora registras el despliegue como un endpoint privado y lo llamas a través de la API que ya utilizas, con proveedores públicos como respaldo opcional si se cae o alcanza su límite de tasa. Solo las organizaciones que apruebes pueden verlo, y nunca aparece en listas de modelos públicos, rankings, búsquedas, gráficos ni benchmarks.
Si tu organización tiene un despliegue dedicado de Azure de DeepSeek V4 Pro por ejemplo, puedes registrarlo como un endpoint privado para deepseek/deepseek-v4-pro y tus aplicaciones siguen llamando a ese slug. Para tu organización, se mueve al principio de la lista de proveedores por defecto, y Model Fallbacks, Provider Selection y el resto del enrutamiento funcionan igual que para cualquier proveedor. OpenRouter accede a él con tu clave de Azure a través de BYOK, por lo que Azure te factura directamente.
La capacidad reservada recibe el mismo tratamiento. Apunta un endpoint privado a ella y el tráfico de tu organización va allí primero por defecto. Cuando está limitada por tasa o no disponible, OpenRouter puede enviar el excedente a proveedores públicos, dentro de las preferencias de proveedor y la configuración de respaldo BYOK que hayas establecido.
Configurar un endpoint
Una vez que Private Endpoints está habilitado, un administrador de la organización registra el despliegue desde la página Private Endpoints de tu cuenta. El despliegue debe estar alojado por un proveedor que admitamos para BYOK, ya que OpenRouter accede a él con tu propia clave. También debe servir un modelo que ya esté en el catálogo de OpenRouter, ya que hereda el slug y las capacidades de ese modelo. Puedes adjuntar tu propia preciación para que el endpoint aparezca con precisión en los informes de costos, y declaras si el despliegue retiene los prompts.
Antes de que algo se enrute al nuevo endpoint, OpenRouter envía una solicitud real a través de la clave del proveedor guardada en uno de tus workspaces. Esa solicitud demuestra que la clave es aceptada, que el despliegue habla el formato compatible con OpenAI, que el streaming funciona, que el uso se devuelve para la facturación y que el ID del modelo coincide con lo que registraste. Una vez que pasa, activas el endpoint y los workspaces de tu organización pueden llamarlo por el slug del modelo. Hasta entonces permanece oculto y no puede ser llamado.
Gestionar endpoints desde código
Si ejecutas más de unos pocos endpoints, o mantienes tu infraestructura en código, puedes omitir la página de configuración. La Private Endpoints API cubre todo el ciclo de vida, desde registrar un borrador y ejecutar las comprobaciones de prueba hasta la activación, actualizaciones de precios, pausa y eliminación. Se autentica con una Management API keyde la organización, y una sola llamada de creación registra, prueba y activa un endpoint.
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>" }
}'Si las comprobaciones de prueba fallan, el borrador se conserva y devuelve las comprobaciones fallidas, para que puedas corregirlo e intentarlo de nuevo. El Idempotency-Key header hace que los reintentos sean seguros (una clave repetida devuelve el endpoint que creó la primera solicitud). El OpenRouter Terraform provider envuelve todo esto en un openrouter_private_endpoint resource, de modo que terraform apply registra, prueba y activa el endpoint y terraform destroy lo elimina.
Bueno saber
- Marcar un endpoint como privado no lo convierte en un endpoint de Zero Data Retention . Tu proveedor maneja los prompts exactamente como lo hacía antes, y OpenRouter registra la política de datos que declaras al registrar el despliegue.
- Un private endpoint puede usar In-Region Routing si OpenRouter puede deducir una región a partir de su dirección, o si tú declaras una durante la configuración. Las solicitudes a
us.openrouter.aioeu.openrouter.aise dirigen entonces a tu despliegue dentro de esa región. La guía de In-Region Routing enumera los proveedores compatibles. - Tu clave de proveedor debe guardarse en BYOK en cada workspace que llame al endpoint, y la solicitud de prueba durante la configuración también la necesita allí.
- Cada organización puede tener hasta 10 private endpoints por defecto, y los endpoints que todavía están en configuración cuentan para ese límite.
Primeros pasos
Private Endpoints es un complemento del plan Enterprise. Pide a tu representante de cuenta que lo habilite para tu organización, o habla con el equipo.
Una vez habilitado, un administrador de la organización puede añadir tu primer endpoint desde la página de Private Endpoints de tu cuenta o con una clave de Management API a través de la API de Private Endpoints.