Migrating from Portkey
Switch from Portkey to Shim
Portkey and Shim overlap more than either overlaps with a plain proxy. The difference is what each treats as the centre of the product: observability and prompt operations, or the evidence trail.
Side by side
How the two differ
| Dimension | Portkey | Shim |
|---|---|---|
| Centre of gravity | Observability, prompt management, guardrails as a platform | Redaction and the audit record, with routing around them |
| PII handling | Guardrails you configure per policy | Reversible tokenization in the request path, and the mapping stays in the gateway |
| Audit record | Request logs and analytics | Hash-chained log with daily anchors, built to be exported as evidence |
| Turkish and EU regimes | Generic policy tooling | KVKK vocabulary, TR identifiers, EU AI Act evidence reports |
| Prompt library and evaluations | Yes | No |
| Deployment | Managed, with self-host options | Managed, with self-hosting on the Enterprise plan |
The code change
The diff, in full
Both expose an OpenAI-compatible surface, so the swap is the base URL and the key. Portkey-specific headers (virtual keys, configs, trace ids) have no Shim equivalent and should be removed. Request tagging moves to the X-Shim-Tag header.
Before· today
from openai import OpenAI
client = OpenAI(
api_key="pk-...",
base_url="https://api.portkey.ai/v1"
)After· through Shim
from openai import OpenAI
client = OpenAI(
api_key="sk-shim-...",
base_url="https://api.getshim.tech/v1"
)What it takes
Half a day per service, plus whatever your prompt tooling depends on.
The transport swap is trivial. The migration cost sits in anything you built on Portkey-specific features: prompt templates stored in their library, config objects, and virtual-key routing. Those need a home before you cut over: usually your own repo. Budget for that inventory before you budget for the swap.
- The redaction round trip is reversible and the map never leaves your gateway: your application gets real values back while the provider only ever saw tokens.
- An audit log designed for the reviewer rather than the dashboard: entity types and counts, hash-chained, with an evidence export.
- Turkish identifier coverage and KVKK-shaped reporting without building the vocabulary yourself.
What Shim does not do
- No prompt library, no versioned prompt deployments, no evaluation runs. If your team works inside Portkey's prompt tooling daily, that workflow has no equivalent here.
- Narrower provider list.
- Analytics are focused on cost, traffic and policy decisions, not on model-quality experimentation.
Stay where you are when
Portkey is the better answer
- Prompt management is part of your daily workflow. Shim has no answer here and you should not give up a working prompt pipeline for a governance feature you could add elsewhere.
- You need model-quality evaluation and experimentation in the same tool as routing.
- Your compliance requirements are generic enough that a policy engine covers them and no one is asking for TR-specific identifiers or KVKK-shaped evidence.
We would rather you read this and stay than migrate and find out in month two. If one of these describes you, Shim is not the tool you need yet.
Ready to move your first service?
Start free on the hosted gateway, or tell us about your setup and we will plan the switch with you, on our cloud or on your own servers.