Rotate a third-party API key without redeploying your frontend

How long would it take you to rotate your OpenAI key today? Not in theory. If the key showed up in a public GitHub repo this morning, count the actual steps: generate a replacement, find every file and environment that holds the old one, update them all, rebuild, redeploy, wait for the CDN to pick up the new bundle, then revoke. For a typical static frontend that is somewhere between twenty minutes and a full afternoon. The revoke step is the only one that actually ends the exposure, and it sits at the very end of that chain.

The delay isn't carelessness. It's architecture. When a key is baked into your deployed artifact, rotation is a deployment, with everything a deployment drags along: CI time, cache invalidation, and the risk that something unrelated breaks while you're in a hurry.

Why baked-in keys make rotation slow

Frontend build tools inline environment variables at build time. A VITE_OPENAI_KEY doesn't stay a variable; it becomes a string literal in your JavaScript bundle, copied to every CDN edge node that caches it. (It's also readable by anyone who opens DevTools, which is why it needed rotating in the first place.)

That gives the key the same release cadence as your code. Rotating it means a rebuild and a redeploy, even if nothing else changed. If the bundle is cached aggressively, users on stale HTML keep sending the old key until the cache expires. And if the same key is shared across a marketing site, a dashboard, and a browser extension, you get to do this three times, in three pipelines, hopefully in the right order.

The stable UUID pattern

The fix is to stop shipping the key at all and ship a reference to it instead. A SaltingIO Bridge is a proxy record: it stores the upstream URL and request headers (including the provider key) server-side, and exposes a single endpoint at https://api.salting.io/r/{uuid}. Your frontend calls that UUID. SaltingIO attaches the stored Authorization header on its side, forwards the request to the upstream, and returns the response. The key never appears in your bundle, your repo, or the browser's network tab. The UUID is the only thing deployed, and the UUID never changes.

That last property is the whole point for rotation. The deployed artifact references something stable, while the secret behind it stays mutable. Rotation becomes a data change, not a code change.

Setup happens once. In the dashboard, go to Secrets and create a Bridge. Point the destination URL at https://api.openai.com/v1/chat/completions, allow only POST, restrict allowed origins to your production domain, and add one header: Authorization with the value Bearer sk-.... Bridges accept up to 20 stored headers, so an OpenAI-Organization header can ride along too.

The frontend then looks like this, with no secret anywhere in sight:

const BRIDGE = "9b1f0c2e-8d4a-4f6b-b2c1-7e5a3d9f0a12";

const res = await fetch(
  `https://api.salting.io/r/${BRIDGE}?select=choices.0.message.content`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      model: "gpt-4o-mini",
      messages: [{ role: "user", content: "Summarize this changelog." }]
    })
  }
);

const summary = await res.json();

The ?select= parameter is optional but worth it here: it applies a GJSON-style path to the upstream response, so the browser receives just the completion text instead of the full OpenAI envelope. View source on this page and an attacker learns a UUID that only answers requests from your allowlisted origin.

The rotation workflow

With the key living in the Bridge, a rotation looks like this:

1. Generate the new key at the provider while the old one is still valid. OpenAI and Stripe both allow multiple active keys at once; use that overlap.
2. Edit the Bridge in the dashboard and replace the Authorization header value. The change applies on the next request through the UUID. There is no build, no deploy, no cache purge, no version bump.
3. Fire a test call from the Playground and confirm a 200 with a real payload.
4. Revoke the old key at the provider.

Then open Logs, filter to the Bridge's UUID for the minutes after the cutover, and confirm the error log stays empty. The exposure window shrinks from "however long the deploy pipeline takes" to the seconds between saving the header and revoking the old key.

Two related notes. If you're changing providers rather than keys, the Bridge's failover URLs let you keep the old destination as a backup while traffic shifts. And on the Enterprise Edge plan, team access control means an Editor can perform this entire rotation. The role's own description reads "can create, read, and update secrets", so an on-call engineer can rotate a leaked key at 2 a.m. without holding Admin rights or the provider account password.

Common pitfalls

Revoking in the wrong order. If step 4 happens before step 2, every request through the Bridge returns the upstream's 401 until the header is updated. From the browser it looks like SaltingIO failing; it's actually OpenAI rejecting a dead key. Keep both provider keys valid through the overlap and revoke last, always.

Confusing the two keys. The provider key stored inside the Bridge and the record's own X-API-Key are different things. The latter only exists if you made the record Private, and it authenticates callers to SaltingIO, not SaltingIO to OpenAI. Rotating the provider key never touches it. One sharp edge: a Private record's X-API-Key is displayed exactly once, on the creation success modal next to a Download .txt button, and never again. Save it immediately or you'll be recreating the record.

Testing from an origin that isn't allowlisted. If allowed origins contains only your production domain, verifying the rotation from localhost:5173 returns a 403 with {"error":"Origin not allowed","message":"Your origin is not authorized to access this endpoint."}. During a rotation that error reads like a broken key, but the key is fine. Verify from the Playground inside the dashboard instead, or temporarily add your dev origin.

Keys that are painful to rotate don't get rotated; they get extended, shared, and eventually leaked with years of standing access behind them. Moving a key behind a stable UUID turns rotation from a deployment into a thirty-second edit, which is the difference between a quarterly chore and a habit. The free Starter tier covers 2,500 requests a month and 5 secrets, enough to move one key behind a Bridge and run a practice rotation end to end. Start building