Bundata Docs
What is limited 429 response How to handle 429 Best practices Idempotency Next steps

Rate limits

The Bundata API applies rate limits to prevent abuse and ensure fair usage. When you exceed a limit, the API returns 429 Too Many Requests. This page describes how limits work, how to handle 429, and how to design your integration for high throughput.

What is limited

  • Requests per minute (RPM) — Number of API calls per minute per API key (or per workspace/account, depending on plan). Exact limits depend on your plan; see Limits and quotas.
  • Concurrent requests — Some endpoints may limit how many requests can be in flight at once. Exceeding that can result in 429 or queuing.
  • Page or document quotas — Billing and usage may be measured in pages processed (e.g. one PDF page = one page). That’s separate from request rate but may affect how much you can process in a period. See API reference: Pricing.

429 response

  • Status — 429 Too Many Requests.
  • Headers — Retry-After (seconds or date) suggests when to retry. Use it for backoff when present.
  • Body — JSON with error code (e.g. RATE_LIMITED) and message. See Error codes.

How to handle 429

  1. Back off — Wait at least the Retry-After period (or use exponential backoff, e.g. 1s, 2s, 4s) before retrying.
  2. Reduce concurrency — If you’re sending many parallel requests, reduce the number of concurrent calls so you stay under the limit.
  3. Batch when possible — Use batch endpoints (e.g. submit multiple documents in one request) to reduce the number of API calls. See REST API overview and Extraction runs.
  4. Spread load — If you have a large backlog, spread requests over time instead of bursting.

Best practices

  • Respect Retry-After — Don’t retry before the suggested time; you’ll likely get 429 again and worsen throttling.
  • Use workflows — For recurring ingestion, use workflow orchestration and scheduling so Bundata manages throughput and you avoid hitting limits from ad-hoc scripts. See Workflows overview.
  • Monitor usage — Track request counts and 429 rates. If you consistently hit limits, consider a plan upgrade or batching strategy. See Limits and quotas.

Idempotency

  • When retrying after 429, use idempotency keys for mutation requests (where supported) so a retry doesn’t create duplicate runs or resources. See Error handling.

Next steps

Previous
Error handling