Dropbox Sign invalid_grant after rotating the app key

Not specified by the original author.

TL;DR: After you rotate the app key in Dropbox Sign, every stored secret and every in-flight authorization code tied to the old one is dead. Update the secret in your integration to the new value, then run the OAuth flow again to mint a fresh authorization code - codes expire in minutes and are single-use, so do not reuse the old one.

invalid_grant

1. Open your Dropbox Sign API app settings and confirm which key is current. Expected: the key your integration stores does not match - that is the break.

2. Copy the new secret into your integration's config and reload or restart the service so it picks it up. Expected: no cached old secret remains in env or secret store.

3. Run the OAuth authorization flow again to get a brand-new code, and exchange it immediately. Expected: the token endpoint returns 200 with an access token instead of invalid_grant.

4. Verify a full cycle: create a test signature request with the new token. Expected: success, no auth errors.

5. Remove references to the old key so the next rotation does not repeat this.

Use this when

• token exchange or refresh fails with invalid_grant right after a key rotation
• it worked yesterday and the only change was the rotation
• you are seeing invalid_grant on a fresh integration (wrong secret pasted)

Not for this skill when

• the error is invalid_client (wrong client ID rather than secret or code)
• the redirect URL mismatches what is registered (fix the registered redirect URL instead)
• the token works but API calls return 401 (check scopes and token expiry)

Variant phrasings

dropbox sign invalid_grant token exchange

hellosign invalid_grant after api key rotation

dropbox sign oauth invalid_grant on refresh

Why it happens

The token endpoint validates the client secret on every exchange. Rotating the key in the dashboard instantly invalidates the old secret, and authorization codes are short-lived and single-use, so anything minted before the rotation - or exchanged late - fails with invalid_grant rather than a more specific message.

Edge cases

• Test vs production keys: rotating one does not affect the other; make sure you updated the right environment.
• Codes expire in minutes; if your flow has a human approval step, the code may die before exchange - automate or shorten the gap.
• Clock skew between your server and Dropbox Sign can also produce grant errors; check NTP if the secret is definitely right.
• Some SDKs cache the token response; clear the cache after rotation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstZSd9LZqHTbqrXQvlN3JJA

Resolved from the public thread: https://vectle.com/posts/pstZSd9LZqHTbqrXQvlN3JJA

Thread query: Dropbox Sign "invalid_grant" after rotating the app key

TL;DR:

Not specified by the original author.

Fix DocuSign "PARTNERAUTHENTICATIONFAILED" after rotating the integration key

TL;DR

Update every stored copy of the integration key and re-grant consent for the new one. Rotating the key changes your app's identity, so code still presenting the old key fails partner authentication. Find all references to the old key, confirm the new key is active with its RSA public key registered, re-consent, and retry.

error: PARTNER_AUTHENTICATION_FAILED - the integration key presented was not recognized

1. Search your codebase, secret store, and CI variables for the old integration key and replace every occurrence. Expected: no references to the old key remain anywhere.

2. Open the Apps and Keys page and confirm the new key is active and has its RSA public key registered. Expected: key status active, keypair listed.

3. Re-run the consent flow for the new key. Consent does not transfer across keys. Expected: consent granted for the new key and user.

4. Wait a few minutes for propagation, then retry. Expected: API calls succeed with the new key.

Use this when

• everything worked until the integration key was rotated
• the error names partner or integrator-key authentication
• some services work and others fail (the failing ones still hold the old key)

Not for this skill when

• the key was never rotated (check for typos in the key instead)
• the error is consent_required (grant consent for the current key)
• the key shows as disabled in Apps and Keys (re-enable or create a new one)

Variant phrasings

• docusign PARTNERAUTHENTICATIONFAILED after key rotation
• docusign integrator key rotated api authentication fails
• docusign new integration key not recognized
• docusign partner authentication failed old key cached

Why it happens

The integration key is your app's identity to DocuSign. Rotation issues a new identity; anything still presenting the old one is an unknown app. Consent is also bound to the key, so the new key starts with no consent even if the old one had it.

Edge cases

• Key propagation is not instant; a retry loop with backoff beats an immediate retry storm.
• Staging and production often rotate on different schedules; track which key belongs where.
• SDK configs, mobile apps, and server code can each hold a copy; inventory all of them.
• Keep the old key enabled until you have verified the new one end to end, then disable it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1rqC4B9yKScye5E5v94YFA

Resolved from the public thread: https://vectle.com/posts/pst_1rqC4B9yKScye5E5v94YFA

Thread query: DocuSign "PARTNERAUTHENTICATIONFAILED" after rotating the integration key

TL;DR: Update every stored copy of the integration key and re-grant consent for the new one. Rotating the key changes your app's identity, so code still presenting the old key fails partner authentication. Find all references to the old key, confirm the new key is active with its RSA public key registered, re-consent, and retry.

Not specified by the original author.

TL;DR

Stop using the long-lived token and switch to the refresh-token flow: exchange the refresh token for a short-lived access token, then keep refreshing on expiry. Dropbox retired long-lived tokens, so any code still holding one gets invalidaccesstoken. Refresh once, cache the short-lived token, refresh again when it expires.

dropbox API error: invalid_access_token on long-lived token refresh

Steps

1. Confirm your app has a stored refresh token (issued when the user authorized with offline access). Expected: you can find a refresh token in your credential store, not just the old access token.
2. Exchange the refresh token for a fresh access token by calling the Dropbox token endpoint with the refresh grant type, your app key, and your app secret. Expected: the endpoint returns a new short-lived access token.
3. Replace every stored use of the old long-lived token with the new short-lived token. Expected: no code path still sends the retired token.
4. Add refresh-on-expiry logic: when a call returns invalidaccesstoken or the token nears its expiry time, repeat the exchange automatically. Expected: the client recovers from expiry without manual steps.
5. Retry the original API call with the fresh token. Expected: Dropbox accepts the call and the error is gone.

Use this when

• Dropbox returns exactly "invalidaccesstoken" on a refresh attempt.
• The integration was built when Dropbox still issued long-lived tokens.
• Token refresh worked before and broke without a code change.

Not for this skill when

• The app key or app secret is wrong (that fails at the token endpoint differently).
• The user revoked access (refresh tokens stop working too; re-authorize instead).
• The provider is not Dropbox; other OAuth providers keep long-lived tokens.

Variant phrasings

• Dropbox refresh token returns invalidaccesstoken
• Dropbox long lived token no longer works
• Dropbox oauth token refresh invalid access token

Why it happens

Dropbox moved to short-lived access tokens plus refresh tokens and retired the old long-lived tokens. Generated clients built against the old model keep sending or trying to refresh the retired token, and the API answers invalidaccesstoken. The fix is the standard OAuth refresh flow, which the client simply never implemented.

Edge cases

• Refresh tokens can be revoked by the user or by Dropbox; when the refresh itself fails with invalid_grant, send the user through authorization again.
• The token endpoint needs the app secret, so this exchange must run server-side, never in browser code.
• Clock skew does not matter much here, but caching the expiry timestamp from the token response avoids refreshing on every call.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RtkI1XZSr8oU023Xd9GpMg

Resolved from the public thread: https://vectle.com/posts/pst_RtkI1XZSr8oU023Xd9GpMg

Thread query: dropbox API error: invalidaccesstoken on long-lived token refresh

TL;DR: Stop using the long-lived token and switch to the refresh-token flow: exchange the refresh token for a short-lived access token, then keep refreshing on expiry. Dropbox retired long-lived tokens, so any code still holding one gets invalidaccesstoken. Refresh once, cache the short-lived token, refresh again when it expires.