Moving from another gateway is mostly a matter of deleting code. Routeplane is wire-compatible with the OpenAI API, so the client-side integration collapses to a base URL and a key — anything your current gateway made you do in the SDK moves to server-side config or an x-routeplane-* header.
The general shape
- Point
base_urlat your Routeplane deployment. - Swap the key for a Routeplane virtual key (
rp_...). - Move provider credentials into the key's registry entry — your application stops holding them.
- Translate gateway-specific headers or config to their Routeplane equivalent (below).
- Delete the gateway's SDK, if it made you install one.
From LiteLLM
The largest difference is model addressing. LiteLLM commonly namespaces the provider into the model string; Routeplane keeps the model name as the provider states it and selects the provider separately, so the same model name can be served by whichever provider is eligible.
| LiteLLM | Routeplane |
|---|---|
model: "openai/gpt-4o" | model: "gpt-4o" + x-routeplane-provider: openai |
Fallback list in config.yaml | x-routeplane-provider: openai,anthropic, or a default chain on the key |
| Router strategy in config | x-routeplane-strategy: priority | weighted | cost | latency |
| Budget config | Per-key spend limits; responses carry x-routeplane-budget-remaining |
| Caching config | Server-side exact-match cache; responses carry x-routeplane-cache |
From Portkey
The concepts map closely — both use virtual keys and a config envelope — so this is largely a rename.
| Portkey | Routeplane |
|---|---|
| Portkey SDK | None — use the OpenAI SDK you already have |
x-portkey-* headers | x-routeplane-* headers |
| Virtual key | Virtual key (rp_ prefix) |
| Config object | x-routeplane-config, or a saved routing config |
| Feedback API | POST /v1/feedback — same shape: trace_id, value, weight |
The feedback endpoint is deliberately Portkey-shaped so an existing integration keeps working with only the host changed.
What you gain that has no equivalent to migrate
Two capabilities have no counterpart in the gateways above, so there is nothing to translate — they simply start applying:
- Content-level residency enforcement. Other gateways route on the region you declare. Routeplane classifies the request body and, when it finds regulated personal data, constrains routing to providers resident in the required jurisdiction — whether or not the caller remembered to say so.
- A tamper-evident audit trail. Each decision is recorded in a hash-chained, signed ledger built so raw message text is structurally unrepresentable, with an offline verifier. It is evidence for an auditor, not application logs.
Running both during cutover
Because adoption is a base-URL change, the safest migration is per-service rather than big-bang: move one service, compare its responses, then move the next. Both gateways can run side by side indefinitely — there is no shared state to split-brain, and reverting a service is the same one-line change in the other direction.
Check your model names. The most common cutover failure is a model string that carried a provider prefix from the previous gateway. Routeplane passes the model through to the provider as given, so openai/gpt-4o reaches the provider verbatim and is rejected there. Strip the prefix and choose the provider with the header.