Credits
Verifications are paid for in credits. 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) |
What is being sold is the decision
Section titled “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
Section titled “Two headers, and they answer different questions”X-Credits-Charged: 10X-Credits-Remaining: 41230X-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 ledger could not be consulted at
all. A number this service does not have is not reported as a zero. When that
happens the verification is still served and not charged, which is availability
beating billing accuracy — deliberately, and measured on our side rather than
discovered later from a discrepancy.
An empty balance is a 402, never an unknown
Section titled “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.
Entitlement is checked before the work and charged after it, which admits a small overdraft under concurrency. The balance is signed and not clamped: an overdraft is shown rather than hidden, because a hidden one is a wrong number nobody can see.
Pricing
Section titled “Pricing”Credits are bought in volume, and the price per credit falls as volume rises. The current grid, the volume breaks and a calculator are on emvero.io/pricing — served from one source, so the calculator and the table cannot disagree.
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
Section titled “The free tier”An account gets five verifications’ worth of credits 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.