Skip to main content

When a credit is consumed

Credits are consumed per valid data point returned, not per API call and not per provider tried.
  • A lead whose email comes back deliverable consumes credits.
  • A lead whose email comes back undeliverable, or for which nothing was found, does not.
  • The same rule applies to mobile phone numbers: a number that fails verification is not charged.
  • The waterfall may query several providers for a single lead. You are charged once for the result, not once per provider.
  • A Lead Finder search on its own does not consume enrichment credits. Setting enrich_email_address or enrich_phone_number on the search does.
  • A Company Finder search costs 0.1 credit per company returned. Each page of a paginated search is charged on its own, and a search that matched nothing is free.
  • Enrich a company profile is free and never consumes credits.
  • Enrich a lead profile costs 0.1 credit per profile found, and nothing when no profile matches.
Catch-all emails are charged when catch-all verification is off. When it is on, only emails that come back catch_all_safe are charged.
Every result payload carries credits_consumed for that request and credits_left for the account, so you can reconcile without a second call.

Checking your balance

Response
The balance is shared across your whole organisation, not per user and not per API key.

Running out

There are two distinct behaviours, and they are easy to confuse.
The request is refused with 402. Nothing is queued, nothing is charged, and there is no request_id to poll. Top up, then submit again.
The request switches to the on_hold status. It is not lost: top up and it resumes on its own. Do not resubmit, or you will pay twice for the leads already processed. See Request statuses.
When the balance covers only part of the page, the search returns as many companies as the balance can pay for, and ends terminated. When it cannot pay for a single company, the search ends on_hold, charges nothing, and does not resume after a top up: submit it again.
Submissions are not idempotent. A retried POST that had actually succeeded creates a second request and consumes credits twice.