Migrating from Direct provider APIs
Switch from calling provider APIs directly to Shim
Most teams start by calling the provider directly, because it is the shortest path to a working feature. It stays right until someone asks what your application has been sending, and you have no way to answer.
Side by side
How the two differ
| Dimension | the provider APIs | Shim |
|---|---|---|
| Setup | None, the provider SDK and a key | One base URL and one key |
| What the provider receives | Exactly what your application sent | The same request with personal data replaced by tokens |
| Spend visibility | Per provider account, after the fact | Per key, team, project and tag, per request |
| Switching providers | A code change per SDK | A model name |
| Evidence | Whatever you logged yourself | A hash-chained audit record built for export |
| Added latency | None | Gateway overhead in the tens of milliseconds |
The code change
The diff, in full
Nothing else in your code changes, same client library, same request, same response. Your provider key moves into Shim, and your application holds a Shim key instead.
Before· today
from openai import OpenAI
client = OpenAI(
api_key="sk-..."
)After· through Shim
from openai import OpenAI
client = OpenAI(
api_key="sk-shim-...",
base_url="https://api.getshim.tech/v1"
)What it takes
Minutes per service.
This is the smallest migration on this site, because there is nothing to unwind: no proxy config, no prompt library, no routing rules. Point one service at Shim, watch it in the request explorer, then move the rest. Most teams run one service through the gateway for a week before cutting over the fleet.
- An answer to "what did we send?" that does not depend on someone having thought to log it.
- One credential surface: provider keys live in the gateway, encrypted, instead of in every service's environment.
- Cost attribution per team and project, from the request rather than from a monthly invoice.
- Provider failover and model swaps without touching application code.
What Shim does not do
- A hop you did not have before, and therefore latency you did not have before, plus one more component that can fail.
- A vendor in your critical path. Self-hosting is available on the Enterprise plan, and the deployment model is part of the scoping conversation.
- Provider features that never had an OpenAI-compatible shape may not be reachable through the gateway.
Stay where you are when
Calling the provider directly is the right answer
- You are prototyping. Do not put a gateway in front of an idea you might delete next week.
- Your prompts provably carry no personal data and no one is asking you to prove it.
- Every millisecond counts and you have measured that gateway overhead breaks your budget.
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.