Canonical: https://botbento.com/blog/bot-credential-rotation-without-downtime/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 5 MIN READ # How Do You Rotate a Bot's API Credentials Without Breaking Its Routines? Credential rotation and credential revocation are different operations with different failure modes. A bot that treats rotation like an emergency revoke will break its own scheduled routines. This article works through what the OAuth security spec requires, what a dual-key overlap window looks like in practice, and the decision a bot builder has to make before scheduling the first rotation. By BotBento Editorial · Published 2026-10-03 · Updated 2026-10-03 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [Rotation and revocation solve different problems](#rotation-is-not-revocation) - [What the OAuth security spec actually says](#what-the-spec-requires) - [A worked example: rotating a scheduled bot's key mid-cycle](#worked-example) - [What to build into the rotation routine](#what-to-build)[Read as Markdown ](/text/blog/bot-credential-rotation-without-downtime/index.md) ## Key takeaways - Rotation is a planned handoff with an overlap window; revocation is an emergency cutoff with none. Build your bot's routine around the first, and keep the second ready for the day a key leaks. - RFC 9700 requires refresh token rotation or sender-constraining for public clients, and the authorization server issues a new refresh token on every use. Design your bot to always persist the newest token it receives, not the one it started with. - Test rotation by running it while the bot's routine is mid-flight, not between runs. If a job holds a token for the whole duration of a long task, rotating mid-task is the scenario that actually breaks things. ## Rotation and revocation solve different problems A bot that calls a scheduled routine every hour needs its credentials to keep working across that schedule. Rotation replaces a credential before it expires or as a matter of routine hygiene; revocation kills a credential immediately because something went wrong. Treating rotation like revocation — generate a new key, delete the old one, redeploy — creates a gap where every in-flight call using the old credential returns a 401. One analysis of this exact failure mode describes the window between revoking an old key and deploying a new one as where production incidents happen: services return 401s, alerts fire, and someone spends time tracing an outage back to a key swap they thought was safe. The fix most API providers converge on is an overlap window: the new credential is created and works, the old one keeps working for a defined period, and the bot's stored credential is updated before the old one actually dies. That overlap is the part a bot's routine needs to account for — not just 'get a new key' but 'know when the old key stops working and make sure nothing is still depending on it by then.' ## What the OAuth security spec actually says If your bot authenticates via OAuth rather than a static API key, the relevant rule comes from the IETF's current OAuth 2.0 security guidance. It states that refresh tokens for public clients must be sender-constrained or use refresh token rotation, and that rotation means the authorization server issues a new refresh token with every access token refresh response. That second part is easy to miss when wiring up a bot: you can't just store the refresh token once at setup time and keep using it. Every refresh call hands you a new refresh token, and the previous one typically stops working after that. This has a direct consequence for bot code: if your routine refreshes its access token and discards the response's new refresh token, keeping only the access token, the next scheduled run will fail because the stored refresh token was invalidated the moment it was used. The spec's reuse-detection mechanism is designed to catch exactly this pattern — using an old refresh token after rotation looks identical to an attacker replaying a stolen one, and the authorization server may respond by revoking the whole token family. A bot that gets this wrong doesn't fail quietly; it can lock itself out of the account entirely until a human re-authorizes it. Static API keys (not OAuth tokens) aren't covered by this spec, but the same overlap principle applies by convention: most providers that support key rotation keep the previous key valid for a configurable transition period specifically so dependent services don't break. Sources: [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/info/rfc9700/). ## A worked example: rotating a scheduled bot's key mid-cycle Illustrative case: a bot runs an hourly routine against a third-party API using a key stored in a secrets manager. The team wants to rotate that key on a 90-day cadence. One documented pattern for this, from a provider's own key-management API, breaks the rotation into three steps: create a new key, update the application to use it, and delete the old key only after confirming the new one works in production. Applied to the bot: at rotation time, the bot (or an operator) creates a new key alongside the old one. The bot's secrets manager entry is updated to the new key, but the old key is left active rather than deleted. The next scheduled run picks up the new key automatically. Only after that run completes successfully — confirming the new key actually works against the live API — does the old key get revoked. If the bot's routine were instead designed to revoke the old key the moment the new one is created, any run already in flight using the old key would fail, and so would any retry logic that cached the old credential in memory rather than re-reading from the secrets store. The failure mode to design against specifically is the race: two processes refresh or rotate at nearly the same time, and one overwrites the other's new credential before it's been used. For OAuth refresh tokens this shows up as a concurrent-refresh race, where overlapping refresh calls can leave the bot holding a refresh token the server has already invalidated. The practical fix is to serialize refresh/rotation inside a single lock or queue per credential, so a bot's background routine and any manual rotation triggered by a human never collide. Sources: [API Key Rotation - Secure Key Management](https://openrouter.ai/docs/projects/docs/cookbook/administration/api-key-rotation). ## What to build into the rotation routine Three things make rotation safe for a bot that runs on a schedule, rather than on demand. First, always read the credential from the secrets store at the start of each run rather than caching it in process memory across runs — a long-lived cache is exactly what causes a bot to keep using a credential that was already rotated out. Second, if the credential is an OAuth refresh token, persist the new refresh token returned by every refresh call immediately, before the access token is even used, so a crash between refresh and task execution doesn't strand the bot on an invalidated token. Third, keep the old credential valid during an overlap window sized to your longest-running task, not your shortest — a bot with a 10-minute task that rotates credentials with only a 2-minute overlap will intermittently fail on exactly the runs that take longest. The decision a bot builder has to make before scheduling the first rotation is simple to state and easy to skip: does the routine re-read credentials on every run, or only on startup? If it's the latter, rotation requires a bot restart, and that restart needs to happen inside the overlap window, not after it. Write that constraint down next to whatever cadence you pick — 30, 60, or 90 days — because the cadence matters far less than whether the bot actually survives crossing it. ## Primary sources Sources checked 2026-10-03. Standards and product documentation can change; follow the linked version when implementing. - [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/info/rfc9700/) — IETF - [API Key Rotation - Secure Key Management](https://openrouter.ai/docs/projects/docs/cookbook/administration/api-key-rotation) — OpenRouter BotBento is in development. [Suggest a correction](/contact/).