Playbooks · Playbook

Verify before the push, and know exactly which verifications you paid for

A gate between enrichment and your sequencer: no row reaches a sending tool without a verification verdict attached. email_verifier is a waterfall endpoint, so the free case is narrow and specific — providers ran and reached no verdict at all. A verdict of invalid, or a verdict of catch-all, is a result and it bills. We do not send email; the gate hands rows to whatever does.

Last updated September 22, 2026

Pattern: enriched rows → email_verifier → route on verdict → push only the rows you decided to push

Credit math: Worked example at stated counts: 2,000 enriched rows. 1,870 return a verdict — valid, invalid, catch-all, whatever the enum says — and bill 2 credits each = 3,740 credits. 130 return a soft fail where no provider reached a verdict: success:false, billed:false, 0 credits. Total 3,740, not 4,000. The 130 are re-queued for a later run, not silently pushed. 2 credits per email_verifier call

ROI math: The comparison is not credits against credits. It is 3,740 credits against the cost of bouncing a few hundred addresses from a domain you need for the next two years. Domain reputation has no top-up button. Convert credits at your tier rate on /pricing.

Owned internally by: Whoever owns sending domain reputation — RevOps, growth engineering, or the founder who will be first to notice replies stop

Best for: Any team whose enrichment output flows into a sequencer automatically, and especially any team running more than one sending domain

example
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"}'
the prompt
Verify these 12 email addresses. Group them into three buckets: safe to send,
do not send, and no verdict reached. For the no-verdict group, tell me which
ones cost zero credits and should be retried rather than discarded.
  1. 01

    Sign up at app.richapi.ai and copy your key.

    25 free credits, no card.

  2. 02

    Add a verification_status column to whatever table sits between your enrichment job and your sequencer. Default it to null.

  3. 03

    Make the push step read that column.

    A null value means the row has not been verified and must not be pushed — not that it is fine.

  4. 04

    Call email_verifier for every unverified row and write the verdict back, along with whether the response reported billed true or false.

  5. 05

    Route on the verdict.

    Send the safe bucket, hold the risky bucket, re-queue the no-verdict bucket for a later run.

  6. 06

    Read your usage export and reconcile verified rows against billed calls.

    The difference is the soft fails, and it should be small.

The gate

