Limits and paging

What the API will take, and how to walk a long list.

Rate limits

Each key may make 300 requests a minute. Every answer to a request made with a key says where it stands:

Past the limit the answer is 429 rate_limited with Retry-After in seconds. Wait that long rather than guessing: three quick retries land in the same window, fail the same way, and spend the next window's budget as well. Some actions have smaller budgets of their own, named in the refusal: a fresh signing link is ten a minute per document, a reminder one an hour per signer, a signer's one-time code one a minute and five an hour.

Paging

GET /v1/documents pages with limit (1 to 200, 50 when absent) and offset, newest first, and answers beside the page:

{ "documents": [ … ], "total": 312, "has_more": true, "limit": 50, "offset": 0 }

Ask for the next page with offset plus limit until has_more is false. A document made while you walk appears at the front and moves everything after it along by one, so an integration that must see every document once should also find them by what it knows: its own reference (?external_ref=), or the webhook that told it about them.

The other lists are short enough to answer whole: templates (every version), workflows, webhook endpoints, tablets. An endpoint's deliveries are its last fifty.

Sizes

• A request body is at most a megabyte; larger is 413 too_large.
• A document has at most fifty signers; a template at most fifty questions.
• external_ref is up to 200 characters; metadata up to twenty names of up to 40 characters, each with text of up to 500.
• An idempotency key is 8 to 255 characters and is remembered for 24 hours.