From reading to action
A practical path through this guide.
Select a step to explore what to do and why it matters.
Capture the access context
Record the connection, environment, response code and last successful operation.
When an integration loses access, identify whether the problem is token expiry, revoked authorization, insufficient permissions, or the wrong account. Reconnecting immediately may restore service, but it can also hide a recurring refresh or ownership problem.
Capture the failure context
Record the connection name, environment, provider response code, and time of the last successful operation. Check whether every request fails or only particular endpoints. A connection that can read contacts but cannot update them may have a scope problem rather than a general authentication failure.
Keep token values out of screenshots and incident reports. Use credential identifiers and redacted error messages. Confirm which person or service account owns the connection before changing authorization on a shared production workflow.
Check the refresh path
For providers using refresh tokens, inspect whether the application stores the latest token set safely and handles provider-specific rotation. Parallel refresh attempts can cause problems in some schemes if one worker keeps using an obsolete token.
Do not assume a refresh token is permanent. Revocation, account changes, provider policy, or inactivity can require renewed consent. Follow the actual provider's documentation and preserve a clear reconnect path for the authorized account owner.
Repair permissions deliberately
Compare required operations with the permissions granted. Request only the access the workflow needs. If a provider requires renewed consent for additional scopes, plan that change with the account owner and test it in the correct environment.
Verify that an employee departure or password policy change did not remove the underlying access. Where supported and appropriate, use an organizational ownership model rather than a personal account that nobody else can maintain.
Restore and reconcile
Test a minimal read and a controlled write before replaying the backlog. Inspect destination records that might have succeeded before the authentication failure became visible. Resume in small batches and track any records requiring manual intervention.
Add an alert for persistent authorization failures and document who can reconnect the account. Repeated failures deserve a root-cause review; a monthly ritual of reconnecting is evidence that the operating model needs attention, not a normal maintenance success.
Further reading
See the OAuth 2.0 authorization framework for the underlying roles and token concepts. Pair credential repair with the incident recovery runbook.
A few practical answers
Frequently asked questions
Does every authorization failure mean the token has expired?
No. Compare the affected endpoint, required scopes, environment and last successful operation. The connection may be valid but lack permission for a particular action.
What should be tested before replaying a backlog after reconnecting?
Verify a minimal read and a controlled write, then reconcile uncertain previous outcomes. Resume gradually while watching for duplicates, delays and repeated authorization failures.
