The catch-all lookup

curl -sS https://api.emvero.tech/v1/accept-all \
  -H "Authorization: Bearer emv_your_credential" \
  -H "Content-Type: application/json" \
  -d '{"domain":"yahoo.com"}'

{
  "domain": "yahoo.com",
  "ascii_domain": "yahoo.com",
  "accept_all": "yes",
  "source": "provider",
  "provider_profile": "provider:yahoo",
  "mail_routing": true
}

It costs nothing. No credits are spent, no X-Credits-Charged or X-Credits-Remaining is returned, and an empty balance does not refuse it.

It contacts no mail server, ever, and that is a guarantee rather than an optimisation. It reports what has already been established; where nothing has been, it says so. This is what makes it free and it is also what bounds it, so it is worth understanding before you build on it — see unknown is the ordinary answer below.

Unlike the disposable lookup it is not quite free to answer: a domain not in the cache costs one resolver query, because part of the answer is keyed by where the domain’s mail goes. Nothing beyond that.

What the answer says

Field
`accept_all`	`yes`, `no` or `unknown`
`source`	what established it: `probe`, `operator` or `provider`. Absent when nothing did
`established_at`	when a record was written. Absent for a `provider` answer
`provider_profile`	the operator this domain’s mail routing classifies into
`mail_routing`	whether the domain can receive Internet mail at all

It uses the same domain records and provider catalogue as a verification reports in checks.accept_all, with the same source precedence. A new observation or expiry can change the state between requests.

`source` is worth reading

The three are not the same claim. Probe observations are used only while they are sufficiently fresh; a stored observation can expire without a new SMTP session being opened by this lookup.

probe — SMTP evidence was gathered at this domain, on the date in established_at. A control recipient or a recipient-specific refusal can establish the state. This is an observation about the domain, not a final decision about the submitted address.
operator — somebody recorded it about this domain deliberately. It outranks a probe’s and does not expire.
provider — the reviewed catalogue, speaking about the operator rather than about this domain, and reaching every domain that operator hosts. It carries no date, because it is a decision and not an observation. yahoo.com, aol.com and att.net all answer this way from one entry.

A domain’s own record always wins. mail.ru answers operator, not provider, even though the catalogue would have said the same thing.

`unknown` is the ordinary answer

Most domains have never been established either way, and this lookup will say so rather than find out. "accept_all": "unknown" means no current source establishes the state. The domain may never have been measured, a measurement may have been inconclusive, or an earlier observation may have expired. It does not mean the domain discriminates. Reading it as no is the misreading worth guarding against, and it is the expensive one: it would treat an acceptance from a domain that takes everybody as evidence about a mailbox.

Coverage grows as verifications are performed, so a domain unknown today may be answered next week without anything else changing.

Three answers look similar and are not:


`"accept_all": "unknown"`, `"mail_routing": true`	No current source establishes the catch-all state. The domain receives mail.
`"accept_all": "unknown"`, `"mail_routing": false`	No mail server is listening for this domain, so the question does not arise.
`503`	The lookup could not be made. This is about us, not about the domain — see Errors.

What it does not tell you

It answers exactly one question about the domain, and nothing about any mailbox:

It does not verify an address. A catch-all domain accepts every address offered to it, which is precisely why a yes tells you an acceptance there would be worthless — not whether a particular mailbox exists. Nothing is asked of any destination.
It cannot produce a verdict. There is no status, no action and no reason_codes here, because none of them would be earned.
no is not a promise that an address exists, only that the destination distinguishes recipients — which is what makes a full check’s acceptance worth something there.

Sending an address instead of a domain

domain accepts a whole address, because the code asking this usually has one:

{ "domain": "someone@yahoo.com" }

Only the domain is read. The local part is discarded before anything else happens — before the domain is even normalised — and appears in no response, no log and no error message.

When to use this, and when to buy a check

Use this to decide how much weight to give an answer you already hold, to label a domain in a list you are cleaning, or to tell somebody at a form that a successful check at their domain would not have meant much.

Buy a full check when the question is about an address. This lookup will never open the session that answers that, at any rate limit.

Note the direction of the dependency: catch-all states are established by verifications. This route reports the accumulated result of that work; it does not do any of it.

Errors

Status	Meaning
`400`	`missing_domain`, or `invalid_domain` for something no lookup can be made for. Fix the request; it will not succeed on retry.
`401`	Missing or unrecognised credential.
`413`	The request body is larger than permitted.
`429`	Caller or source budget exceeded. Back off; honour `Retry-After`.
`503`	`lookup_unavailable` — the domain could not be looked up right now.

The 503 is the same decision the disposable lookup’s is, and worth one sentence for the same reason. A service that could not resolve the domain could answer "accept_all": "unknown", and from outside that is indistinguishable from a domain examined and found unremarkable. It refuses instead. Treat it as no answer rather than as a negative one, and retry.