URL base de la API de OpenAI (2026): endpoints directos y compatibles

URL base de la API de OpenAI (2026): endpoints directos y compatibles

Respuesta rápida: la URL base oficial de la API de OpenAI es https://api.openai.com/v1. Úsala como base_url o baseURL del SDK y deja que este añada la ruta del recurso. Algunos endpoints completos habituales son https://api.openai.com/v1/responses y https://api.openai.com/v1/chat/completions.

Para el gateway de Flatkey compatible con OpenAI, usa https://router.flatkey.ai/v1 como URL base. El endpoint correspondiente de chat completions es https://router.flatkey.ai/v1/chat/completions. No pegues la ruta completa /chat/completions en un campo del SDK que solo espera una URL base.

Tabla de URL base de la API de OpenAI

URL base frente a endpoint: la diferencia

Una URL base es el prefijo compartido que se configura una sola vez en un SDK. Un endpoint es la ruta completa de una operación de la API. Confundirlos provoca los fallos de integración más habituales:

• 404 Not Found: has proporcionado una ruta incorrecta o has duplicado /v1.
• 401 Unauthorized: la clave no pertenece a la URL base a la que estás llamando.
• /v1/v1/...: tanto la URL base configurada como el código del cliente han añadido /v1.
• .../chat/completions/chat/completions: se ha pasado un endpoint completo donde el SDK solo esperaba la URL base.

Usa una única fuente de referencia para la URL base, guarda las claves en variables de entorno y realiza una pequeña solicitud a /models o de chat antes de migrar el tráfico de producción.

Qué cambia con un gateway de API compatible con OpenAI

El cambio principal es operativo, no conceptual.

Por eso los equipos buscan un gateway de API compatible con OpenAI. No están pidiendo un nuevo formato de prompt. Buscan reducir el riesgo de tener que reescribir código.

Usa esta lista de comprobación de migración antes de modificar el entorno de producción

La forma más segura de adoptar un gateway de API compatible con OpenAI es tratarlo como un cambio de integración controlado, no como un proyecto de abstracción generalizado.

1. Enumera los endpoints exactos de OpenAI que usas actualmente. La mayoría de los equipos cree que usa «la API de OpenAI» cuando en realidad utiliza un subconjunto más reducido, como chat completions, responses, embeddings o generación de imágenes.
2. Confirma qué llamadas deben permanecer sin cambios en el código de la aplicación. Esto ayuda a mantener un alcance realista y respalda la afirmación de que se trata de una «migración mínima».
3. Comprueba si tu SDK actual ya admite una URL base personalizada. Los clientes oficiales actuales de OpenAI para Python y Node la admiten.
4. Elige primero un flujo de trabajo en el entorno de pruebas. Empieza por la ruta que ya se ajuste a una estructura de solicitud estándar de OpenAI.
5. Verifica que los modelos de destino estén disponibles antes del despliegue. No te bases en capturas de pantalla antiguas ni en suposiciones desactualizadas sobre el catálogo.
6. Documenta la regla de respaldo. Quienes revisen la integración deben saber si la ruta puede cambiar de modelo, bloquearse ante un fallo o poner las solicitudes en cola.
7. Aprueba la salvedad sobre compatibilidad. El texto que publiques debe decir «compatible con OpenAI» para el conjunto de solicitudes admitidas, no «totalmente idéntico a OpenAI».

Esta lista de comprobación es lo que hace que un gateway de API compatible con OpenAI resulte creíble en una revisión para producción.

Ejemplos de código con cambios mínimos

Los SDK oficiales actuales de OpenAI ya documentan la compatibilidad con URL base personalizadas. Esa es la razón técnica por la que un gateway de API compatible con OpenAI puede facilitar una migración con poca fricción cuando conserva la estructura de solicitud de estilo OpenAI que ya utilizas.

Ejemplo en Python

from openai import OpenAI

client = OpenAI(
    api_key="sk-fk-your-flatkey-key",
    base_url="https://router.flatkey.ai/v1",
)

response = client.chat.completions.create(
    model="gpt-5.4-mini",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "Return a one-line health check."},
    ],
)

print(response.choices[0].message.content)

Ejemplo de Node

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

const response = await client.chat.completions.create({
  model: "gpt-5.4-mini",
  messages: [
    { role: "system", content: "You are a concise assistant." },
    { role: "user", content: "Return a one-line health check." },
  ],
});

console.log(response.choices[0].message.content);

Ejemplo de cURL

curl -X POST "https://router.flatkey.ai/v1/chat/completions" \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4-mini",
    "messages": [
      { "role": "user", "content": "Return a one-line health check." }
    ]
  }'

Para muchos equipos, esta es la primera prueba de que una pasarela de API compatible con OpenAI no tiene por qué implicar reescribir el cliente. La restricción importante es que el flujo de trabajo elegido debe ajustarse a la superficie de solicitudes compatible.

