Always two steps. Call it first without
confirm to get a free dry-run cost preview — how many leads are chargeable, how many already have an email on file (free), the provider, and the estimated cost. Report that to the user and get their go-ahead. Then call again with confirm: true to actually run it. Nothing is spent on the preview.filter rather than listing ids — filter is resolved server-side across the whole list, not just one page. With neither filter nor ids, it defaults to every lead missing an email (the usual case). Call lead_list_operations with no id first to find the list’s UUID.
Parameters
| Name | Type | Required | Description |
|---|---|---|---|
lead_list_id | string | yes | The lead list’s UUID. |
filter | object | Pick leads by attribute, e.g. { "emailStatus": "none" } (missing an email — the default) or { "domain": "has", "emailStatus": "none" } (has a company domain but no email). | |
ids | string[] | Explicit lead ids — an alternative to filter. | |
confirm | boolean | Omit or false = dry-run cost preview only (spends nothing). true = run it as a background job. |
Returns
Preview (noconfirm):
confirm: true):
When to call it
- The user wants to fill in missing emails on a lead list before outreach.
- Always preview first, surface the cost, and only run on the user’s go-ahead.
Backed by
POST /api/lead-lists/:id/enrich — preview: true for the dry run, background: true for the job. Reuses the 90-day reuse-gate (a lead enriched recently anywhere is free). See also verify_leads for validating the emails afterwards.