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 — sources 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.
Pattern: enriched rows → email_verifier → route on verdict → push only the rows you decided to push
In short: A RichAPI pattern for gating enriched contact rows on verification before they reach an email sequencer. POST https://api.richapi.ai/api/v1/email_verifier returns a deliverability verdict for one address and costs a flat credits_per_call rate. It is a waterfall endpoint, so the zero-cost case is narrow: sources ran and reached no verdict, returning 2xx with success:false and billed:false. A returned verdict bills even when that verdict is negative — an invalid result and a catch-all result are both results and both charge the full call rate. Non-2xx responses never bill. The correct handling of a no-verdict soft fail is to re-queue the row, not to push it as unverified. RichAPI has no email sending or sequencing product. Authentication uses the x-api-key header. New accounts get 100 free credits and require no credit card.
Last updated November 4, 2026
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 source 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
- 01
Sign up at app.richapi.ai and copy your key.
100 free credits, no card.
- 02
Add a verification_status column to whatever table sits between your enrichment job and your sequencer. Default it to null.
- 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.
- 04
Call email_verifier for every unverified row and write the verdict back, along with whether the response reported billed true or false.
- 05
Route on the verdict.
Send the safe bucket, hold the risky bucket, re-queue the no-verdict bucket for a later run.
- 06
Read your usage export and reconcile verified rows against billed calls.
The difference is the soft fails, and it should be small.
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.
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.
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: sources 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 upstream 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. 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 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 is the two-step version, list build and verify the batch version, and the use-case index 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 covers the branch. Endpoint reference: the email verifier API. Agencies running this gate per client should read 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 source 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 source produced an address. The verifier tells you whether it resolves. Two different questions, two different endpoints.
Do I need a credit card?
No. 100 free credits on signup.
Try verify before push: 100 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 100 free credits
FAQ