Enrutamiento de proveedores

Un modelo suele estar servido por varios proveedores, y provider.type fija una petición a uno de ellos. Qué proveedores existen y por qué fijar uno se tratan en Enrutamiento de proveedores; esta página es el contrato de campo por protocolo.

Ubicación del campo

El campo no está en el mismo sitio en todos los protocolos:

Protocolo / endpoint	Cuerpo de la petición	Cabecera
OpenAI Chat Completions · `POST /v1/chat/completions`	`extra_body.provider.type`	`X-OfoxAI-Provider-Type`
OpenAI Responses · `POST /v1/responses`	`extra_body.provider.type`	`X-OfoxAI-Provider-Type`
OpenAI Images · `POST /v1/images/generations`	`extra_body.provider.type`	`X-OfoxAI-Provider-Type`
Anthropic Messages · `POST /anthropic/v1/messages`	`extra_body.provider.type`	`X-OfoxAI-Provider-Type`
Gemini generateContent · `POST /gemini/v1beta/…`	se ignora en silencio	`X-OfoxAI-Provider-Type`
Video API · `POST /v1/videos`	`provider.type` de nivel superior	—

De los modelos de imagen, hoy solo openai/gpt-image-2 está servido por más de un proveedor (azure_foundry y openai); el resto son de un solo proveedor, así que indicar otro devuelve 400 provider_type_unavailable. Ten en cuenta además que los modelos de imagen de Gemini tienen dos puntos de entrada: en /v1/images/generations el campo del cuerpo funciona; en el generateContent nativo de Gemini se ignora.

Enviarlo en el cuerpo de la petición

extra_body debe ser una clave literal del cuerpo JSON, con provider anidado dentro:

cURL

Terminal


curl https://api.ofox.io/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-5",
    "messages": [{ "role": "user", "content": "..." }],
    "extra_body": {
      "provider": { "type": "bedrock" }
    }
  }'

Python

provider_routing.py


client.chat.completions.create(
    model="anthropic/claude-sonnet-5",
    messages=[{"role": "user", "content": "..."}],
    extra_body={"extra_body": {"provider": {"type": "bedrock"}}},
)

TypeScript

provider-routing.ts


await client.chat.completions.create({
  model: 'anthropic/claude-sonnet-5',
  messages: [{ role: 'user', content: '...' }],
  extra_body: { provider: { type: 'bedrock' } },
} as any)

Con los SDK oficiales de OpenAI, extra_body debe estar presente como clave literal en el cuerpo de la petición. El SDK de TypeScript lo envía tal como se escribe en el objeto de parámetros. El argumento extra_body= del SDK de Python fusiona su contenido en el nivel superior del cuerpo, por lo que la clave debe anidarse un nivel más, o enviarse como cabecera.

El protocolo nativo de Gemini ignora extra_body.provider en el cuerpo: la petición se completa, la restricción sencillamente no se aplica y no hay ningún error. En ese protocolo usa la cabecera de más abajo.

Enviarlo en una cabecera

X-OfoxAI-Provider-Type funciona en todos los protocolos de texto, incluido Gemini, y encaja con integraciones que no pueden modificar el cuerpo de la petición:

Terminal


curl https://api.ofox.io/gemini/v1beta/models/google/gemini-3.1-flash-lite:generateContent \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "X-OfoxAI-Provider-Type: vertex" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{ "parts": [{ "text": "..." }] }]
  }'

Donde ambos están admitidos, la cabecera y el campo del cuerpo son equivalentes. La API de vídeo no tiene forma de cabecera — ver Video API · Enrutamiento de proveedores.

Errores

`error.type`	Cuándo aparece
`invalid_provider_type`	El valor no es un nombre de proveedor: una errata o una escritura ya retirada.
`provider_type_unavailable`	El proveedor existe pero no sirve este modelo. El mensaje lista además los que sí lo sirven.

Qué proveedores puedes indicar

La lista completa, y cómo averiguar qué proveedores sirven un modelo concreto, están en Enrutamiento de proveedores.