The access-token lifecycle

The full cycle

The lifecycle is a short loop. Your server posts its client credentials to the token endpoint, caches the returned token alongside its expiry, and attaches it to every partner call. Shortly before the token expires it mints a fresh one and swaps it in. Because there is no user session, there is no refresh token — the client-credentials grant re-mints from the same secret each time.

Caching correctly

Key the cache by client and scope, and store the absolute expiry (now + expires_in, minus a safety margin of a few seconds). Serve the cached token to every worker rather than minting one per request — the token endpoint is rate-limited and a mint-per-call pattern will throttle you fast. In a multi-process deployment, share the token through a small cache (for example Redis) so all workers reuse one live token.

Handling expiry mid-flight

Even with a margin, a token can expire between your check and the server's clock. Treat a 401 with an expired-token reason as a signal to mint once and retry the request exactly once. Do not retry blindly on every 401 — an invalid credential (bad secret, revoked client) also returns 401, and retrying that just burns your token-endpoint quota.