DocuSign "PARTNER_AUTHENTICATION_FAILED" after rotating the integration key

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