Qué verificar antes de afirmar que la migración es «inmediata»

Aquí es donde la mayoría de las páginas sobre pasarelas de API compatibles con OpenAI se vuelven imprecisas. «Inmediata» es un término demasiado amplio si no se define el límite.

Use esta tabla durante la revisión:

Una pasarela de API compatible con OpenAI es valiosa cuando estas comprobaciones se superan con menos fricción que las migraciones independientes de proveedores.

Una secuencia práctica de despliegue

Esta es la ruta de despliegue más limpia para una pasarela de API compatible con OpenAI cuando se desean cambios mínimos de código:

1. Haga inventario de la ruta de llamadas actual. Registre la versión actual del SDK, la familia de endpoints, los ID de modelo, la configuración de streaming y las suposiciones de reintento.
2. Cambie una URL base en el entorno de ensayo. Mantenga primero el mismo patrón de cliente. No combine esto con cambios no relacionados en prompts o modelos.
3. Mantenga un modelo aprobado para la primera prueba. El primer criterio de éxito es la compatibilidad de transporte, no una cobertura amplia de modelos.
4. Ejecute comprobaciones de forma de respuesta y de error. Compare las salidas, los códigos de estado, las expectativas de latencia y el comportamiento de registro.
5. Revise la política de enrutamiento de modelos. Decida si la ruta queda fijada a un modelo, puede conmutar por error a una clase equivalente o debe fallar de forma cerrada.
6. Amplíe solo después de confirmar el catálogo activo. El 15 de julio de 2026, la fuente pública de precios de Flatkey mostraba 170 filas totales y 95 filas disponibles, pero el despliegue en producción sigue requiriendo la validación exacta del modelo el día del lanzamiento.

Esa secuencia es lo que convierte una pasarela de API compatible con OpenAI en una capa de control de migración en lugar de otra incógnita de integración.

En qué se diferencia de una migración directa de proveedor

La documentación de los proveedores ya muestra que la compatibilidad con estilo OpenAI se está volviendo habitual. Google documenta el acceso a Gemini mediante bibliotecas de OpenAI. DeepSeek documenta la compatibilidad con OpenAI y Anthropic. Sin embargo, cada proveedor sigue teniendo su propia clave, URL base y límite operativo.

Ese es el vacío que aborda una pasarela de API compatible con OpenAI. En lugar de enseñar a cada equipo una nueva configuración específica del proveedor, puede centralizar la superficie de migración y orientar el trabajo de revisión hacia la aprobación de modelos, la observabilidad y la política de enrutamiento de modelos.

Esto también explica por qué el mensaje actual de Flatkey es más sólido que «funciona con el SDK de OpenAI». El beneficio más importante es que una pasarela de API compatible con OpenAI puede consolidar el acceso y la revisión sin obligar a una reescritura inmediata de la aplicación.

Redacción de cumplimiento que los revisores pueden aprobar

Use una redacción como esta en la revisión final antes de publicar:

Evite formulaciones como estas, a menos que los revisores puedan demostrarlas:

Estas salvedades hacen que la propuesta de openai compatible api gateway sea más creíble, no más débil.

Cuándo un gateway de API compatible con OpenAI es la opción adecuada

Un openai compatible api gateway suele ser la opción adecuada cuando:

• su equipo ya depende de flujos de cliente de estilo OpenAI y busca la ruta de migración menos disruptiva
• ya se contempla más de una familia de modelos
• necesita un único lugar para revisar el acceso, el uso y las rutas aprobadas
• los cambios de modelos ocurren con la frecuencia suficiente para justificar una model routing policy compartida
• desea una migración controlada antes de considerar funcionalidades más avanzadas de gateway

Si esas condiciones no se cumplen, una configuración directa con el proveedor puede seguir siendo más sencilla. Este artículo debe ser honesto sobre esa disyuntiva.

Equipos de AWS: la URL base compatible con OpenAI de Bedrock

Si sus modelos se ejecutan en AWS, Amazon Bedrock expone su propia URL base compatible con OpenAI, https://bedrock-runtime.{region}.amazonaws.com/openai/v1, autenticada con claves de API de Bedrock. Nuestra guía de la API compatible con OpenAI de Amazon Bedrock cubre endpoints, claves, ID de modelos y la limitación de /models.

Conclusión

El valor de un openai compatible api gateway no radica en que invente un nuevo patrón de API. Su valor es que permite a los equipos conservar una integración familiar de estilo OpenAI mientras trasladan el acceso, la aprobación de modelos y el control del despliegue detrás de una capa revisable.

Para Flatkey, la afirmación revisable más sólida es sencilla: conserve el patrón de cliente que ya utiliza, cambie la URL base a https://router.flatkey.ai/v1, valide el flujo de trabajo compatible exacto y apruebe la model routing policy antes de ampliar el tráfico. Esa es la lista de verificación de migración que los desarrolladores realmente necesitan.