AddThisFeature

OAuth Token Refresh Recovery

Keep connections alive when short-lived provider tokens expire.

involved Integrations

What it adds

A refresh lifecycle that renews access tokens safely under concurrency and stops cleanly when renewal is impossible.

What your agent is told to do

6
  1. 1

    Refresh proactively, shortly before expiry, rather than waiting for a 401. Also handle the 401 path — provider clocks and your clock disagree.

  2. 2

    Serialize refresh per connection with a lock. Concurrent refreshes race, and with rotating refresh tokens the loser's token is already dead — the whole connection dies with it.

  3. 3

    Write the new access token and any replacement refresh token in one atomic update. A crash between the two leaves the connection unrecoverable.

  4. 4

    Classify refresh failures. A network error or 5xx is retryable with backoff; invalid_grant is permanent. Do NOT retry a permanent failure — it burns quota and never succeeds.

  5. 5

    Notify the user only when a human must reauthorize. A transient refresh failure that self-heals must produce no notification at all.

  6. 6

    The status surface and the reconnect button are owned by Integration Connection Health; set the state and let that feature render it.

Edge cases it handles

6
  • Some providers rotate the refresh token on every use and some do not. Handle both; assuming the wrong one silently breaks connections after the first refresh.
  • A request that was in flight when the token expired must be retried once with the new token, not dropped.
  • Background jobs and web requests may both hit expiry at once. The lock has to span processes, not just threads.
  • A refresh token can expire from disuse. A dormant connection needs the same reauthorization path as a revoked one.
  • Storing the new token must survive a failed write to the provider-facing side — never delete the old token until the replacement is committed.
  • Repeated invalid_grant across many connections at once usually means a provider-side app change, not user error. Detect the pattern and alert operators before mass-emailing users.

Definition of done

8
  • Tokens are refreshed before expiry, and expired-token responses are also handled.
  • Concurrent refresh attempts for one connection are serialized and only one call reaches the provider.
  • Access and rotating refresh tokens are persisted atomically.
  • invalid_grant halts retries immediately; transient errors back off and retry.
  • Users are notified only when reauthorization is genuinely required.
  • A crash mid-refresh leaves the connection either on the old token or the new one, never on neither.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.