Create Verification Run
create_verification_runCreate a run that finds the CONTACTS in a scope whose email is DEAD. It does nothing until dispatched. It reads the CRM's own bounce record first, at no cost (Salesforce's bounce fields; HubSpot's invalid-address and hard-bounce properties), then, when the tenant has connected an email-verification provider, checks the rest with it, spending one verification per address, at most check_cap of them (default 10,000). The connection's verification rules, a template of tool_type verification, decide how recently checked an address may be and still stand (30 days by default), which results count as dead (invalid and disposable by default), and whether a dead result writes the CRM's bounce date and reason. On its own it lists the dead emails, readable through get_run_records. In a staged plan, put it before the Contact Enrichment run: a contact with a dead email is then not enriched and goes to the Job Change run, unless the data provider still reports the same company, in which case it is enriched and its email replaced.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A name for the run, shown in the Runs tab. It finds the contacts whose email is dead. | |
| check_cap | No | The most email addresses this run sends to the verification provider, least recently checked first; the next run continues where it stopped. This is the run's spend limit. Default 10,000. | |
| filter_spec | No | Which records this run covers, as a filter tree. Omit for the whole object. It DESCRIBES a population and is resolved when the run is DISPATCHED, so write what you mean -- the CRO at Skypoint is `account_name is Skypoint AND title contains CRO` -- and never look a record up to write one. You need no ids and no counts. Call list_filterable_fields first, for the field names and operators only. | |
| connection_id | Yes | The CRM connection. Required. Call list_crm_connections to get one. |