プロバイダールーティング

1 つのモデルは複数のプロバイダーで提供されていることが多く、provider.type はリクエストをそのうち 1 つに固定します。どんなプロバイダーがあるか、なぜ固定するのかはプロバイダールーティングを参照してください。本ページは各プロトコルのフィールド契約です。

フィールドの位置

このフィールドの位置はプロトコルによって異なります：

プロトコル / エンドポイント	リクエストボディ	リクエストヘッダー
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/…`	黙って無視	`X-OfoxAI-Provider-Type`
Video API · `POST /v1/videos`	トップレベルの `provider.type`	—

画像モデルのうち、現在複数のプロバイダーで提供されているのは openai/gpt-image-2（azure_foundry と openai）だけです。ほかは単一プロバイダーのため、別のプロバイダーを指定すると 400 provider_type_unavailable が返ります。また Gemini 系の画像モデルには 2 つのプロトコル入口があります —— /v1/images/generations ではボディのフィールドが有効ですが、Gemini ネイティブの generateContent では無視されます。

リクエストボディで渡す

extra_body は JSON ボディのリテラルなキーとして存在し、その中に provider をネストします：

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)

公式の OpenAI SDK を使用する場合、extra_body はリクエストボディのリテラルなキーとして存在する必要があります。TypeScript SDK はパラメータオブジェクトに記述したとおりに送信します。Python SDK の extra_body= 引数は内容をボディのトップレベルにマージするため、キーをもう 1 段階深くネストするか、リクエストヘッダーで渡してください。

Gemini ネイティブプロトコルはボディの extra_body.provider を無視します —— リクエストは正常に返り、制約は適用されず、エラーも出ません。このプロトコルでは下記のヘッダーを使ってください。

リクエストヘッダーで渡す

X-OfoxAI-Provider-Type は Gemini を含むすべてのテキストプロトコルで有効で、リクエストボディを変更できない接続方式に向いています：

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": "..." }] }]
  }'

両方に対応しているプロトコルでは、ヘッダーとボディのフィールドは等価です。Video API にヘッダー形式はありません — Video API · プロバイダールーティングを参照してください。

エラー

`error.type`	発生条件
`invalid_provider_type`	値がプロバイダー名ではありません：綴り間違い、または廃止された書き方です。
`provider_type_unavailable`	プロバイダーは存在しますが、このモデルを提供していません。メッセージには提供元のプロバイダーも併記されます。

指定できるプロバイダー

一覧と、あるモデルをどのプロバイダーが提供しているかの調べ方はプロバイダールーティングにあります。