Models

モデル一覧エンドポイントは 1 つの問いに答えます。現在のトークンでどのモデルを呼び出せるかです。返されるのは、トークンの権限・グループ・公開状態でフィルタされた結果であり、プラットフォーム全体のモデルカタログではありません。リクエストの model は必ずこの一覧に含まれる値でなければなりません。

利用可能なモデルを一覧する

GET /v1/models

curl https://api.routeapi.ai/v1/models \
  -H "Authorization: Bearer $ROUTEAPI_KEY"

レスポンス:

{
  "success": true,
  "object": "list",
  "data": [
    {
      "id": "gpt-5.5",
      "object": "model",
      "created": 1626777600,
      "owned_by": "openai",
      "supported_endpoint_types": ["openai", "openai-response"]
    },
    {
      "id": "claude-sonnet-4-5",
      "object": "model",
      "created": 1626777600,
      "owned_by": "anthropic",
      "supported_endpoint_types": ["openai", "anthropic"]
    },
    {
      "id": "text-embedding-3-large",
      "object": "model",
      "created": 1626777600,
      "owned_by": "openai",
      "supported_endpoint_types": ["embeddings"]
    }
  ]
}

フィールド	説明
`id`	呼び出し時に `model` に指定する値。唯一信頼できるモデル識別子
`object`	固定で `"model"`
`created`	固定のプレースホルダ値 `1626777600`。実際の公開日時ではありません。並び替えや新旧の判断に使わないでください
`owned_by`	モデルが属するチャネルタイプ（`openai`、`anthropic` など）。プラットフォームのカスタムモデルは `custom`
`supported_endpoint_types`	このモデルで利用できるエンドポイントタイプの一覧。下記のエンドポイントタイプを参照

レスポンスのトップレベルには success と、OpenAI スタイルの object/data が同時に存在します。OpenAI SDK は data のみを読むため、追加の success はパースに影響しません。

data の順序は安定性が保証されず、2 回のリクエストで異なる場合があります。順序を固定したい場合はクライアント側で並び替えてください。

エンドポイントタイプ

supported_endpoint_types は RouteAPI の拡張フィールドであり、モデル一覧における唯一の能力シグナルです。このモデルがどのプロトコル入口から呼び出せるかを示します。

値	対応するエンドポイント
`openai`	`POST /v1/chat/completions`
`openai-response`	`POST /v1/responses`
`anthropic`	`POST /v1/messages`
`gemini`	`POST /v1beta/models/{model}:generateContent`
`embeddings`	`POST /v1/embeddings`
`image-generation`	`POST /v1/images/generations`
`jina-rerank`	`POST /v1/rerank`
`openai-video`	OpenAI 動画生成エンドポイント
`suno-*`	Suno 系エンドポイント。Suno API を参照

あるモデルの supported_endpoint_types に embeddings が含まれていない場合、そのモデルを /v1/embeddings に渡さないでください。この種の不一致は転送段階で失敗します。

一覧には細粒度の能力フィールドはありません。 ツール呼び出し、画像入力、構造化出力に対応しているかは、モデル一覧エンドポイントでは返されず、supports_tools / supports_vision のようなフィールドもありません。これらの能力は上流モデル自身によって決まるため、確認方法はモデルプロバイダのドキュメントを参照するか、対象モデルで実際にリクエストを 1 回送って検証することです。コンテキスト長、モダリティ、価格などのメタデータも同様にこのエンドポイントには含まれず、コンソールのモデル広場ページに表示されます。

単一モデルを取得する

GET /v1/models/{model}

curl https://api.routeapi.ai/v1/models/gpt-5.5 \
  -H "Authorization: Bearer $ROUTEAPI_KEY"

存在する場合はモデルオブジェクトをそのまま返します（data でラップされません）:

{
  "id": "gpt-5.5",
  "object": "model",
  "created": 1626777600,
  "owned_by": "openai"
}

存在しない場合、または現在のアカウントから見えない場合は次を返します:

{
  "error": {
    "message": "The model 'foo' does not exist",
    "type": "invalid_request_error",
    "param": "model",
    "code": "model_not_found"
  }
}

HTTP ステータスコードは 200 のままであることに注意してください。 このエンドポイントはエラーをレスポンスボディの error フィールドに入れ、「モデルが存在しない」ことをステータスコードで表現しません。クライアントはレスポンスボディに error があるかどうかを必ず確認する必要があります。HTTP ステータスコードだけを見ると、失敗を成功と見なしてしまいます。

現在のアカウントから見えないモデルと、本当に存在しないモデルは完全に同じエラーを返すため、このエンドポイントで両者を区別することはできません。

他プロトコルのモデル一覧

同じ利用可能モデル集合を 3 つのプロトコル形式で取得できます。ご利用の SDK に合わせて選んでください。

Claude Messages 形式

GET /v1/models に x-api-key と anthropic-version の両方のリクエストヘッダーを付けると、Anthropic スタイルで返します:

curl https://api.routeapi.ai/v1/models \
  -H "x-api-key: $ROUTEAPI_KEY" \
  -H "anthropic-version: 2023-06-01"

{
  "data": [
    {
      "id": "claude-sonnet-4-5",
      "created_at": "2021-07-20T12:00:00Z",
      "display_name": "claude-sonnet-4-5",
      "type": "model"
    }
  ],
  "first_id": "claude-sonnet-4-5",
  "has_more": false,
  "last_id": "claude-sonnet-4-5"
}

