Authentication — JWT Grant, not authorization code
DocuSign is connected with JWT Grant (server-to-server), not the authorization-code flow used by the OAuth connectors. Two reasons this is not a stylistic choice:- An unattended agent has nobody to click through a consent screen when a token goes stale.
- DocuSign’s authorization-code refresh tokens expire after 30 days. A long-running agent on that flow would silently stop sending envelopes roughly every month — surfacing as “patients stopped getting forms”, days after the cause.
Configuration
environment fails safe: anything that isn’t exactly prod (case- and whitespace-insensitive) resolves to the demo sandbox, so a typo can never point a test integration at live, billable envelopes.
Saving the integration performs a real JWT grant and reads /oauth/userinfo, so a key that parses but was never consented — or an account the user cannot reach — fails at setup rather than at the first envelope send.
One-time consent
If the grant returnsconsent_required, an administrator must grant consent once:
account.docusign.com for production.) The tools surface this case with an explicit message naming the fix rather than the raw OAuth payload.
Account base URI
The REST host differs per account (na3, eu, …), so it is discovered from /oauth/userinfo on first use and cached — never hardcoded to demo.docusign.net.
Not covered yet
- Downloading the signed PDF. Retrieving envelope documents and filing them into a system of record needs the platform’s file-storage plumbing, and pairs with an EHR upload tool that doesn’t exist yet.
- Connect webhooks. Envelope lifecycle events (opened, completed) currently require polling
docusign_get_envelope. - Voiding or correcting an in-flight envelope.