Skip to main content
Our API implements rate limiting to ensure fair usage and maintain service stability for all users. Understanding these limits will help you optimize your API usage and avoid disruptions.

​
Account Endpoints Rate Limits

The following account endpoints are limited to 2 requests per minute:
  • Single Enrichment (/accounts/single_enrich)
  • Headcount Analysis (/accounts/headcount)
  • Profile Count (/accounts/count_profiles)

​
Leads Endpoints Rate Limits

The leads enrichment endpoint is limited to 2 requests per minute:
  • Single Enrichment (/leads/single_enrich)

​
Search Endpoints Rate Limits

Search endpoints have stricter rate limits due to their resource-intensive nature:
  • Create Search (/searches/create): 1 request per second
  • Company Search (/searches/search_in_a_company): 1 request per 5 seconds

​
Understanding Rate Windows

Rate limits are calculated based on rolling time windows. For example:
  • If you make 2 requests to /accounts/single_enrich at 10:00:30, you’ll need to wait until 10:01:30 before making another request
  • If you make a request to /searches/create at 10:00:00, you’ll need to wait 1 second before making another request
  • If you make a request to /searches/search_in_a_company at 10:00:00, you’ll need to wait 5 seconds before making another request

​
Rate Limit Responses

When you exceed rate limits, you’ll receive a 429 Too Many Requests response: 
{
  "error": 429,
  "message": "Rate limit exceeded. Please try again in X seconds."
}

​
Best Practices

  1. Implement Endpoint-Specific Retry Logic
    • Add exponential backoff with appropriate intervals for each endpoint
    • Use shorter retry intervals for search endpoints (1-5 seconds)
    • Use longer retry intervals for enrichment endpoints (60 seconds)
    • Include jitter to prevent thundering herd problems
  2. Optimize Request Patterns
    • Use bulk endpoints when available (e.g., /accounts/bulk_enrich)
    • Space out search requests according to their specific time windows
    • Track rate limit headers for each endpoint separately
    • Queue requests that would exceed rate limits
  3. Handle Rate Limits Gracefully
    • Implement proper error handling for 429 responses
    • Use different queues for different endpoint types
    • Consider using a rate limiting library in your client

​
Example Retry Implementation

Here’s a simple example of how to implement retry logic with endpoint-specific timing: 
def make_request_with_retry(endpoint, max_retries = 3)
  retries = 0
  # Define wait times based on endpoint type
  wait_time = case endpoint
              when /\/searches\/create$/
                1  # 1 second for create search
              when /\/searches\/search_in_a_company$/
                5  # 5 seconds for company search
              else
                60 # 60 seconds for other endpoints
              end

  begin
    response = api_client.call(endpoint)
    return response
  rescue RateLimitExceeded => e
    raise if retries >= max_retries

    retries += 1
    # Add jitter to prevent thundering herd
    sleep_time = wait_time + rand(0.1..0.5)
    sleep(sleep_time)
    retry
  end
end

​
Additional Considerations

  • Rate limits are applied per API key
  • Each endpoint’s rate limit is tracked separately
  • Different endpoint types have different rate limit windows
  • Consider implementing separate queues for different endpoint types
  • Monitor your usage patterns and adjust your implementation accordingly
For questions about rate limits or to request limit increases, please contact our support team.