- API endpoints — per-second and per-minute caps on requests, based on your plan tier
- Daily credit quotas — total daily usage allowance based on your plan (separate from rate limits)
Plan Tiers and Rate Limits
Your rate limits are determined by your plan tier, which is based on your monthly credit allocation:Capacity Examples
Assuming an average request duration of 2-3 seconds:
Example: With a Silver or Gold tier plan (600 requests/minute), you can:
- Enrich ~864,000 people profiles per day
- Process ~36,000 profiles per hour
- Handle ~600 concurrent enrichment requests
Quotas
Rate limits for quota and billing data retrieval via/quotas:
Best Practices
Optimizing for Rate Limits
- Implement Exponential Backoff: When you hit the plan rate limit, wait before retrying with increasing delays.
- Monitor Your Usage: Track your API consumption to stay within limits.
- Space concurrent workers: Stay under your plan’s requests/second, not only requests/minute.
Handling Rate Limit Errors
When you exceed the subscription plan rate limit, you receive HTTP429 Too Many Requests
with this body (also reflected in response headers when present):
Use
Retry-After when present; otherwise apply exponential backoff.
This plan-limit response uses a nested
error object. Most other API failures use the standard
error_label / error_scope / error_ref shape. Treat a nested
error.code === 429 as a plan rate limit. A flat body with status_code: 429 and
error_label: "GENERIC_ERROR" is a transient server-side failure — retry with backoff, and do
not expect window or provider details in params.Monitoring and Alerts
Track your rate limit usage through:- API response headers (
Retry-After,X-RateLimit-*) on plan-limit responses - Dashboard analytics
- Webhook notifications for quota warnings
Getting Help
If you consistently hit rate limits or need higher limits:- Review your implementation design for optimization opportunities
- Consider upgrading your plan for higher limits
- Contact support for custom enterprise solutions