Rate limits and daily allowances

Two ceilings, the headers that tell you where you stand against each, and how to back off.

Last updated 26/08/2026

Two ceilings apply to an API key, and they answer different questions. 300 requests per rolling minute stops a runaway loop. An allowance per account per UTC day, set by your plan, is what the plan sells. Both report where you stand on every response, so a well-behaved client never has to guess.

Per minute, per credential

The minute limiter counts per credential, not per address. Your API key has a bucket of its own, separate from every member of staff working in the application and separate from any other key the account holds, so an integration cannot consume the company's allowance and the company cannot throttle your integration.

Every response carries the state of that bucket:

Exceeding it returns 429 with a Retry-After header in seconds.

Per day, per account

The daily allowance is a property of the account's plan and is shared by every key it holds. It resets at midnight UTC, whatever the account's own timezone. A response to an API key reports where the account stands:

Exceeding it returns 429 with a Retry-After counting down to that rollover, and a machine-readable code:

{
  "code": "daily-quota-exceeded",
  "statusCode": 429,
  "message": "This account has used its allowance of 50,000 API requests for today. The allowance resets at midnight UTC.",
  "error": "Too Many Requests",
  "timestamp": "2026-08-26T21:14:03.221Z",
  "path": "/v1/envelopes"
}

The presence of code is what tells the two ceilings apart: a minute-limit 429 carries no code, and clears in under a minute. A daily 429 may be hours from clearing, and is worth alerting on rather than simply sleeping through.

All six headers, and Retry-After, are exposed to browsers under CORS, so a front end that calls the API through your own server can still surface them.

How to behave

Read X-RateLimit-Remaining and slow down before you run out. It is cheaper to pace a bulk job than to recover from a wall of refusals partway through it. A job sending several hundred envelopes should aim to sit comfortably under the minute ceiling rather than sprint into it.

Treat 429 as retryable, and honour Retry-After. It is a wait, not a fault. Sleep for the number of seconds in the header and try again; do not retry immediately, and do not treat it as a failure of the underlying operation.

Give retries exponential backoff and a little jitter. Several workers that all back off by the same fixed interval come back in step and hit the ceiling together.

Pair retries with an idempotency key on anything that creates something, so that a request that had already succeeded when the connection dropped does not create a second copy. See Idempotency.

Prefer webhooks to polling. Polling an envelope for a status change is the most common way an integration spends its allowance on nothing. Subscribe once and be told: Webhooks.

A note on the public pages

The signing ceremony, the public proposal pages and the login form carry their own tighter limits. Those surfaces are anonymous and none of them is reachable with an API key, so they do not affect your integration's budget. The two ceilings above are the ones to build against.