The Token That Expired Mid-Run: OAuth Refresh in Long n8n Workflows

Description and use

In n8n workflows that reuse a single OAuth token, the token can expire mid‑run, causing 401 errors and partial failures. The fix is to check token expiry before each batch, refresh proactively, use a single atomic refresher to avoid races, persist the new token pair atomically, and cap refresh attempts.

Problem

Long n8n workflows that reuse a single OAuth access token fail when the token expires mid‑run, causing 401 errors and partial failures.

Outcome

Implementing proactive token refresh, single atomic refresher, and persistent token storage prevents mid‑run failures and ensures consistent workflow execution.

Workflow

• Fetch access token at start
• For each batch of calls: check token expiry; if less than 10 minutes remaining, refresh token atomically
• Make API calls with current token
• If 401 occurs, retry with refreshed token (safety net)
• Write new token pair atomically to shared store
• Re‑read token before next batch
• Handle revoked tokens by capping refresh attempts and sending review record

Evidence

The access token lived for sixty minutes. The workflow fetched it once at the start and reused it for every downstream call.

Source

The worker now checks the token's expiry before each batch of calls, with a margin. If the token expires in less than ten minutes, it refreshes first, then proceeds.

Source

Token state lives in one database row, not in each execution's memory. Refreshing means claiming that row — an atomic update that only succeeds for one execution — doing the refresh, writing the new tokens back to the same row, and releasing the claim.

Source

The refresh writes back to the same place every run reads from: the credential store, or a single token row that the workflow reads at start.

Source