Playbooks · Playbook
The verifier labels a catch-all domain instead of guessing. From there you have exactly two honest branches: try a personal address with find_personal_email, or drop the row. find_personal_email is not a waterfall endpoint and bills on any 2xx, including one that returns nothing.
Last updated September 22, 2026
Pattern: email_verifier → read status → branch to find_personal_email, a separate sending track, or the bin
Credit math: Worked example at stated counts: 1,000 verifications at 2 credits = 2,000 credits, minus zero for any call the waterfall could not resolve. 280 come back catch-all. Sending all 280 to find_personal_email at 5 credits per call = 1,400 credits charged whether or not an address comes back. Sending only the 60 highest-value rows = 300 credits. 2 credits per email_verifier call, 5 credits per find_personal_email call
ROI math: The decision is not whether catch-alls are worth money, it is which catch-alls are. A blanket personal-email fallback on a large list is the single easiest way to spend credits on rows you would never have called. Convert at your tier rate on /pricing.
Owned internally by: Whoever owns deliverability — usually the same person who gets blamed for the bounce rate
Best for: Anyone whose list skews mid-market or enterprise, where catch-all configurations are common and a blanket drop deletes real prospects
curl -X POST https://api.richapi.ai/api/v1/email_verifier \
-H "x-api-key: $RICHAPI_KEY" \
-H "Content-Type: application/json" \
-d '{"email": "jane@acme.com"}'
Verify these twelve addresses. For any that come back as a catch-all domain,
tell me which ones they are and do not guess whether they are deliverable.
Then wait for me to decide which of them are worth a personal email lookup.
Sign up at app.richapi.ai and copy your key.
25 free credits, no card.
Verify the address and branch on status, not on the valid boolean.
valid alone cannot express a catch-all honestly.
Score the catch-all rows on something you already know — account tier, title seniority, whether a rep asked for them.
Send only the rows that clear that bar to find_personal_email, and budget for the calls that come back empty, because they still bill.
Route the survivors onto a separate sending track with a lower volume cap and their own bounce monitoring.
A catch-all domain accepts mail addressed to anything. `jane@`, `ceo@`, `qqqqq@` — the server takes them all at the SMTP handshake and sorts it out later, or never. There is no verification technique, ours or anyone's, that can prove a named mailbox exists behind that configuration. The server refuses to distinguish, on purpose. So every verifier faces the same fork, and what separates them is honesty about it. Return `valid: true` and you have quietly handed the user a bounce risk dressed as a verdict. Return `valid: false` and you have deleted a pile of real, reachable prospects — and catch-all configurations cluster at exactly the mid-market and enterprise domains most people want. `email_verifier` labels it in `status` and lets you decide. The decision is yours, it is a business decision rather than a data one, and there are only two defensible ways to make it. **[Get 25 free credits — no card](https://app.richapi.ai)**
`find_personal_email` looks for an address outside the corporate domain. For a senior contact at a company whose mail server tells you nothing, that is sometimes the only route that exists. Read the billing carefully, because this is where budgets leak. **`find_personal_email` is not a multi-provider waterfall endpoint.** It bills a flat rate on any 2xx, including one that comes back with nothing. The "a miss costs nothing" rule covers `email_finder`, `email_verifier` and `phone_finder`, and it stops there. Every other endpoint in the catalog, this one included, bills on a 2xx whether or not it found anything useful. A non-2xx never bills, on any endpoint. Which makes branch one a filter problem, not a pipeline problem. Running it across every catch-all row on a large list is how you turn a hygiene step into a line item.
Dropping is underrated. If the row is a mid-funnel title at a company you were never going to prioritize, the catch-all label has done its job: it saved you a send and a bounce. The middle option is isolation. Keep catch-all rows, send to them from a separate domain, cap the daily volume, and watch the bounce rate on that track alone. You learn the truth empirically without putting your primary sending reputation on the line. That is more operational work than a toggle, and it is the only method that actually produces evidence. What you should not do is dump catch-alls into the main sequence because the verifier "didn't say no." Bounce rate is the input that gets a sending domain throttled, and it is the one you control completely.
| Step | Count | Rate | Credits | |---|---|---|---| | `email_verifier` | 1,000 addresses | 2 / call, no-verdict calls free | ≤ 2,000 | | `find_personal_email`, all catch-alls | 280 calls | 5 / call, billed on empty | 1,400 | | `find_personal_email`, filtered | 60 calls | 5 / call, billed on empty | 300 | Rates used above: 2 credits per `email_verifier` call, 5 credits per `find_personal_email` call. The gap between those last two rows is the entire argument for filtering before you fall back. Convert at your tier rate on [the pricing page](/pricing) — the rate depends on your package, so there is no single number to quote.
**Branching on `valid` instead of `status`.** A boolean cannot carry three states. If your code only reads `valid`, you have already collapsed the catch-all case into whichever answer the boolean happened to take, and you will never know which rows were affected. **Caching the verdict.** A domain's mail configuration changes. So does employment. A verdict from eight weeks ago describes an address that may now belong to nobody. Verify close to the send. **Assuming a personal address is a better idea.** Sometimes it is a worse one. A cold pitch to somebody's personal inbox reads differently than one to their work address, and in some jurisdictions it is treated differently too. Use branch one when the relationship justifies it, not as a default. **Silent budget drift.** Because `find_personal_email` bills on empty responses, a fallback that runs automatically on every catch-all row will not fail loudly. It will just cost more each month. Put a counter on it.
[Waterfall email then verify](/use-cases/waterfall-email-then-verify) covers the happy path this pattern branches off. [List build and verify](/use-cases/list-build-and-verify) puts it in the context of a full list run, and [ICP filter with AI enrich](/use-cases/icp-filter-with-ai-enrich) is one way to build the score that decides which catch-alls earn a fallback. The endpoint reference is [the email verifier API](/api/email-verifier), [the email finder API](/api/email-finder) explains the waterfall billing in detail, and [the use-case index](/use-cases) has the rest of the plays.
**Can any tool confirm a mailbox behind a catch-all?** No. The server accepts every local part by design, so there is nothing to observe. Anyone claiming otherwise is inferring from patterns and calling it verification. **Is `find_personal_email` free when it finds nothing?** No. It bills a flat rate on any 2xx, empty included. Only `email_finder`, `email_verifier` and `phone_finder` return `billed: false` on a miss. **What proportion of a list comes back catch-all?** It depends entirely on your ICP and we are not going to invent a number. Run a sample of a few hundred rows from your own list and measure it — that figure is worth more than any benchmark. **Should I just delete them all?** Only if your list is large enough that you can afford to. On a tight enterprise list, catch-alls are often where the best accounts live, which is why the isolation track exists. **Can I do this from Claude or Cursor (MCP)?** Yes. `email_verifier` and `find_personal_email` are both exposed as tools on [the hosted MCP server](/integrations/claude), which is a decent way to walk a handful of ambiguous rows by hand before you automate the rule. **Do I need a credit card?** No. 25 free credits on signup.
Verify a dozen addresses from your worst-performing segment and see how many come back catch-all. **[Get 25 free credits](https://app.richapi.ai)**