Rate limits & credits

Every request costs between 0 and 4 credits depending on the endpoint. Most errors, stale data, and status checks are always free.

You’re never charged for

Errors all 4xx and 5xx responses cost 0 credits, except 404 which depends on the endpoint (see the pricing catalog).
Check and Usage endpoints always 0 credits, designed for testing and decision-making before spending.

You can test the API freely before committing credits.

Important

When your workspace reaches 0 credits, the free Check endpoints are paused too. A call to POST /v2/fetch/persons/check or /v2/fetch/companies/check then returns 402 NO_CREDITS instead of a result, because no enrichment can follow until you top up. Status and result endpoints stay open: GET /v2/usage, GET /v2/flags, the Search available-fields endpoints, and webhook polling (GET /v2/webhooks/:webhookId) keep working so you can still read your balance and retrieve already-paid results. Top up →

Per-endpoint pricing

The full credit-cost matrix lives in your dashboard. It covers every scenario (cache hit, live scrape, 404 cache, 404 live), async refund rules, and plan gating:

Open the API pricing catalog →

One row per endpoint, one badge per scenario. Updated automatically with the gateway runtime, so what you read there is what gets billed.

The catalog also explains the async billing model in detail: how credits are charged at request creation and refunded automatically based on the outcome (API error, 404 on Search/Contact, 404 on Live endpoints). Refunds are auditable in the Webhook Events dashboard.

Note

Webhook delivery failures are not refunded. When your webhook URL is invalid, returns an error, times out, or is unreachable (webhook-url-invalid, webhook-url-errored, webhook-url-timeout, webhook-url-unreachable), the credit is kept because the data was successfully fetched. The job is reported as succeeded with a deliveryStatus field naming the delivery problem, and the result is populated, poll GET /v2/webhooks/:webhookId to retrieve it.

Rate limits

Two rate limits apply per workspace:

Limit	Scope	Description
Minute limit	Workspace	Maximum requests per minute (e.g. 60 req/min)
Daily limit	Workspace	Maximum requests per day (Enterprise only, disabled by default)

You can also set per-key rate limits to cap individual integrations below the workspace maximum. See API key management for details.

When a rate limit is exceeded, the API returns 429 Too Many Requests. Check the quotas object in any response to see your current usage:

Rate limit response

JSON

"minuteRateLimit": {
  "limit": 60,
  "used": 58,
  "left": 2,
  "nextReset": "2025-01-15T09:31:00.000Z"
}

For retry strategies on 429, see Error handling & retries.

Agent, MCP, and dashboard usage

Not every credit-consuming action shows up as the same kind of usage event:

Agent LLM turns consume credits, but they do not hit the gateway directly and do not count toward gateway RPM.
Agent tool calls use the same gateway endpoints as the REST API. They consume endpoint credits and do count toward gateway RPM when the endpoint itself is RPM-metered.
MCP calls use the same credits and the same rate-limit rules as the REST API.
Polling and status-only endpoints such as GET /v2/usage and GET /v2/webhooks/:webhookId stay free and do not affect gateway RPM.

In the dashboard, the Usage channels section is the best view to understand where credits are going across Agent, MCP, and API usage. The request analytics tabs remain HTTP-request-centric on purpose.

Save credits

Check before you fetch. Call the free Check endpoint first to see if a profile exists and when it was last updated. Then decide: cached fetch (1 credit) or live scrape (2 credits). See Data freshness for the full strategy.

Use Search for bulk discovery. 1 credit per search, up to 100 results per request. Find matching profiles first, then fetch only the ones you need.