DEV Community

Axel Freeman
Axel Freeman

Posted on Originally published at tapacapi.com

Verify at the moment of use, not at import: why two-step lead workflows rot

#email #api #ai #webdev

Every lead stack I have seen has the same shape: one tool finds contacts, another tool tells you whether the addresses still work, and a spreadsheet sits between them holding the gap.

That gap is where the money goes. Here is the arithmetic that made me stop treating "found" and "verified" as two different products.

Two clocks, running at different speeds

A contact record has two clocks:

  • The person clock. 23% of business contacts change jobs every year (ZoomInfo, 2025). Their mailbox usually follows within weeks.
  • The mailbox clock. 40% of email addresses go dead within two years (NeverBounce) — people leave, domains get retired, aliases get closed.

A two-step workflow verifies on the day the list is imported. The list is then sent to on the day the campaign runs. Between those two dates nothing re-checks anything, so the bounce rate you observe is really a measure of the time between verification and send, not of your vendor's quality.

Static databases typically bounce 10–35%. When the SMTP handshake happens inside the request that returns the contact, that number drops to 2–5% — not because the data is magically better, but because the check and the use are the same event.

What "verify inside the call" actually looks like

Two calls, one of which you may never need:

POST /v1/contacts/search
{
  "industry": "SaaS",
  "job_titles": ["VP Sales"],
  "limit": 20
}
Enter fullscreen mode Exit fullscreen mode

Every returned contact carries its own verification status, because each address was checked over SMTP while the response was being built.

If you already own a list and just want the check:

POST /v1/contacts/verify
{ "emails": ["alex@example.com", "sam@example.com"] }
Enter fullscreen mode Exit fullscreen mode

Same discipline, same price unit: you pay per address that is actually checked. Nothing is stored and re-billed later.

Why this matters more with agents than with humans

When a human runs prospecting, the two-step workflow survives — the human notices a bounce report and re-verifies. An agent does not. An agent that is handed a stale list will happily write 400 emails to it and report "campaign sent".

So if you are wiring lead generation into an agent, "verified" has to be a property of the response, not a step someone remembers to schedule. That is why TAPAC ships as an MCP server (npx -y @tapacapi/mcp, tools tapac_find_contacts and tapac_status) and as a plain REST API with an OpenAPI 3.1 spec — the verification rides along with the search in both cases.

The honest limits

  • If you need free-text enrichment of millions of stored rows, this is not that tool.
  • If your use case is a full CRM with a browser extension, it is not that either.
  • Prices across the category are published and drifting (Apollo Basic $49/user/month billed annually, Hunter from $34/month, Lusha Starter $49.90/month, ZoomInfo does not publish) — check them at the source before you commit.

TAPAC's own model is deliberately boring: 100 free searches, then $0.10–0.50 per verified contact, pay-per-use, no seat licence. Full endpoint list and the OpenAPI spec: the email verification API page · REST quickstart · free key.

Top comments (0)