Gateways

A gateway that already speaks the OpenRouter wire can serve its users through Heimdallm as though it were OpenRouter, and every client of that gateway comes along. Each gateway below is configured with the marketplace as an upstream: a base URL and a Heimdallm API key (sk-hd-v1-…, see Authentication). Model ids stay author/slug catalogue ids.

None of the gateways here has a row in the compatibility matrix, which drives client SDKs rather than gateways (see SDKs & frameworks). The settings follow each project's documented configuration for an OpenAI-compatible or OpenRouter-compatible upstream.

Bifrost#

Bifrost's openrouter provider speaks OpenRouter's wire and takes a base URL in network_config. It appends /v1/chat/completions, /v1/embeddings and /v1/models to that URL, so the base URL is the API origin plus /api. When key validation is enabled it reads /v1/auth/key, which the gateway answers beside /key (Key & activity).

{
"providers": {
  "openrouter": {
    "keys": [
      { "name": "heimdall", "value": "env.HEIMDALL_API_KEY", "models": ["*"], "weight": 1.0 }
    ],
    "network_config": { "base_url": "https://api-staging.heimdallm.com/api" }
  }
}
}

Requests name the model as openrouter/ followed by the catalogue id, for example openrouter/deepseek/deepseek-v4-flash-0731-abliterated. Bifrost's OpenRouter provider covers chat, text completions, embeddings, speech and transcription; image generation, files and batches are not operations of that provider, so use the API reference routes directly for them.

LLMGateway#

LLMGateway reaches an upstream through a custom provider: a name, a base URL and a token. Its base URL field appends /v1/chat/completions to a bare host. Heimdallm serves chat completions under /api/v1, so the field takes the full endpoint, which LLMGateway uses unchanged when it ends in /chat/completions:

https://api-staging.heimdallm.com/api/v1/chat/completions

The token is a Heimdallm API key, sent as a bearer credential. Callers then name the model as the custom provider's name, a slash and the catalogue id: with a provider named heimdall, the model heimdall/deepseek/deepseek-v4-flash-0731-abliterated. LLMGateway documents these limits for custom providers: the URL must be HTTPS, the provider must support the chat completions format, and embeddings, images, audio, video and rerank do not route through a custom provider. Creating one requires its Enterprise plan on the hosted service.

LiteLLM proxy#

A LiteLLM proxy forwards to Heimdallm through the same openrouter provider the Python client uses. model_name is the alias the proxy's own callers send.

model_list:
- model_name: deepseek-flash
  litellm_params:
    model: openrouter/deepseek/deepseek-v4-flash-0731-abliterated
    api_base: https://api-staging.heimdallm.com/api/v1
    api_key: os.environ/HEIMDALL_API_KEY

What a gateway adds to the path#

The marketplace sees every request as coming from the gateway's key, so the per-key rate limit of Errors & rate limits is shared by all of the gateway's users, and a spend limit on that key bounds all of them together. A gateway that retries should follow the rules in the production checklist: retry 408, 429, 502, 503 and 504 with backoff, honour Retry-After, and leave the other 4xx responses alone. A gateway that retries a request after its own timeout can send that request twice, and both attempts are billed if both complete.