Resolve up to 1000 hashed emails (HEMs) or plain email addresses in one
call. Each key is resolved exactly as GET /api/v1/lookup would resolve
it: SHA-256 (64 hex) or MD5 (32 hex) hems, algorithm inferred from the
digest length or set per key with hem_type; plain emails are
normalized and hashed for you. Keys may mix algorithms in one request.
Results are in input order, one entry per key. record is the
identity record, or null when the key did not resolve, when filter
rejected the record, or when that key could not be processed. A key that
could not be processed (malformed hem, hem_type that does not match
the hem, an algorithm with no lookup available) carries an error
string on its entry; the request itself still succeeds and partial is
true. Only an outage of the lookup backends fails the whole request.
Filtering and projection. Optional filter and select (in the
body or as query params) apply per record with the same grammar as
GET /api/v1/lookup. A record the filter rejects is returned as null
and is not billed.
Billing. Metered on egress as contact_record: one per entry that
returns a record. Misses, filtered-out records, and per-key errors bill
nothing.
Rate limit. Two requests per second per organization on this route,
in addition to the per-client limit. At 1000 keys per request that is
2000 lookups per second; raise it with your Delivr contact if you need
more.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
400Empty keys, more than 1000 keys, or a body that is not a JSON
object with a keys array. Per-key problems do not produce a 400;
they appear as error on that entry.
401Missing or invalid authentication.
429Rate limit exceeded.
501Batch lookup is not available for test keys (X-Delivr-Environment: test).
502The lookup backends are unavailable.
504The lookup backends did not answer before the request deadline.
