All posts
Developers2026/11/04

Uptime guarantees explained for email verification APIs

What API uptime SLAs measure, why live SMTP verification depends on remote mail servers, and how to design resilient client timeouts.

When evaluating an email verification API, teams often ask about uptime guarantees and Service Level Agreements (SLAs). Because real-time email verification talks to thousands of external mail servers over SMTP, understanding what an API availability metric actually covers is essential for building a reliable integration.

API availability vs remote mail server reachability

An API provider controls its own edge routing, authentication, database and queue workers. It does not control the receiving mail server for a recipient's domain. Under RFC 5321, a receiving MTA can delay its greeting (tarpitting), temporarily defer connections (4xx greylisting), or drop packets entirely.

Even when a verification API's own HTTP endpoint is healthy and responds on time, a specific domain's mail server may be unreachable. In ValidReach, that outcome returns HTTP 200 with status: "unknown" and retryable: true (and is not billed), rather than an HTTP 500.

What to check in any vendor's SLA

ValidReach does not publish a financial SLA credit commitment (see our Trust & Security pages for our actual operational controls). When reviewing any vendor that advertises an uptime SLA, read the contract definitions carefully:

  • Measurement scope: does "uptime" measure only whether the HTTP gateway returns a response, or does it include batch queue completion times?
  • Exclusions: scheduled maintenance windows, upstream cloud/network outages and rate-limited requests (429) are almost always excluded.
  • Remedy: most standard SaaS SLAs offer service credits against future invoices rather than cash refunds.

Designing your integration so verification never blocks signups

Never let a third-party network call become a single point of failure in your checkout or registration flow:

  • Set a strict client-side AbortSignal timeout (for example 3 to 5 seconds on a signup form).
  • If the request times out, returns 5xx, or returns status: "unknown" with retryable: true, allow the user to proceed and queue the address for background verification.

Sources

All posts