A scheduled connector can have several workers sharing one customer authorization. When an access token expires, two workers may independently try to renew it. With refresh token rotation, the first successful exchange changes the credential that later requests must use.
The resulting failure can look like an intermittent integration outage. Understanding the sequence requires separating a provider's replay protection from the client's coordination of legitimate work.
Rotation creates a sequence of credentials
RFC 9700 describes rotation as issuing a new refresh token with each exchange and invalidating the previous token while retaining information about their relationship. Reuse of an invalidated token can reveal a possible compromise. For public clients, the standard requires sender-constrained refresh tokens or rotation to detect replay. RFC 9700 explains the security requirements.
Auth0 documents one implementation in which detected reuse invalidates the token family, requiring a new authorization grant. Its rotation documentation illustrates why a client cannot treat an old refresh token as an unlimited retry credential. Exact behavior depends on the provider and configuration.
Trace one shared grant across workers
Consider an illustrative accounting connector with two invoice-import workers. Both read credential revision seven. Worker A renews it and stores revision eight. Worker B still holds revision seven and sends another renewal. The provider's response and the client's next action determine whether the connector recovers or repeatedly submits an invalid credential.
A client design can give one worker responsibility for renewal and make other workers wait for the resulting credential revision. Coordination must cover every process that shares the grant. A lock held only inside one process does not coordinate independent queue workers or deployment instances.
Treat a lost response as an uncertain outcome
A network timeout does not establish that the authorization server rejected the exchange. The provider may have rotated the token while the response was lost. Blindly resending the previous token can therefore have a different effect from retrying an ordinary read request.
Define recovery using the provider's documented behavior, including any supported overlap interval. Bound retries, distinguish transient transport failures from revoked authorization, and request reconnection when recovery requires user authorization. An undocumented assumption about token reuse should not determine whether customer jobs continue.
Test the sequence and its customer impact
In a supported test environment, exercise a normal renewal, two concurrent workers, a delayed response, and controlled reuse of a retired test token. Record credential revision numbers, worker identifiers, provider error categories, and resulting job states without recording token values.
Verify that a stopped integration becomes visible to its owner and that reconnecting resumes the intended work without duplicating imported records. The result is a documented renewal state machine and recovery procedure. It explains how the connector preserves continuity while respecting replay protection, including cases that require a person to reconnect the account.
Sources
The IETF and Auth0 references above describe the protocol and one provider implementation. The accounting connector and revision numbers are illustrative.
