DocuSign API limits

DocuSign API limits bite when onboarding funnels, batch jobs, or CI pipelines create envelopes faster than plan quotas allow. This guide summarizes limit categories and Atlas equivalents for dual-run migrations.

DocuSign limit categories

DocuSign publishes and enforces limits across several dimensions (exact numbers vary by plan and datacenter):

Category	What throttles	Typical symptom
Burst rate	Requests per short window	HTTP 429, retry-after header
Daily envelope count	Sent envelopes per account	Create/send rejected mid-day
Concurrent requests	Parallel connections	Timeouts under load
Connect webhook delivery	Retry storms	Duplicate events if handler not idempotent
Sandbox vs production	Separate quotas	CI passes, prod fails

Always read current DocuSign developer documentation for your account tier. Enterprise deals negotiate custom ceilings.

Why limits show up in search

Teams hit limits when:

Marketing launch creates thousands of accounts in one hour
Nightly ETL resends contracts on data fix
Integration tests run unmocked against production sandbox
Bulk send CSV jobs overlap with API creates

Symptoms look like "random" 429 errors unless you log rate limit headers.

Mitigation patterns on DocuSign

Exponential backoff. Honor Retry-After. Queue creates in worker with max concurrency.

Idempotent handlers. Connect may deliver duplicates. Store envelopeId + event hash.

Separate sandbox. Never point CI at production credentials.

Bulk Send API. Different path than per-row REST create. Confirm licensing.

Account sharding. Multiple sub-accounts divide quotas (operational complexity).

Atlas limits (contrast)

Atlas uses:

Credits at send time (402 when exhausted), not per-seat send caps on entry usage model
Idempotency-Key on create (24-hour dedupe window)
Webhooks at-least-once; verify HMAC and dedupe in your app

Drafts and field detection do not consume credits. Burst create of drafts is lighter than burst send.

For platform tenants, model margin per connected account send volume separately.

Mapping limits in migration projects

When dual-running DocuSign and Atlas:

Log DocuSign 429 timestamps and endpoint
Compare peak creates vs Atlas send rate your middleware sustains
Move low-risk document type first to reduce DocuSign quota pressure
Keep DocuSign Connect handler until webhook parity proven

Route map: DocuSign envelope API.

Monitoring checklist

[ ] Dashboard or log metric for 429 rate by endpoint
[ ] Alert when daily envelope count crosses 80% of quota
[ ] CI uses mocked DocuSign or isolated sandbox account
[ ] Webhook handler completes under Connect retry window
[ ] Atlas webhook handler idempotent on envelope.signed

FAQ

Do API limits apply to embedded signing?

Create and ceremony URLs count against API/account limits. Embedded does not bypass quotas.

Are limits the same in demo and prod?

No. Sandbox has separate maintenance and quota rules.

Does Atlas publish hard RPM numbers?

Contact support for high-volume production forecasts. Pilot measure your actual middleware throughput first.

Where is create envelope documented?

DocuSign create envelope API guide and signature API.

DocuSign burst limit headers

Log response headers on 429:

Which endpoint throttled (create vs list vs download)
Retry-After seconds
Correlation id for support ticket

Patterns in logs beat guessing during quarter close fire drills.

Atlas contrast for burst create

Creating many drafts without send still triggers detection work. Stagger creates if detection queue backs up on huge PDFs. Send consumes credits; create drafts do not.

For CI pipelines, mock Atlas API or use dedicated test API key with low parallel jobs.

Enterprise negotiated limits

DocuSign enterprise accounts may raise ceilings in writing. Archive amendment PDF in vendor folder. Engineering should store limit numbers in runbook, not tribal memory.

Dual-vendor quota planning

When splitting traffic between DocuSign and Atlas during migration, assign document types explicitly so DocuSign quota breathes while Atlas handles overflow category.

Support escalation template

When opening DocuSign support on limits include: account id, endpoint, UTC timestamp, request id, envelopes attempted, business justification for temporary raise.

Rate limit testing script outline

Ramp creates 1→50/min in sandbox
Note first 429
Backoff algorithm verify
Document safe production concurrency

Historical limit incidents (planning)

Quarter-end spikes cause limit tickets that look like outages. Pre-scale concurrency limits in middleware before Black Friday or enrollment season.

Communicate to reps when throttling delays contract sends. Transparency reduces duplicate manual sends that worsen quota pressure.

Atlas migration offload strategy

Route new product-led document types to Atlas while legacy DocuSign templates finish natural contract cycle. Quota pressure eases without big-bang migration.

Monitoring dashboard suggestions

Track 429 rate, envelope create success rate, median webhook latency, and daily send count per vendor account. One Grafana board prevents surprise limit tickets.