Enrich Coresignal employee member_ids to business contact emails — billed per email.
Synchronous batch (server fans out ~25 req/s internally). Billed per email
FOUND; ids with no email (NOT_FOUND) or EEA/UK ids (NOT_ACCESSIBLE, GDPR)
are free, omitted from the rows, and counted by reason in ``misses``. A
batch of European ids can therefore come back with zero emails at zero
credits, and ``misses`` is what distinguishes that from a failure. Per-id
misses never abort the batch. An account-level failure (bad key, zero
credits, rate limit) stops it, and so does a network error that outlives
its retries or an unparseable response on any single id — the response
then carries ``warning`` and ``truncated``.
Verified vs in-data emails: every employee record already carries a
``primary_professional_email`` field, available through entity_fetch at no
extra credits, but that address is usually unverified. This tool verifies
that the address is correct and deliverable, and bills only for the emails
it confirms.
Returns:
str: JSON. inline -> {delivery:"inline", requested, count, results:
[{member_id, email, email_status, email_confidence}], misses,
credits_consumed}. url -> {delivery:"url", url, count, total_count,
fields, reason, misses, credits_consumed} (no sample — the rows are in
the file), where total_count is the ids SENT and count the emails
FOUND. ``misses`` counts the unbilled ids by reason: not_found
(no email on record), not_accessible_gdpr (withheld, EEA/UK), stale_id,
unavailable. A ``warning`` means something failed AFTER emails were
billed and they are in this response anyway: an account error cut the
batch short — also setting ``truncated``, with the ids past that point
never requested — or the artifact upload failed and the rows came back
inline instead of as a file. Errors -> "Error: <message>".
