Rate limits trigger 429s during your peak hour
Every major e-signature API rate-limits requests, usually per-account or per-API-key. Your POC sent two envelopes a day and never hit the limit. At a thousand envelopes a month, your traffic clusters around batch jobs and you start seeing HTTP 429 responses.
The fix is to dispatch through a queue instead of synchronously creating envelopes. Use a job runner (Sidekiq, Celery, BullMQ) with concurrency capped below the provider's per-second limit, and exponential backoff on 429. Idempotency keys on the create-envelope call protect you from double sends when retries fire.
Webhooks miss completion events
E-signature providers send webhooks for envelope and recipient events. They retry on 5xx, but most providers stop retrying after a few hours. Network blips, deploy windows, and a 502 from your reverse proxy will silently drop completion events.
Two-part fix: respond 200 immediately and process the event in a background job, and run a daily reconciliation job that polls the provider for envelopes you marked sent more than 24 hours ago without a completed event. The reconciliation job catches what the webhook stream missed.
Bulk send fails when templates drift
Bulk send features depend on field names being stable across the template. If anyone edits the underlying PDF or the template field labels, the bulk job either errors or fills the wrong fields silently. The latter is worse because audit trails look clean.
Lock template editing behind a review process, namespace field labels with a prefix per template (for example, nda_v3_signerName), and version your templates in code rather than only in the provider's UI.
Back to All Questions