Dropbox Sign "invalid_grant" after rotating the app key
Fixes Dropbox Sign 'invalid_grant' after rotating the app key. Use when OAuth token exchange breaks right after a key rotation. Key trigger: the integration still sends the old secret, or the authorization code expired.
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_grantOpen 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.
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.
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.
Verify a full cycle: create a test signature request with the new token. Expected: success, no auth errors.
- 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