Skip to main content

Use case

Discover professional or personal email addresses for leads for sales outreach, CRM enrichment, or lead qualification.

Endpoint

API Reference

See the full request/response schema and parameters in the API Reference.

Pricing

See Credits & Pricing Guide for credit costs.

Errors

For error responses (400, 403, 422, etc.), see Handling Errors.

Email modes

The mode parameter controls which type of email the API returns. Defaults to PROFESSIONAL if omitted. If the input lead already includes an email field, the API returns it unchanged with appropriate status and type. In PERSONAL mode, if the existing email is a personal email, the API returns immediately without additional processing or cost.

Response format

The email and personal_email fields contain a list of tuples. Each tuple consists of:
  • Email address (string)
  • Validation status (string, always uppercase):
    • OK — The email address has been validated and is likely deliverable.
    • RISKY — The address may work but could bounce, typically because the domain accepts every address (catch-all).
    • UNKNOWN — Validation was inconclusive.
    • NOT_FOUND — No email could be discovered for this lead.
  • Email type (string, always uppercase):
    • COMPANY — Tied to the company domain.
    • PERSONAL — A personal email address (e.g., Gmail, Yahoo).

Other emails

A lead can have more than one address. With verify_emails on (the default), we check every address a provider returns and put the first deliverable one in email (or personal_email). If none is deliverable, you get the first one that did not fail validation, so always read its status. The rest are listed in other_emails (or personal_other_emails) with their own status, so you can fall back to them:
With verify_emails: false nothing is checked: you get the provider’s first address, and the other-emails list is empty.
  • Addresses that fail validation are left out.
  • In PERSONAL mode, addresses at the lead’s employer are never listed.
  • The field is an empty list when there are no other addresses.

Sync usage

Async pattern

For production workflows, use /find-email-async to submit a job and poll for results. This avoids long-lived HTTP connections and lets you parallelize many lookups without blocking your client. The flow is:
  1. Submit — POST /find-email-async with the same body as the sync endpoint. Response includes a task_id.
  2. Poll — GET /job-status/{task_id} until status is completed, failed, cancelled, terminated, or timed_out.
  3. Read result — When completed, the discovered emails are in the result field, in the same shape as the sync response.
The async start endpoint returns uppercase RUNNING. Subsequent /job-status/{task_id} calls return lowercase statuses. charge_amount is returned in cents, not credits.

Polling example

Webhook callback

Pass a webhook_url to receive the result via HTTP POST instead of polling. The signed payload, retry behavior, and verification steps are documented in Outgoing Webhooks.

Bulk processing

Use /find-email-bulk (sync) or /find-email-bulk-async (async) to process up to 100 leads in a single call. Both accept a leads array and the same mode, verify_emails, and webhook_url fields as the single-lead endpoints.

Bulk sync

Returns 200 OK with results once every lead is processed. Best for small batches where you want a single round-trip.

Bulk async

Submit a batch, get back a task_id, then poll /job-status/{task_id} (or set webhook_url to receive a callback). Recommended for batches of more than a handful of leads, or when you don’t want to hold a long-lived HTTP connection.