Rate limiting | LeadX API docs

LeadX applies a default limit of 60 calls per minute to ordinary synchronous search and enrichment requests. The limit applies across the endpoint group described below, not separately to each endpoint.

Default limits

Your authentication method determines who shares the 60-call allowance:

Authentication	Minute-limit scope	Default
Platform bearer token or MCP OAuth	Each authenticated user	60 calls per minute per user
API key	The client account	60 calls per minute shared by the client's API keys
Either method	The client account	10 simultaneous ordinary synchronous requests

Bearer and OAuth users have independent allowances. For example, 30 users can each make up to 60 calls per minute unless your client account has an additional aggregate ceiling.

API keys do not receive independent allowances. Calls made with any API key belonging to the same client share one client allowance.

The aggregate ceiling is disabled by default. When enabled, it applies across bearer-token, OAuth, and API-key traffic for the client. The concurrency limit is separate from the minute limits and controls how many ordinary synchronous requests can be in progress at once.

Requests that count toward the limit

The ordinary synchronous endpoint group includes:

POST /v1/all-attributes
POST /v1/bbb
POST /v1/companies
POST /v1/contacts
POST /v1/dnb
POST /v1/emails/find
POST /v1/emails/validation
POST /v1/google-reviews
POST /v1/mobile-numbers/find
POST /v1/tax-liens
GET /v1/ucc/companies
POST /v1/ucc/debtor and POST /v1/ucc/debtor/preview
POST /v1/ucc/secured_party and POST /v1/ucc/secured_party/preview

All calls in this group consume the same applicable minute allowance. For example, 40 company searches followed by 20 contact searches use the full default allowance for that user or API-key client.

Authentication, account-management, bulk submission, job polling, and export requests are outside this ordinary synchronous limit. For example, GET /v1/users/me does not count toward the 60 calls per minute.

Routes outside this group can have separate policies selected by credential, HTTP method, and canonical endpoint. Those policies can enforce minute, hour, and UTC-day windows independently.

Read rate-limit headers

Successful limited requests include the applicable limit, remaining allowance, and reset time:

Header	Meaning
`X-RateLimit-Policy`	Name of the applied rate-limit policy
`X-RateLimit-Scope`	Primary scope, such as `user` or `client`
`X-RateLimit-Source`	Whether the policy uses the default or a client-specific configuration
`X-RateLimit-Limit-Minute`	Calls allowed in the current minute window
`X-RateLimit-Remaining-Minute`	Calls remaining in the current minute window
`X-RateLimit-Reset-Minute`	Unix timestamp when the minute window resets
`X-RateLimit-Limit-Concurrent`	Simultaneous requests allowed for the client
`X-RateLimit-Remaining-Concurrent`	Simultaneous request capacity remaining at admission time

When an aggregate client-wide minute ceiling is configured, responses also include:

Header	Meaning
`X-RateLimit-Client-Limit-Minute`	Calls allowed across the entire client in the current minute
`X-RateLimit-Client-Remaining-Minute`	Calls remaining across the entire client
`X-RateLimit-Client-Reset-Minute`	Unix timestamp when the aggregate window resets

A successful request does not include Retry-After.

Handle a rate-limit response

A request that exceeds a minute allowance returns 429 Too Many Requests. The response includes:

X-RateLimit-Window: minute
The exhausted scope in X-RateLimit-Scope
The applicable limit in X-RateLimit-Limit-Minute
X-RateLimit-Remaining-Minute: 0
The reset timestamp in X-RateLimit-Reset-Minute
An accurate Retry-After value in seconds

{
  "success": false,
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Rate limit exceeded",
    "status": 429,
    "request_id": "3f12b95d-743b-4a97-a306-5f616c9bd0c7",
    "timestamp": "2026-09-02T20:52:05+00:00"
  }
}

A request that exceeds the client concurrency limit also returns 429. It includes X-RateLimit-Window: concurrent, X-RateLimit-Remaining-Concurrent: 0, and Retry-After: 1. Its error code is CONCURRENCY_LIMIT_EXCEEDED.

LeadX performs the admission check before executing the requested search or enrichment. A rejected request does not consume billable credits, does not consume an allowance from another configured rate-limit scope, and does not run the requested operation.

When you receive 429:

Stop sending requests for the exhausted scope.
Wait for the number of seconds in Retry-After.
Add random jitter before retrying so concurrent workers do not resume together.
Keep retries bounded and alert an operator if the integration cannot recover within its deadline.

Do not switch API keys to bypass a limit. API keys for the same client share an allowance, and rotating keys makes usage reconciliation unreliable. See Reliability and retries for a bounded retry pattern.