What one check call covers
Sent to a dead address, an email doesn't just fail, it testifies against you: every hard bounce tells mailbox providers you don't know your own list. A check API runs the layers before that happens: syntax, then MX records on the domain, then whether the mailbox itself exists and accepts, then disposable and role-address flags.
In Nitrosend it's the enrich call
Most verifiers are a separate subscription with an export-upload-download loop. Here the check lives inside the contact record: enrich the contact, and the verification status lands in the same table you send from, NeverBounce under the hood.
curl -X POST https://api.nitrosend.com/v1/my/contacts/{id}/enrich \ -H "Authorization: Bearer $NITROSEND_API_KEY" → { "verification_status": "valid" }
Run it at signup to catch typos while the user is still there, on import to keep a bought-or-old list from torching your domain, and quarterly as hygiene.
Signup is also where we check ourselves. After a bot wave hit our own signup form with disposable-domain addresses, we hardened the gate with a curated blocklist, subdomain-aware matching, and closed the side doors the bots were routing through. And every brand-new account's first multi-recipient campaign without a verified sending domain lands in a manual review queue before it goes anywhere. The checks we sell are the checks we live behind.
When the send really matters, I stack the checks. Before one recovery send I filtered on prior-blacklist flags, plus the full suppression list, plus verification-valid, plus a real engagement signal, and only then let the send go. Belt, braces, and a second belt. That send recovered the domain's reputation.
Full parameters and responses live in the REST API docs and the API reference.
Go deeper
Why the bounce math is unforgiving: the email validation API guide, with the 22.8%-to-0.20% story. Security side: API-based email security.