Routage des fournisseurs

Un modèle est souvent servi par plusieurs fournisseurs, et provider.type épingle une requête à l’un d’eux. Quels fournisseurs existent et pourquoi en épingler un sont traités dans Routage des fournisseurs ; cette page est le contrat de champ par protocole.

Emplacement du champ

Le champ ne se place pas au même endroit selon le protocole :

Protocole / endpoint	Corps de la requête	En-tête
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/…`	ignoré silencieusement	`X-OfoxAI-Provider-Type`
Video API · `POST /v1/videos`	`provider.type` à la racine	—

Parmi les modèles d’image, seul openai/gpt-image-2 est aujourd’hui servi par plusieurs fournisseurs (azure_foundry et openai) ; les autres sont mono-fournisseur, et en désigner un autre renvoie 400 provider_type_unavailable. À noter aussi : les modèles d’image Gemini ont deux points d’entrée — sur /v1/images/generations le champ du corps fonctionne, sur le generateContent natif de Gemini il est ignoré.

Le passer dans le corps de la requête

extra_body doit être une clé littérale du corps JSON, avec provider imbriqué dedans :

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.5",
    "messages": [{ "role": "user", "content": "..." }],
    "extra_body": {
      "provider": { "type": "bedrock" }
    }
  }'

Python

provider_routing.py


client.chat.completions.create(
    model="anthropic/claude-sonnet-5.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.5',
  messages: [{ role: 'user', content: '...' }],
  extra_body: { provider: { type: 'bedrock' } },
} as any)

Avec les SDK OpenAI officiels, extra_body doit être présent comme clé littérale dans le corps de la requête. Le SDK TypeScript l’envoie tel qu’il est écrit dans l’objet de paramètres. L’argument extra_body= du SDK Python fusionne son contenu à la racine du corps : la clé doit donc être imbriquée un niveau plus profond, ou transmise via un en-tête.

Le protocole natif Gemini ignore extra_body.provider dans le corps — la requête aboutit, la contrainte ne s’applique tout simplement pas, sans erreur. Sur ce protocole, utilisez l’en-tête ci-dessous.

Le passer dans un en-tête

X-OfoxAI-Provider-Type fonctionne sur tous les protocoles texte, Gemini compris, et convient aux intégrations qui ne peuvent pas modifier le corps de la requête :

Terminal


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

Là où les deux sont pris en charge, l’en-tête et le champ du corps sont équivalents. L’API vidéo n’a pas de forme d’en-tête — voir Video API · Routage des fournisseurs.

Erreurs

`error.type`	Quand elle survient
`invalid_provider_type`	La valeur n’est pas un nom de fournisseur : faute de frappe ou écriture retirée.
`provider_type_unavailable`	Le fournisseur existe mais ne sert pas ce modèle. Le message liste également ceux qui le servent.

Quels fournisseurs indiquer

La liste complète, et comment savoir quels fournisseurs servent un modèle donné, figurent dans Routage des fournisseurs.