One rule, and it is a code-level rule rather than a habit: a row without a verification verdict does not reach the sequencer. Not held for review, not flagged, not pushed with a warning. It does not move. Habits fail on the Friday afternoon someone runs a backfill. A null check in the push step does not. **[Get 25 free credits — no card](https://app.richapi.ai)**

What actually costs you nothing, stated precisely

This is the part people get wrong, and getting it wrong in the other direction is worse than getting it wrong in this one. `email_verifier` is a waterfall endpoint. The zero-cost case is **a failure to reach a verdict**: providers ran, none of them could determine anything about the address, and the response comes back 2xx with `success: false` and `billed: false`. Nothing is charged. That is the only free case. In particular: - **A verdict of invalid bills.** The API did its job. It told you not to send. That is a useful answer, it cost providers work to produce, and it costs you the full call rate. - **A verdict of catch-all bills.** "This domain accepts everything, so I cannot tell you whether this specific mailbox exists" is a determination about the domain, not a failure to reach one. It bills. - **A verdict of valid bills**, which nobody is surprised by. - **A non-2xx does not bill**, on this or any other endpoint. So do not budget as though every bad address is free. Budget as though nearly every call bills, and treat the soft-fail line in your reconciliation as a small correction rather than a discount you planned around.

What verify before push costs, at stated counts

| Outcome | Rows | Billed | Credits | |---|---|---|---| | Verdict returned (valid, invalid, catch-all, all of it) | 1,870 | yes, 2 / call | 3,740 | | No verdict reached, `success: false`, `billed: false` | 130 | no | 0 | | Total | 2,000 | | **3,740** | `2 credits per email_verifier call` Convert to currency at your tier rate on [the pricing page](/pricing). The 130 no-verdict rows are the interesting ones operationally, not financially: they are unresolved, they cost nothing, and the failure mode is treating "free" as "fine" and pushing them anyway.

Route on the verdict, do not just filter on it

A filter throws rows away. Routing keeps them and decides what each bucket deserves: - **Valid** goes to the sequencer. - **Invalid** goes nowhere near it. Keep the row, mark the address dead, and do not re-verify it next month out of optimism. - **Catch-all** is a policy decision, not a technical one. Some teams send at low volume from a secondary domain; some route to a LinkedIn touch instead; some drop. All three are defensible, and [catch-all email handling](/use-cases/catch-all-email-handling) walks through the trade-off properly. - **No verdict** gets re-queued. A later run often resolves it, and it cost nothing to learn that today was not the day.

Where verify before push goes wrong

**Null read as valid.** The single most common version of this bug. A push job that selects rows `WHERE verification_status != 'invalid'` happily pushes every row that was never verified at all. Select for the positive verdict, never against the negative one. **Verifying once and trusting it forever.** People leave. Addresses die. A verdict from eleven months ago is a historical note. Re-verify before a re-engagement campaign against an old list, and accept that this costs credits again. **Treating verification as a deliverability programme.** It stops one failure mode: sending to addresses that do not exist. It does nothing for your SPF and DKIM setup, your warmup, your content, or your sending volume ramp. We have no sending product and cannot see any of that. **Assuming valid means wanted.** The address works. Whether the person wants your email is a separate question, and one that the bounce rate will never answer for you.

Plays related to verify before push

This gate sits at the end of nearly every list-building chain we publish: [waterfall email then verify](/use-cases/waterfall-email-then-verify) is the two-step version, [list build and verify](/use-cases/list-build-and-verify) the batch version, and [the use-case index](/use-cases) carries the account-based variants. When the verdict comes back catch-all and you need another route to the person, [catch-all then personal email](/use-cases/catch-all-then-personal-email) covers the branch. Endpoint reference: [the email verifier API](/api/email-verifier). Agencies running this gate per client should read [per-client API keys for agencies](/use-cases/per-client-api-keys-for-agencies) for how the usage attribution works.

Verify before push FAQ

**Is an invalid result free?** No. It is a verdict, it bills the full call rate, and it is worth every credit. It is the result that saved you the bounce. **Is a catch-all result free?** No. It bills too. The only free outcome is a soft fail where no provider reached a verdict at all, which returns `success: false` and `billed: false`. **So what does "a miss costs nothing" mean here?** It means the waterfall ran and came back empty-handed. It does not mean "the answer was bad news." Bad news is an answer. **Does RichAPI send the emails?** No. No sending, no sequencing, no warmup, no inbox rotation. The gate hands verified rows to your tool. **How do I reconcile what I was charged?** Per-key usage with CSV export. Compare billed verifier calls against rows carrying a verdict; the gap is your soft fails. **Should I verify addresses that came straight from email_finder?** Yes. The finder tells you a provider produced an address. The verifier tells you whether it resolves. Two different questions, two different endpoints. **Do I need a credit card?** No. 25 free credits on signup.

Try verify before push: 25 free credits, no card

Run twenty addresses you already believe in and count how many come back with a verdict you did not expect. **[Get 25 free credits](https://app.richapi.ai)**

Frequently asked.

Is an invalid result free?
No. It is a verdict, it bills the full call rate, and it is worth every credit. It is the result that saved you the bounce.
Is a catch-all result free?
No. It bills too. The only free outcome is a soft fail where no provider reached a verdict at all, which returns `success: false` and `billed: false`.
So what does "a miss costs nothing" mean here?
It means the waterfall ran and came back empty-handed. It does not mean "the answer was bad news." Bad news is an answer.
Does RichAPI send the emails?
No. No sending, no sequencing, no warmup, no inbox rotation. The gate hands verified rows to your tool.
How do I reconcile what I was charged?
Per-key usage with CSV export. Compare billed verifier calls against rows carrying a verdict; the gap is your soft fails.
Should I verify addresses that came straight from email_finder?
Yes. The finder tells you a provider produced an address. The verifier tells you whether it resolves. Two different questions, two different endpoints.
Do I need a credit card?
No. 25 free credits on signup.

More playbooks

Try it with 25 free credits.