A Verifalia alternative for teams that live in the API.

Depth of configuration. Being able to choose how hard a job tries, and to trade time against certainty, is a genuinely useful control that most competitors do not expose at all.

The documentation and the client libraries have been maintained for years across a lot of languages, which counts for something when you are the one who has to keep the integration alive.

Ours is deliberately small. One bearer token, one endpoint for a single address, one for a batch, and the same response object from both. There is no session to establish and no quality level to pick.

That is a trade, not a claim of superiority. Fewer knobs means less to tune and less to get wrong; more knobs means more control if you know exactly what you want. Which is better depends on whether you want to think about verification once or continuously.

• Authorization: Bearer with a key you can rotate independently of the others
• POST /v1/check_email for one address, synchronous
• POST /v1/bulk for a list, returning a job id you poll
• The same verdict, score, reason codes and recommended action from both

The response carries the reasoning, not just the conclusion: documented reason codes and a recommended action alongside the verdict and score. That is what lets you write one integration and change your risk threshold later without another one.

API keys come with any paid plan, monthly or pay as you go, and pay as you go credits do not expire. For a team that verifies in bursts rather than continuously, that shape is usually the deciding factor.

Map the verdict field first and ship that, then use the reason codes for the segmentation you were previously deriving in your own code. Most migrations find they can delete a helper or two.

Handle unknown as its own branch rather than folding it into invalid. It is a 200 with an honest non-answer, and treating it as a failure is the most common way an otherwise clean integration loses real signups.