Provider guide

OpenAI through one OpenAI-compatible gateway

Keep your OpenAI SDK. Point its base URL at Routeplane and get automatic fallback to a second provider, PII redaction on the hot path, residency-aware routing, and cost attribution — without changing a line of application code.

OpenAI is Routeplane's default provider: drop the x-routeplane-provider header entirely and requests route to it. Because the gateway surface is OpenAI-compatible, adopting it is a base-URL change — the request and response shapes you already send stay the same.

What you gain by routing through the gateway rather than calling api.openai.com directly: a fallback chain so a single provider outage doesn't take you down, deterministic PII/secret redaction before the request leaves the data plane, sovereign routing that can hard-lock regulated requests to an in-region provider, and spend attributed by team, project, and currency.

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: openai" \
  -d '{"model":"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": "openai",   # route to OpenAI
    },
)

resp = client.chat.completions.create(
    model="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': 'openai', // route to OpenAI
  },
});

const completion = await client.chat.completions.create({
  model: '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="openai",   # route to OpenAI
)

resp = client.chat.completions.create(
    model="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: 'openai',                 // route to OpenAI
});

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

Add a fallback chain

Try OpenAI first; fall back to Anthropic if OpenAI errors, rate-limits, or its circuit is open. 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: openai,anthropic" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"Hello!"}]}'

OpenAI on the gateway

Beyond chat, the OpenAI adapter also proxies embeddings, moderations, audio transcription and translation (Whisper), text-to-speech, and image generation — all on the same OpenAI-compatible surface.

Streaming is native

The adapter forwards OpenAI's server-sent events straight through, so stream: true behaves exactly as it does against OpenAI directly — the gateway adds fallback only up to the first chunk, then commits to the chosen provider.

Usage detail preserved

Nested usage fields OpenAI returns — cached prompt tokens and reasoning tokens — are lifted into the canonical usage block so your cost accounting sees them.

OpenAI model pricing

List prices for the OpenAI models you can call through the gateway — click any model for its per-token cost page.

Sovereign routing

Sovereign routing works with OpenAI 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. Combine OpenAI with a region-locked deployment and declare its region so it becomes eligible for in-region routing.

Keep reading

Frequently asked questions

Is Routeplane a drop-in replacement for calling OpenAI 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 openai. You keep your code and gain automatic fallback, in-data-plane PII guardrails, sovereign routing, and per-team cost attribution.

Which OpenAI models can I use through Routeplane?

Any OpenAI model the provider serves. See the list prices linked above for the ones we publish.

Can I enforce data residency on OpenAI 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. Declare the region your OpenAI deployment serves so it becomes eligible.

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.