API integration for Docusign
We build your Docusign connector
We wire Docusign into your business record: the envelope leaves your tool, the signed status comes back, at the right eIDAS level.
- Senior product team
- signature connectors in production
- from scoping to monitoring
What does the Docusign integration do and what happens to a contract once it is connected?
Docusign is the most widely used electronic signature platform in enterprise. Once integrated into your software, Docusign lets you send a document for signature directly from your application, select the required signature level (simple, advanced or qualified depending on legal requirements), and automatically return the signature proof to the file. The contract stops being an email attachment and becomes a business object with a status, a date and legal evidential value attached to the transaction in your system.
What our clients plug into Docusign
Quotes and contracts from the CRM
The envelope leaves from the deal. On completed, fields write back to the record and the file moves to won, with no PDF copy-paste.
Employee onboarding, two levels
Employment contract in AES or QES, annexes in SES, in the same ordered envelope. HR software advances on the webhook, not by opening the Docusign inbox.
Regulated deed in QES
Credit, real estate, health: the signer goes through a QTSP (IdNow is one example). The rest of the file stays SES. The level is a parameter, not a second project.
Automatic archiving in the DMS
On envelope-completed, the signed pack is downloaded once and stored in your DMS. No more Friday-night manual export.
What this changes in your journey
Engineering in service of a measurable outcome: status in the file, the right eIDAS level, zero PDF hunting.
Sales sees whether it is signed
Sent, viewed, signed, declined, expired: status lives in your tool. You stop hunting the contract in a vendor inbox.
The eIDAS level is a parameter
Simple, advanced or qualified is chosen per document type. You do not open a parallel legal project for every new template.
Signer data comes back
Address, IBAN, clauses: filled fields are written into your software. They do not stay trapped in the PDF.
The file moves without manual watching
Notifications are verified, with a regular reconciliation pass. You do not wait for a rep to open Docusign to know.
How we ship your Docusign connector
Scoping
Which documents, which eIDAS level, JWT or Authorization Code, SBS and QES already enabled or not. We list edge cases before writing a line of code.
Development
Envelope creation, Connect with HMAC over the raw body, queue, deduplication on envelope and event type. JWT renewed with no refresh token.
Testing
Sandbox for the flow, then an account with SBS if AES or QES is required. Demo certificates do not verify the way production ones do.
Monitoring
Read X-RateLimit-Limit, alert before 3,000 calls / h, Connect retries tracked for 15 days. You know a flow is broken before your customers do.
What the Docusign API allows
- Envelopes and recipients
- Create, send, track the envelope GUID, up to 100 recipients, tabs and anchors. The business object of every Docusign connector.
- eIDAS levels (SBS)
- SES with no certificate (UniversalSignaturePen_ImageOnly), Docusign eIDAS AES, QES via a QTSP (example docusign_eu_qualified_idnow_tsp). One field, three levels.
- Connect (webhooks)
- JSON or XML POST to a public HTTPS listener. Connect messages do not count against the API quota. HMAC-SHA256 of the raw body, retries for up to 15 days.
- Documents and filled fields
- Download the signed pack, read form_data. Write-back to the CRM or ERP, a single archive at completed, not a re-fetch on every view.
Docusign API vocabulary
- Envelope
- The transaction container: documents, sender, recipients, tabs, status. Identifier = GUID. This is the object your software must know, not the PDF.
- signatureProviderName
- The SBS field that sets the level. UniversalSignaturePen_ImageOnly = SES with no certificate (default). Docusign eIDAS AES. docusign_eu_qualified_idnow_tsp = QES via IdNow.
- JWT Grant
- OAuth flow for a service: impersonate a user, RSA key pair, prior consent, 1-hour token, no refresh. Without consent, the Grant fails even with a valid key.
- Connect
- Docusign webhooks. HTTPS listener, JSON or XML POST. Messages do not consume the API quota. This is the production channel; polling is an admission rule.
- X-Docusign-Signature-1
- HMAC-SHA256 header of the raw body (including line endings). Up to 100 keys (Signature-1 … Signature-N). A handler that parses JSON before hashing fails silently.
- Hourly_Envelope_Polling_Limit_Exceeded
- Named error when envelope status is queried too often. The documented step is 15 minutes (20 recommended). An app off that step does not pass go-live.
The real constraints of the Docusign API
Polling is an admission rule
For a given envelope, status may be queried only once every 15 minutes. An application that polls more often will not be approved for production.
3,000 calls per hour, shared
Per-account quota, read from X-RateLimit-Limit, refreshed on the hour. Burst 200 / 30 s in developer, 500 / 30 s in production. Every integration on the account draws from the same bucket.
SBS and QES are not flags
Without account enablement, recipientSignatureProviders is ignored or rejected. The digital sandbox is not an eIDAS sandbox: demo certificates do not verify the way production ones do.
JWT with no refresh token
At expiry (1 h) you must rebuild a JWT and exchange it again. Impersonation consent is a prerequisite. The RSA private key is stored encrypted, with documented rotation.
Docusign API or Yousign API?
Two eIDAS signature APIs. The right choice depends on your existing stack and how SES, AES and QES are expressed in the product.
| Criterion | DocusignThis page | YousignFrench vendor |
|---|---|---|
| Core object | Envelope (GUID) | Signature Request |
| eIDAS SES / AES / QES | SBS, account options to enable | signature_level enum per signer |
| Authentication | OAuth 2.0, JWT Grant (1 h token) | Bearer, API key |
| Webhooks | Connect, HMAC X-Docusign-Signature-1 | x-yousign-signature-256, 1 s timeout |
| QES in the journey | QTSP, IdNow example, outside iframe | Video + human, no iframe, 30 min |
| API quota | 3,000 / h per account, burst 500 / 30 s | 60 / min and 1,200 / h in production |
| The right case | Docusign already in the stack | French product, eIDAS native in the API |
All three (Docusign, Yousign, Universign) cover SES, AES and QES. None makes QES free or iframe by default. This is a scoping trade-off, not a final choice.
What we measure on a Docusign integration
The other signature APIs
If Docusign is not the right foundation, these options are discussed at scoping.
DocusignWe build your Docusign connectorThis page
YousignFrench v3 API, SES AES QES as an enum, iframe forbidden in QES.
UniversignFive levels, qualified seal and timestamp, JWS PS256 webhooks.We combine Docusign with
The stack around Docusign on our projects.
Docusign integration: your questions
Three steps. First pick the OAuth flow: JWT Grant for a service that sends envelopes with no user session, Authorization Code if a human must log in. Then create the envelope from your business object (quote, contract, amendment) with the right signatureProviderName, SES, AES or QES. Finally wire Connect: verify X-Docusign-Signature-1 on the raw body, push to a queue, return 2xx, deduplicate on envelope id and event type. The hard part is not the POST envelope, it is refusing polling and passing Docusign go-live.
They are the three levels of the eIDAS regulation (EU) No 910/2014. SES: simple electronic signature, in Docusign the default UniversalSignaturePen_ImageOnly, with no certificate. AES: advanced signature, art. 26, via Standards-Based Signatures, Docusign certificate or the signer's. QES: qualified signature, the only level with handwritten equivalence across the Union (art. 25(2)), via a QTSP, for example docusign_eu_qualified_idnow_tsp. SBS is not included in developer accounts by default: it must be enabled. The level is chosen by document type, not by an « electronic signature » boolean.
For a given envelope, status may be queried only once every 15 minutes (20 recommended). An application off that step triggers Hourly_Envelope_Polling_Limit_Exceeded or Burst_Envelope_Polling_Limit_Exceeded, and it is not approved for production. Connect exists for this: webhooks do not count against the quota, and they see transitions including between two signers. GET envelope remains a reconciliation net, not the engine.
A first useful flow, typically sending a quote in SES and writing back on completed, ships in two to three weeks. A chain with AES or QES, JWT impersonation, DMS archiving and Connect reminders is closer to six to eight weeks: SBS enablement and the QES journey outside an iframe weigh as much as the code. Go-live review is part of the calendar, not an afterthought. We scope the perimeter up front and give a firm estimate before starting.
If your teams already sign in Docusign, we integrate Docusign. Yousign exposes SES, AES and QES as an enum per signer, with a French vendor and yousign.app hosts. Universign adds qualified seal and timestamp, and five levels including level3 (AES plus qualified certificate) which is not a QES. All three require a commercial enablement for QES. The choice is a stack and evidence-policy trade-off, not a « best API ».
A Docusign integration project?
Let's talk. 30 minutes to scope your envelopes, the eIDAS level you actually need, and to tell you frankly what is feasible.
Discuss my Docusign project