Skip to main content
Captain Data applies one customer-facing rate limit on the v1 API: your subscription plan (requests per second and per minute). Understanding these limits helps you design efficient integrations and avoid interruptions. Rate limits are applied at:
  • 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)
Each plan includes a daily credit quota consumed by billed API calls across your workspace. For how individual endpoints are priced, see Credit costs. Rate limits control request throughput; they are not the same as credits.

Plan Tiers and Rate Limits

Your rate limits are determined by your plan tier, which is based on your monthly credit allocation:
Check your subscription page in Captain Data to see your current plan tier and 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

  1. Implement Exponential Backoff: When you hit the plan rate limit, wait before retrying with increasing delays.
  2. Monitor Your Usage: Track your API consumption to stay within limits.
  3. 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 HTTP 429 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:
  1. Review your implementation design for optimization opportunities
  2. Consider upgrading your plan for higher limits
  3. Contact support for custom enterprise solutions
For detailed information about your current plan’s limits, check your workspace dashboard or contact our support team.