Provider guide

OpenRouter through one OpenAI-compatible gateway

Put OpenRouter’s aggregated model catalog behind Routeplane’s governance — fallback, in-data-plane guardrails, residency, and cost attribution — while keeping OpenRouter’s breadth.

OpenRouter is itself an aggregator: its provider/model ids fan out to many upstreams. Routeplane’s adapter passes those ids through verbatim, so you get OpenRouter’s catalog breadth and the gateway’s governance layer — one authenticated, audited surface with guardrails and residency.

Use OpenRouter as a broad catalog provider behind the gateway, or as a fallback to your first-party providers.

Drop in your OpenAI client

Point your existing OpenAI SDK at the gateway and add two headers — your virtual key and the provider. Nothing else about your code changes.

bashcurl

curl https://api.routeplane.ai/v1/chat/completions \
  -H "content-type: application/json" \
  -H "x-routeplane-api-key: rp_your_gateway_key" \
  -H "x-routeplane-provider: openrouter" \
  -d '{"model":"openai/gpt-4o","messages":[{"role":"user","content":"Hello!"}]}'

pythonopenai SDK

import openai

client = openai.OpenAI(
    api_key="rp_your_gateway_key",
    base_url="https://api.routeplane.ai/v1",
    default_headers={
        "x-routeplane-api-key": "rp_your_gateway_key",
        "x-routeplane-provider": "openrouter",   # route to OpenRouter
    },
)

resp = client.chat.completions.create(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Hello!"}],
)
print(resp.choices[0].message.content)

typescriptopenai SDK

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: 'rp_your_gateway_key',
  baseURL: 'https://api.routeplane.ai/v1',
  defaultHeaders: {
    'x-routeplane-api-key': 'rp_your_gateway_key',
    'x-routeplane-provider': 'openrouter', // route to OpenRouter
  },
});

const completion = await client.chat.completions.create({
  model: 'openai/gpt-4o',
  messages: [{ role: 'user', content: 'Hello!' }],
});
console.log(completion.choices[0]?.message.content);

Or use the Routeplane SDK

The Routeplane SDKs subclass the official OpenAI clients, wire up the x-routeplane-* headers for you, and add typed access to routing metadata and the non-OpenAI surfaces.

bashinstall

pip install routeplane

pythonrouteplane SDK

from routeplane import Routeplane

client = Routeplane(
    api_key="rp_your_gateway_key",
    provider="openrouter",   # route to OpenRouter
)

resp = client.chat.completions.create(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Hello!"}],
)
print(resp.choices[0].message.content)

bashinstall

npm i @routeplane/sdk

typescript@routeplane/sdk

import { Routeplane } from '@routeplane/sdk';

const client = new Routeplane({
  apiKey: process.env.ROUTEPLANE_API_KEY!, // rp_...
  provider: 'openrouter',                 // route to OpenRouter
});

const completion = await client.chat.completions.create({
  model: 'openai/gpt-4o',
  messages: [{ role: 'user', content: 'Hello!' }],
});
console.log(completion.choices[0]?.message.content);

Add a fallback chain

Try OpenRouter first; fall back to OpenAI’s direct API. Make the provider header a comma-separated list and the gateway walks it in order, skipping any provider whose circuit is open.

bashcurl

curl https://api.routeplane.ai/v1/chat/completions \
  -H "content-type: application/json" \
  -H "x-routeplane-api-key: rp_your_gateway_key" \
  -H "x-routeplane-provider: openrouter,openai" \
  -d '{"model":"openai/gpt-4o","messages":[{"role":"user","content":"Hello!"}]}'

OpenRouter on the gateway

The adapter supports chat completions and native streaming. Embeddings requests return a clean 422 — route them to a provider that offers them.

Catalog ids pass through

OpenRouter ids look like anthropic/claude-sonnet-4.5 or openai/gpt-4o. Send them verbatim in model; the adapter never rewrites them.

Attribution headers

The adapter sends Routeplane’s attribution headers (HTTP-Referer and X-Title) on every request, as OpenRouter expects for app identification.

Sovereign routing

Sovereign routing works with OpenRouter the same way it works everywhere: add x-routeplane-residency to a request, and when the gateway classifies regulated personal data in it, only providers resident in the requested region stay eligible — a hard constraint that overrides the provider header. Declare where OpenRouter runs by setting OPENROUTER_REGION.

Keep reading

Quickstart — send your first request in a few minutes.
Providers & routing strategy — how eligibility, fallback, and strategies work.
Python SDK and TypeScript SDK — the full typed clients.
All providers — every model provider behind the gateway.

Frequently asked questions

Is Routeplane a drop-in replacement for calling OpenRouter directly?

Yes. The gateway is OpenAI-compatible, so switching is a base-URL change — point your existing OpenAI SDK at https://api.routeplane.ai/v1 and set the x-routeplane-provider header to openrouter. You keep your code and gain automatic fallback, in-data-plane PII guardrails, sovereign routing, and per-team cost attribution.

Which OpenRouter models can I use through Routeplane?

Any model your OpenRouter endpoint exposes — model ids pass through the gateway verbatim.

Can I enforce data residency on OpenRouter requests?

Yes. Add the x-routeplane-residency header (for example IN) and, when a request carries regulated personal data, the gateway restricts routing to providers eligible in that region — overriding the provider header if it has to. The OpenRouter adapter reads OPENROUTER_REGION to declare where it is resident.

Route your first request this week.

Point your existing OpenAI-compatible client at Routeplane, set one header, and get fallback, guardrails, and sovereign routing across every provider.

Request access → Read the quickstart