ends correctly, Ralph needs to know when the client signs. DocuSign's webhook system is called "Connect." To receive signing notifications, Ralph must: 1. Register a webhook listener URL in the DocuSign admin console (GUI operation, not API) 2. Host an HTTP endpoint at that URL that accepts POST requests 3. Parse the incoming payload — which is XML, not JSON: ```xml a1b2c3d4-e5f6-7890-abcd-ef1234567890 Completed 2026-02-07T14:23:45.0000000-08:00 Signer chen.wei@globalretail.co Completed 2026-02-07T14:22:31.0000000-08:00 ``` The REST API returns JSON. The webhook system delivers XML. Ralph is working with two serialization formats in the same workflow. The webhook XML schema includes nested `RecipientStatuses` arrays, envelope custom fields, and document PDFs embedded as base64 within XML CDATA sections. Connect also supports an alternative: polling. Ralph can call `GET /envelopes/{envelopeId}` periodically to check the status. But the eSignature API rate limit is approximately 1,000 requests per hour per account (the exact limit is, per DocuSign's documentation, "subject to change"). If Nicole sends eleven envelopes per month and Ralph polls each one every five minutes until signed, the polling volume is manageable. But Ralph has no way to know when the client will sign — it could be thirty minutes or five days. Polling for five days at five-minute intervals is 1,440 requests per envelope. Multiply by eleven active envelopes and Ralph exhausts the rate limit doing nothing but waiting. ## The Sandbox Gap Ralph has been working in DocuSign's developer sandbox — `demo.docusign.net`. The sandbox is a separate environment with separate credentials, separate templates, separate accounts, and separate webhook configurations. When Nicole is ready to go live, Ralph must: 1. Request production API access (a manual review process called "Go Live" that takes 1-3 business days) 2. Re-register the integration key with the production RSA keypair 3. Obtain consent again — this time on `account.docusign.com`, not `account-d.docusign.com` 4. Re-create or migrate the template (templates do not transfer between sandbox and production) 5. Update the webhook listener URL in the production Connect configuration 6. Change every API base URL from `demo.docusign.net` to the production URL, which varies by data center (`na1.docusign.net`, `na2.docusign.net`, `eu.docusign.net`, `au.docusign.net`) and is only discoverable by calling the `/oauth/userinfo` endpoint after authentication Ralph has been building against a sandbox for three hours. The path to production requires Nicole to click consent in a browser again, wait for a manual review, and reconfigure templates in a different environment. Ralph cannot do any of these steps autonomously. ## Nicole Checks In Nicole finishes her client call at 3:45 PM. She has four messages from Ralph: > 1. JWT auth configured. Required your browser consent (completed). Access token working in sandbox. > 2. Template-based envelope sending works for standard 3-page engagement letters. Non-standard terms (4+ pages) break tab coordinates. Need manual template update in DocuSign GUI. > 3. Webhook notifications require an XML listener endpoint. Currently polling envelope status as a workaround — rate limits are a concern at scale. > 4. All work is in sandbox. Production access requires: your browser consent (again), manual Go-Live review (1-3 days), template recreation, and URL reconfiguration. Nicole wanted one thing: when a deal closes, the contract gets signed. Instead she has a sandbox workflow that handles the common case, breaks on non-standard terms, requires her to click a c