Models

The models endpoint answers one question: which models can this token call right now. What comes back is the result after filtering by token permissions, group, and catalog listing status — not the platform’s full model catalog. The model in your requests must come from this list.

List available models

GET /v1/models

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

Response:

{
  "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"]
    }
  ]
}

Field	Description
id	The value to put in model when calling; the only reliable model identifier
object	Always "model"
created	A fixed placeholder value 1626777600, not the real listing time — do not use it to sort or to judge how new a model is
owned_by	The channel type the model belongs to (such as openai, anthropic); platform custom models are custom
supported_endpoint_types	The list of endpoint types available for this model, see Endpoint types below

The top level of the response carries both success and the OpenAI-style object/data. OpenAI SDKs only read data, so the extra success does not affect parsing.

The order of data is not guaranteed to be stable, and two requests may return different orders. If you need a fixed order, sort on the client side.

Endpoint types

supported_endpoint_types is a RouteAPI extension field, and it is also the only capability signal in the model list. It indicates which protocol entry points this model can be called from:

Value	Corresponding endpoint
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 video generation endpoint
suno-*	Suno series endpoints, see Suno API

If a model’s supported_endpoint_types does not contain embeddings, do not pass it to /v1/embeddings — this kind of mismatch fails during the forwarding stage.

The list has no fine-grained capability fields. Whether tool calling, image input, or structured output is supported is not returned by the models endpoint, and there are no fields such as supports_tools / supports_vision. These capabilities are determined by the upstream model itself; to confirm them, consult the model provider’s documentation, or send one real request with the target model to verify. Metadata such as context length, modalities, and pricing is likewise not in this endpoint — it is shown on the model marketplace page in the console.

Retrieve a single model

GET /v1/models/{model}

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

When it exists, the model object is returned directly (not wrapped in data):

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

When it does not exist, or is not visible to the current account:

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

Note that the HTTP status code is still 200. This endpoint puts the error in the error field of the response body and does not use the status code to express “the model does not exist”. Clients must check whether the response body contains error; looking only at the HTTP status code will treat a failure as a success.

A model that is invisible to the current account returns exactly the same error as a model that genuinely does not exist, and this endpoint cannot distinguish between the two.

Model lists in other protocols

The same set of available models can be retrieved in three protocol formats — just pick the one that matches your SDK.

Claude Messages format

Send both the x-api-key and anthropic-version headers on GET /v1/models to get the Anthropic-style response:

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"
}

Both headers must be present for the format to switch; sending only x-api-key still returns the OpenAI format. display_name equals id, not the display name in the console. has_more is always false — the list is returned in full at once, with no pagination. When the list is empty, first_id and last_id are empty strings.

Gemini format

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
}

Model objects in the Gemini format also contain fields such as inputTokenLimit and supportedGenerationMethods, but RouteAPI only populates name and displayName; the remaining fields are returned as null. Do not rely on these empty fields to judge model capabilities.

For the model list in the Gemini protocol, use the /v1beta/models path — do not send Gemini headers to /v1/models.

Without the /v1 prefix

When a client configures the base URL without /v1 (for example https://api.routeapi.ai), GET /models works as well; internally it is rewritten back to /v1/models.

The four filters that determine list contents

For a model to appear in your list, it must pass four filters at the same time. When troubleshooting “the model is not in the list”, check them in this order:

1. Token model allowlist — if this token has model restrictions enabled, the list is the intersection of the allowlist and the remaining conditions. If not enabled, move on to the next one.
2. Models enabled for the group — the union of models enabled under the user group you belong to (and the group specified by the token). A model with no usable channel will not appear.
3. Catalog listing status — when the platform has strict metadata mode enabled, an unlisted model is externally equivalent to nonexistent.
4. Whether a price is configured — models without a configured price are filtered out by default, unless the platform has self-use mode enabled, or “accept models without pricing” is enabled in your account settings.

After the four filters, an empty list is a normal result, not an error. That is what happens when none of the models in the group are listed.

On the same platform, the model lists of different tokens can be completely different. Listing models with token A and sending requests with token B is a common pitfall — always use the same token for both when troubleshooting.

Model unavailable troubleshooting

When a request reports a model-related error, first use the error text to pin down the specific stage:

Error text	HTTP	Meaning	What to do
Model name not specified...	400	model is empty in the request	Add the model field
This token has no access to model {model}	403	The model is not in this token’s allowlist	Add the model to the token in the console, or switch to a token without model restrictions
This token has no access to any models	403	The token has model restrictions enabled but the allowlist is empty	Fill in the allowlist
No valid upstream service	503	The model has no usable channel (not configured, all disabled, or circuit-broken)	Confirm the spelling of the model ID; switch to another model from the list; contact the platform administrator
The model '{model}' does not exist	200 (error in body)	GET /v1/models/{model} cannot find it, or it is not visible	Use GET /v1/models to confirm the exact ID

Troubleshooting order:

1. Call GET /v1/models with the same token and confirm the model really is in the list.
2. Check the spelling of model character by character, including case and hyphens. Model IDs match strictly.
3. Confirm the endpoint you are calling is in that model’s supported_endpoint_types.
4. If all of the above are correct but it still fails, the problem is on the channel side (no usable upstream, or an upstream error). Look up the specific upstream response by request ID in the console logs. See Errors and debugging for details.

Best practices

• Pin model IDs — do not use console display names or ad-hoc aliases. Requests only recognize id.
• Fetch the list once at startup and cache it instead of querying it on every business request. The set of available models changes very infrequently.
• Do not sort by created — it is a fixed placeholder value shared by all models.
• Prepare a fallback model for critical paths, to switch to when the primary model returns 503.
• Run a real test with your production token before going live — run both the model list and one real call, covering the capabilities you actually use such as tool calling and image input, since the list endpoint makes no guarantees about those.

Next steps

• Authentication — token permissions, model allowlists, and quota configuration.
• Chat Completions — start a conversation with a model from the list.
• Errors and debugging — full status codes and troubleshooting order.
• Billing and quota — model pricing and usage accounting.