Skip to main content
Exact per-endpoint limits can change by plan and endpoint version. Verify active limits in your dashboard.
Rate limits vary by endpoint. The defaults below apply to most accounts. Send an email to gtm@crustdata.co to discuss higher limits if needed for your use case.

​
Core behavior

Crustdata applies per-endpoint request limits. Operationally, you should assume that steady request distribution is safer than bursts, even when total requests per minute look acceptable.

​
Default rate limits by endpoint

Contact endpoints /person/contact/enrich and /batch/person/contact/enrich are grouped with the live endpoints, not with in-database, so their limits do not move with the limits on search and enrich. Raising a live limit is constrained. Contact sales or write to gtm@crustdata.co with your volume.
Watch-management requests are limited to 10 per minute, covering create, list, get, update, test, and delete on both discovery and entity watches. Each watch path keeps its own budget, so exhausting /watch/company/search leaves /watch/company, /watch/person/search, and /watch/job/search with a full allowance. This bounds bursty create and update loops; steady use is unaffected. Every watch response carries the usual counters, and the eleventh request in a minute is refused:
429 - watch-management rate limit
Response headers
X-RateLimit-Reset counts down the seconds until the window rolls over, so wait that long rather than retrying immediately. The four /account/usage/* endpoints share one budget of 60 requests per minute. A burst of /account/usage/events calls also blocks /account/usage/summary until the window resets.

​
Batch job concurrency

Batch endpoints carry a second limit on top of the per-minute rate: a cap on how many jobs you may have in flight at once. A job counts as active while its status is pending or processing. Active jobs are counted in two independent pools, so a queue of enrichment jobs never blocks a live lookup and vice versa: Each pool’s cap is derived from your rate limit on that pool’s endpoints: the highest RPM you hold on any endpoint in the pool, divided by six, then held between 5 and 30. On default limits that is 5 active jobs in each pool, and raising your rate limit raises the cap with it. Your current per-endpoint limits are visible in your dashboard. Exceeding a pool’s cap returns 429 with error.type of rate_limit_error and a Retry-After header:
429 - too many active jobs
The check runs before the endpoint permission check and the credit gate, so a 429 here costs nothing. Poll GET /batch/{batch_id} until a job reaches completed or failed, then submit the next one. A job that has been active for more than 24 hours stops counting toward the limit, so a stuck job does not block your account indefinitely. Rarely, the platform as a whole is at batch capacity. That also returns 429 rate_limit_error, with a message saying so and a shorter Retry-After. It is unrelated to your account’s limits - retry after the interval given.

​
Implementation guidance

To reduce 429 Too Many Requests responses:
  1. Spread traffic across the full minute instead of burst-sending.
  2. Use retry logic with exponential backoff and jitter.
  3. Keep request queues bounded.
  4. Add circuit breakers around non-critical enrichment flows.
  5. Monitor request logs and alert on sustained 429 rates.

​
Client-side best practices

  • Centralize throttling in one shared HTTP client.
  • Use endpoint-specific concurrency and QPS controls.
  • Prioritize business-critical requests when backpressure starts.
  • Cache stable results where your workflow allows it.

​
Rollout checklist

  • Start with conservative throughput.
  • Increase gradually while tracking latency and error rates.
  • Recalibrate limits when you add new endpoints or workflows.
For higher-throughput needs, request custom limits through Crustdata support.