Integrations · Smartlead
No Smartlead app, no sync, no sending. RichAPI finds and verifies the contacts; you move the finished file into a Smartlead campaign. For agencies the point is the verify pass: one bad list on a shared sending domain damages every client on it, and verifying a miss costs nothing.
Last updated September 22, 2026
Copy, paste, edit the brackets, run.
Why it matters
Agencies run many clients across a shared sending infrastructure, and a bounce rate is a reputation event, not a metric. Verification is the cheapest endpoint we sell and a miss on it costs zero, so there is no volume argument for skipping it.
There is no RichAPI app in Smartlead, no sync, and no sending on our side. We find contacts and check whether their addresses are real. You move the finished list into a campaign. That handoff is a CSV or an API call you make, not a connector we maintain. If you wanted a connector this is a worse page than a competitor's. It is also the accurate one, and the accurate version happens to be the shape an agency wants anyway, because the thing you actually need before a Smartlead campaign is not a sync, it is a verified list.
Agencies run dozens of clients across sending infrastructure that shares reputation more than anyone likes to admit. A list with a 9% bounce rate does not damage one campaign. It damages the inboxes, and the inboxes are warming for everyone. So the pipeline is boring on purpose: 1. **Build the list.** `people_search` against an ICP filter, or `linkedin_company_employees_search` against a named account list, or a CSV the client sent you. 2. **`email_finder`** over the rows with no address. 3. **`email_verifier`** over *everything*, including the rows that arrived with an email already in them. Client CRM exports are the single worst input in cold email. Half of those addresses were typed by a salesperson in 2022. 4. **Split on status.** Valid ships. Catch-all is a judgement call. Invalid dies. 5. **Load into Smartlead.** CSV on the campaign, or their Add Leads to Campaign endpoint from your script. Step 3 is the one people skip at volume, and the volume argument does not hold: `email_verifier` is `2 credits` per address and a soft fail costs zero. You are not saving money by sending to a list you did not check. You are moving the cost from an invoice to a domain.
No verifier on earth can confirm an address on a catch-all domain, because the server accepts everything. Anyone telling you otherwise is guessing and calling it a score. What you do with them is a business decision, not a data one. Common agency answer: a separate campaign, on a separate domain, at lower volume, and if the bounce rate holds you promote them. Never the same domain as the client work that has to land. Longer version in [catch-all email handling](/use-cases/catch-all-email-handling).
| Endpoint | Cost | | --- | --- | | `email_finder` | `5 credits` | | `email_verifier` | `2 credits` | | `phone_finder` | `25 credits` | | `people_search` | `0.1 credits per result` | | `enrich_company` | `1 credit` | Full price only on results, and that is scoped to the multi-provider waterfall endpoints: `email_finder`, `email_verifier` and `phone_finder`. A miss there returns 2xx with `"billed": false` and costs nothing. `people_search` and the enrichment endpoints bill on a successful 2xx like a normal API. Non-2xx never bills. Tiers on [/pricing](/pricing). For client accounting: create a named key per client and read per-key usage. What we cannot do is cap credits per key. One pool, one balance, and we would rather say that than let you discover it when a client's job drains the month.
When a client asks why 300 of their 1,000 accounts have no email, the honest answer is a per-row record of what was tried, not "the data wasn't there". That record is `execution_log`, returned by the waterfall endpoints with one entry per provider attempt and its status. We do not publish which providers are in the waterfall. They change. The log is the version that is true on the day you ran it.
No sending. No sequences. No reply detection. No inbox rotation. No warmup. No sync of campaign status back into anything. We do not hold a Smartlead credential and there is nothing in our product that knows a campaign exists. Smartlead does all of that, and does it well. We are the step before it. Related, from the [integrations index](/integrations): [email verifier API](/api/email-verifier), [email finder API](/api/email-finder), [list build and verify](/use-cases/list-build-and-verify), [Instantly](/integrations/instantly) for the same handoff with a different sender, and [Claude MCP to Smartlead](/use-cases/mcp-claude-to-smartlead) if you would rather build the list in a chat window.
**Is there a Smartlead integration in your app?** No. Nothing to connect. You export and upload. **Can you push verified leads into a campaign automatically?** Not from us. Script it: our API returns the rows, Smartlead's API accepts them, and the twenty lines in between are yours. Or put a workflow tool in the middle. **Do you read replies or bounces back?** No. We never see the campaign. **Should I verify leads Smartlead already has?** If they have been sitting more than a couple of months, yes. People change jobs and a verified address goes stale. **Can I bill a client for the credits their list used?** You can attribute usage by key. Budgets per key do not exist. **Do you have a bounce-rate guarantee?** No. Verification reduces bounces; it does not make a promise we would have to define in a contract.
25 free credits, no card. Verify a client list you were about to send and see what comes back invalid.