Rotate a provider credential without downtime

Rotating a provider key is a task every organisation performs and nobody wants to perform for the first time during an incident. The mechanics are simple; the order is what decides whether it is uneventful.

The order

1. Create a new key at the provider

   Do this in your OpenAI, Anthropic, Google Gemini or Grok account. Leave the old key active — both exist for the length of this procedure, and that overlap is the entire trick.

2. Update the credential on the gateway

   Replace the stored value for the existing credential rather than adding a second one. The gateway, its API keys and its settings are untouched, so nothing downstream needs reconfiguring and no deployment is involved.

3. Confirm requests are succeeding

   Send real traffic and check the gateway's request log. Requests served after the update use the new value, so a successful request is direct evidence the new key works.

4. Only then revoke the old key at the provider

   Once you have confirmed the new one. Reversing these last two steps is the same procedure with an outage in the middle.

Why the old key cannot be read back

A saved provider credential is never returned by Salyro. There is no read path for the value — the dashboard shows the provider, the name, the status and the date, and nothing else. Salyro fetches the secret while it is serving a request and does not hand it back out.

This is deliberate and it is one of the reasons to route through a gateway in the first place, but it has a practical consequence for this task: you cannot copy the current value out of Salyro before replacing it. If you need the old key preserved, it has to come from the provider or from wherever you recorded it when it was issued.

What happens at the moment of the switch

Requests served after the update use the new value. A request that was already in flight was issued against the value fetched when it started, and it is the provider that answers it — so if you revoke the old key at the provider while requests are still using it, those requests fail at the provider rather than at Salyro.

That is exactly the window the ordering above closes. Confirm first, revoke second, and there is no interval in which the key Salyro holds is one the provider no longer honours.

When the key may already be compromised

The procedure above optimises for continuity, which is the right trade-off for a scheduled rotation. It is the wrong one when you have reason to believe the key is exposed: there, revoke at the provider first and accept the interruption, then connect the replacement.

If what leaked was a Salyro API key rather than a provider key, that is a different procedure — see Respond to a leaked API key.

After the rotation

Nothing else changes. Your Salyro API keys are unaffected, since they authenticate against the gateway rather than against the provider, and the gateway's logs, conversations and usage history continue uninterrupted across the rotation.