Skip to main content
GET /v1/models Returns the list of models available from the configured provider. When a provider, virtual key, or config is specified in the request headers, the gateway forwards the request to that provider and returns its model list directly. If no provider is specified and a Portkey control-plane URL is configured (ALBUS_BASEPATH), the gateway proxies the request to the Portkey platform to retrieve the available models across your configured integrations.

Request

x-portkey-provider
string
The provider to retrieve models from (e.g. openai, anthropic, azure-openai). When provided, the gateway forwards the request directly to the provider.
x-portkey-api-key
string
required
Your Portkey API key, or the provider API key if using provider headers directly.
x-portkey-virtual-key
string
A Portkey virtual key. When set, the gateway routes to the provider associated with that virtual key.
x-portkey-config
string | object
A Portkey config object or config ID. The gateway reads the provider or virtual_key from the config to determine the target.

Response

object
string
Always list.
data
array

Examples

curl https://your-gateway.example.com/v1/models \
  -H "x-portkey-api-key: YOUR_API_KEY" \
  -H "x-portkey-provider: openai"

Routing behavior

The modelsHandler determines where to send the request based on the following precedence:
  1. Provider header present (x-portkey-provider, x-portkey-virtual-key, or provider/virtual_key in config) — forwards the request to that specific provider’s models endpoint.
  2. No provider specified with ALBUS_BASEPATH configured — proxies to the Portkey control plane at /v2/models to retrieve the aggregated model list across your integrations.
  3. No provider and no control plane — the request falls through to the next middleware handler.
When using virtual keys, the gateway resolves the underlying provider credentials automatically. You do not need to pass a separate provider API key.

Build docs developers (and LLMs) love