Provider-specific requirements
Use LeadMagic as a contact-resolution, verification, and intent layer.- Start with cheaper gates:
leadmagic_email_validation,leadmagic_company_search, andleadmagic_jobs_finder. - Escalate to premium contact discovery only after the target is worth it:
leadmagic_email_finder,leadmagic_mobile_finder,leadmagic_profile_search,leadmagic_b2b_social_email, andleadmagic_email_to_profile. - For role-based discovery, use
leadmagic_role_finderfor a single decision-maker andleadmagic_employee_finderwhen you need a wider company roster. leadmagic_email_validationis the final outbound validity gate for this layer. Default acceptance rule isemail_status == valid. treatcatch_allandunknownas unresolved unless the user explicitly accepts risk.- LeadMagic treats catch-all domains conservatively.
email_status: "invalid"with populatedmx_recordandmx_providercan mean the mailbox is unproven. It does not establish non-delivery. Before discarding the row, considerdeepline_nativevalidation or another validator such aszerobounceorbettercontact. - Ads intelligence (
leadmagic_meta_ads_search,leadmagic_google_ads_search,leadmagic_b2b_ads_search) is a fallback, not the default: route Meta, Google, LinkedIn and TikTok ad lookups through the Adyntel tools first (adyntel_facebook,adyntel_google,adyntel_linkedin,adyntel_tiktok_search) and only fall back here when Adyntel returns nothing. The LeadMagic ad-library endpoint has returnedUPSTREAM_ERRORon every call since 2026-10-16. no credits are charged on those failures, but the row stays empty. - If LeadMagic profile or phone quality is noisy on pilot rows, switch to quality-first enrichment (
crustdata_v3_person_enrich,peopledatalabs_enrich_contact) before scaling. Confirm the current schema withdeepline describe <tool-id>: CrustData V3 takes exactly one identifier family,professional_network_profile_urlsorbusiness_emails, as an array. Request the neededfieldsexplicitly (for example,contactfor contact data). do not copy the older camelCase person-enrichment payload into V3.
- For larger or uncertain authorized work, test identity + email candidates on a representative row before scaling. A small supplied Play needs no extra pilot or repeated approval.
- Validate with
leadmagic_email_validationon every candidate. - Keep fallback order explicit in Play control flow: verify
email_1first, thenemail_2only if the first candidate is absent or does not pass the validity gate. Tool completion alone is not a valid-email verdict. - Scale larger work after checking quality and assumptions. Provider changes or paid fallback calls must fit the existing authorization. inspecting a completed run does not authorize paid repair.
deepline plays search "email verification" and
deepline describe <play-ref>. Confirm the tool’s current contract
with deepline describe leadmagic_email_validation.
For a custom workflow, save this as email-verify.play.ts. The order and payload
stay the same, but the success gate is explicit and each attempted verdict remains
available for inspection. Catch-all/unknown are unresolved, not permission to send.
deepline runs get <run-id> and its full-result/export commands (for
example, save to contacts.csv.out.csv), rather than rerunning to inspect it.
Related docs:
Find an applicable action
Confirm your effective workspace, then search the live catalog:Inspect the selected contract
Replace<returned-tool-id> with the identifier returned by discovery:
Prepare one reviewed input
Use one authorized record that matches the inspected schema. Preserve its source identity and define the result you will accept. Open the action reference for its payload and response shape. Provider-backed execution can incur usage or external effects. For reusable logic, follow Write Plays. For direct-call recovery, use Tool execution recovery.Continue only when the workspace, provider, required fields, acceptance rule, and applicable price are understood. Keep unavailable access separate from no-result evidence.