Rotating keys
Replace an API key with no downtime, and revoke one in a hurry.
A key's allowlist is fixed when the key is created. Rotation means creating a replacement key and retiring the old one — which is also what makes zero-downtime rotation straightforward, because both keys are live while you move across.
Planned rotation
Create the replacement. In Workspace Settings → API Keys, use the Rotate action on the existing key. The form opens prefilled with the old key's name and allowed IPs — change the addresses here if they are part of why you are rotating. Copy the new API key.
Deploy the new key. Both keys are now active. Update your secret manager and roll the change out.
Confirm the old key is idle, then Deactivate it. Keep it around for a day or two in case you need to roll back — deactivating is reversible, deleting is not.
There is no forced overlap window and no deadline. Both keys work until you deactivate one.
Rotate on a schedule, not on an incident
Rotating annually — and whenever someone with access to the key leaves — means the procedure is familiar the day you actually need it in a hurry.
Emergency revocation
If a key has leaked, Deactivate it in the dashboard immediately.
Deactivation takes effect on the next request. Medos checks the key on every call rather than caching it, so there is no window in which the leaked key keeps working after you click. Deactivate first, then work through what the key may have reached.
If you need to keep serving traffic through the incident, create the replacement key before deactivating the compromised one — the two are independent.
A leaked key is bounded, not harmless
The allowlist means a leaked key only works from your registered addresses, so the realistic exposure is someone inside your own network or infrastructure. That is narrower than the internet, but it is not nothing — revoke rather than rely on it.
Lost the key?
There is no recovery path: a Developer API key is shown in full only when it is created. Rotate exactly as above — the only thing you lose is the ability to make requests in the gap.
Changing your servers' addresses
Because the allowlist is part of the key, moving to new egress addresses is also a rotation. Add before you migrate: create the replacement with the new addresses, confirm it works from the new infrastructure, then move traffic and retire the old key. Doing it in the other order is an outage the moment your egress changes.
What rotation does not change
- Your workspace and its data are untouched. Keys are credentials, not scopes — retiring one changes nothing about what the workspace contains.
- Patients' OTP verifications are tracked per key, so an in-flight verification made under the old key does not carry over. Patients mid-flow during the switch may be asked to verify again.