この形式に切り替わるには 2 つのリクエストヘッダーが同時に存在する必要があり、x-api-key だけの場合は OpenAI 形式のままです。display_name は id と同じ値で、コンソール上の表示名ではありません。has_more は常に false です。一覧は一度に全件返され、ページネーションはありません。一覧が空の場合、first_id と last_id は空文字列になります。

Gemini 形式

curl "https://api.routeapi.ai/v1beta/models" \
  -H "x-goog-api-key: $ROUTEAPI_KEY"

{
  "models": [
    { "name": "gemini-2.5-pro", "displayName": "gemini-2.5-pro" }
  ],
  "nextPageToken": null
}

Gemini 形式のモデルオブジェクトには inputTokenLimit、supportedGenerationMethods などのフィールドも含まれますが、RouteAPI が値を入れるのは name と displayName のみで、その他のフィールドは null を返します。これらの空フィールドでモデルの能力を判断しないでください。

Gemini プロトコルのモデル一覧には /v1beta/models パスを使用し、/v1/models に Gemini のリクエストヘッダーを付けないでください。

/v1 プレフィックスなし

クライアントの Base URL を /v1 なし（例: https://api.routeapi.ai）に設定している場合も GET /models は利用可能で、内部で /v1/models に書き換えられます。

一覧内容を決める 4 つのフィルタ

モデルがあなたの一覧に現れるには、4 つのフィルタをすべて通過する必要があります。「モデルが一覧にない」ことを調査するときは、この順序で確認してください。

トークンのモデルホワイトリスト — このトークンでモデル制限が有効な場合、一覧はホワイトリストと他の条件の積集合になります。無効なら次の項目へ進みます。
グループで有効なモデル — あなたが所属するユーザーグループ（およびトークンで指定されたグループ）で有効になっているモデルの和集合を取ります。利用可能なチャネルが 1 つもないモデルは現れません。
カタログの公開状態 — プラットフォームが厳格メタデータモードを有効にしている場合、未公開のモデルは外部から見て存在しないのと同じになります。
価格が設定済みか — 価格が未設定のモデルはデフォルトでフィルタされます。ただしプラットフォームが自己利用モードを有効にしている場合、またはアカウント設定で「価格未設定モデルを受け入れる」を有効にしている場合は除きます。

4 つのフィルタを通過した結果、空の一覧が返るのは正常な結果であり、エラーではありません。グループ内のモデルがすべて未公開の場合にこうなります。

同じプラットフォームでも、トークンによってモデル一覧はまったく異なり得ます。A のトークンで一覧を取得し、B のトークンでリクエストを送るのはよくある落とし穴です。調査の際は、この 2 つを必ず同じトークンで行ってください。

モデル利用不可の調査

リクエストでモデル関連のエラーが出た場合は、まずエラー文言と照らし合わせて該当箇所を特定します。

エラー文言	HTTP	意味	対処
`Model name not specified...`	400	リクエストの `model` が空	`model` フィールドを追加する
`This token has no access to model {model}`	403	モデルがそのトークンのホワイトリストにない	コンソールでトークンにそのモデルを追加する、またはモデル制限のないトークンに切り替える
`This token has no access to any models`	403	トークンでモデル制限が有効だがホワイトリストが空	ホワイトリストを設定する
`No valid upstream service`	503	モデルに利用可能なチャネルがない（未設定、全て無効、または遮断中）	モデル ID のスペルを確認する。一覧内の別のモデルに切り替える。プラットフォーム管理者に連絡する
`The model '{model}' does not exist`	200（ボディ内の `error`）	`GET /v1/models/{model}` で見つからないか、見えない	`GET /v1/models` で正確な ID を確認する

調査の順序:

同じトークンで GET /v1/models を呼び出し、モデルが実際に一覧に含まれていることを確認します。
model のスペルを 1 文字ずつ照合します。大文字小文字とハイフンも含みます。モデル ID は厳密一致です。
呼び出しているエンドポイントが、そのモデルの supported_endpoint_types に含まれていることを確認します。
以上がすべて正しいのに失敗する場合、問題はチャネル側（利用可能な上流がない、または上流のエラー）にあります。コンソールのログで request ID から具体的な上流レスポンスを確認してください。詳しくはエラーとデバッグを参照。

ベストプラクティス

モデル ID を固定する。 コンソールの表示名や一時的なエイリアスを使わないでください。リクエストは id しか受け付けません。
起動時に一覧を 1 回取得してキャッシュする。 業務リクエストごとに問い合わせないでください。利用可能なモデル集合の変化頻度は非常に低いです。
created で並び替えない。 すべてのモデルで共有される固定のプレースホルダ値です。
重要な経路には代替モデルを用意する。 メインのモデルが 503 を返したときに切り替えます。
本番投入前に本番トークンで一度実測する。 モデル一覧と実際の呼び出しの両方を実行し、ツール呼び出しや画像入力など実際に使う能力をカバーしてください。これらの能力は一覧エンドポイントでは保証されません。

次のステップ

認証方式 — トークン権限、モデルホワイトリスト、クォータ設定。
Chat Completions — 一覧内のモデルで対話を開始する。
エラーとデバッグ — 完全なステータスコードと調査手順。
課金とクォータ — モデル価格と使用量の算定基準。