Credits

Everything paid for is paid for in credits, from one balance per account. Ten credits is one full verification, and the unit is finer than the answer so that a partial answer can be priced as one.

What came back	Charge
A verdict - `deliverable`, `undeliverable`, `risky`	10 credits
A `domain`-depth answer	2 credits
`unknown` about a domain we established	2 credits
`unknown` we caused - our timeout, our outage, our pacing	free
A parse error	free
`pending`	free (charged where it becomes an answer)

A domain lookup spends from the same balance: 1 credit when it comes back complete, 2 for a complete extended lookup that carries the registration date, 1 for an extended one missing only that date, and nothing when it is otherwise partial or a repeat under the same key.

Three operations are outside all of this. POST /v1/disposable, POST /v1/accept-all and POST /v1/public-provider spend nothing and carry neither header - there is no work behind them worth selling.

What is being sold is the decision

A domain that does not exist is a whole answer at the whole price. We reached it in one DNS query and no SMTP session, and it is as final as this service gets - what you bought is the decision, not the packets.

The same logic runs the other way. An unknown we caused is free, because the work was spent failing. That includes SMTP_PACING_REFUSED - our decision to protect a destination should not appear on your bill.

A cache hit is charged. The cache is our optimisation, not your discount.

Two headers, and they answer different questions

X-Credits-Charged: 10
X-Credits-Remaining: 41230

X-Credits-Charged is what this request spent. It reads 0 on a pending response, which is honest - that verification is charged where it becomes an answer.

X-Credits-Remaining is the balance afterwards. Both are present on every metered answer, including the 402 when the balance is empty.

The reason both exist rather than one: differencing two balances to work out what a request cost attributes a concurrent request’s charge to this one. If you want to know what you spent, read the number that says so.

X-Credits-Remaining is absent when the outcome is uncertain. A number this service does not have is not reported as a zero. That is a 503 accounting_uncertain, and it carries X-Credits-Operation-ID: read GET /v1/credit-operations/{id} to learn what the request was charged - state is active while the hold is open, then settled with charged, or expired when a hold nobody settled was released. Retrying with the same Idempotency-Key reaches the same operation and does not charge again.

Paid requests fail closed

A paid request is never served without the operation that pays for it. When the balance cannot be reached, a verification answers 503 accounting_unavailable and does no work; when we have paused accounting on purpose, it answers 503 accounting_paused with a Retry-After. Retry both with backoff. The free lookups do not touch the balance, so they keep answering through either.

This reverses what this page said until 2026-09-21, when a verification was served uncharged through a ledger outage. It is the one exception to the rule that a dependency failure degrades the answer rather than refusing it, and the reason is the one below: what somebody has paid for is not something to be uncertain about.

An empty balance is a `402`, never an `unknown`

402 insufficient_credits is a hard refusal. The fail-open rule that makes unknown the answer to everything ambiguous is about what the service knows, not about what somebody has paid for - reporting an unpaid balance as uncertainty would be a different kind of lie.

The maximum is reserved before the work and the actual price settled after it. A full verification holds 10 credits while it runs and releases whatever the answer turns out not to cost - an unknown we caused releases all of it. So an account holding fewer credits than the maximum is refused with 402 even when the answer would have cost less, and concurrent requests cannot spend more than the balance holds: there is no overdraft.

Where to see them, and where to buy them

emvero.io/account/ is the balance and what it went on: granted, spent, what is left, and a per-day breakdown by API key over the last 7, 30 or 90 days. Those are credits charged, not requests made - an unknown we caused and a malformed address cost nothing, so the chart is lower than your request count and that is not a discrepancy.

It is the same number X-Credits-Remaining carries. Nothing about it is cached: a balance served from memory is one that disagrees with the invoice, so an unreachable ledger shows as unavailable there rather than as a zero - for the same reason the header is absent rather than zero here.

emvero.io/account/credits/ is where you buy more. Credits go in volume from 100,000, and the price per credit falls as volume rises; the calculator there and the grid on emvero.io/pricing read the same published model, so the two cannot contradict each other. The volume is what leaves the page - never a price, because a browser deciding what something costs is not a quote.

Purchased credits last twelve months from the payment. Credits spend on any operation: a purchase is not tied to verifications or to domain lookups.

There are no plans and no capability tiers. Every account has the same product; what differs is how many credits it holds.

The free tier

An account gets a hundred verifications’ worth of credits - 1,000 of them - once, when control of its address is proven. It works through the API, appears in the balance and shows up in the usage report, because it is credits rather than a mechanism of its own. It is granted once per account and is not refreshed.

Credits rather than a count of checks is the part worth acting on: the same grant is 100 full verifications, 500 domain-depth answers, 1,000 domain lookups, or any mix of them.