Email · Available on Starter & Team

Stop a fake signup at the form, not three months into a bounced newsletter.

Q: How is an API call authenticated?

By an API key issued from the dashboard (ulv_live_...), not a login session — Starter gets 2 live keys, Team gets 10, each independently revocable without affecting the others. That independence matters operationally: if one key is ever compromised or simply needs rotating, revoking it doesn't require touching any of the others or coordinating downtime across every integration using the API at once. Rotating a key is as simple as issuing a new one and updating whatever calls the old one. Nothing about revoking one key touches the credit balance or usage of another.

A REST API authenticated by key — not a dashboard session — for verifying one address inline at signup or a whole batch from your own pipeline, rate-limited per key so nothing rogue drains your balance.

Start Free → See pricing

Free forever plan, no card required.

Why it matters

Email verification API & webhooks

A registration form that accepts anything ends up full of typos, throwaway addresses and outright fakes — and every one of them still costs you a "welcome" email nobody will ever read, plus a bounce your sender reputation absorbs on your behalf. Catching it in the API call before the account is even created is a different order of magnitude cheaper than cleaning it out of a CRM a year later. That gap compounds fast: a signup form with no verification at the front door doesn't just collect a few bad addresses, it trains people who want a throwaway account that your form doesn't check anything, so the ratio of fake to real signups only gets worse over time. Verifying inline, in the same request that creates the account, means a typo'd or disposable address never gets the chance to become a database row you'll eventually have to notice, investigate, and clean up manually months down the line. It's the difference between a filter at the front door and a mop for the flood that got in anyway. Every fake signup that gets through the front door becomes someone's problem to clean up later, usually with a lot less context than the API call would have had.

Drop-in REST endpoints

POST an address or a batch, get a verdict back — verify, batch, batch status/cancel and credit balance, all authenticated by an issued API key rather than a session cookie. That's a small enough surface to integrate in an afternoon: a signup form calls verify inline before creating the account, while a nightly CRM sync can lean on the batch endpoints instead, all against the same API key and the same credit balance. It's built to be something a single engineer can wire up without a kickoff meeting. It's built to be understandable from the documentation alone, without a support call.

Rate limits that scale with you

60 requests a minute on Starter, 300 on Team, enforced per key — so a single misbehaving integration is contained rather than eating the whole balance in a loop. If you run more than one integration — a signup form and an internal admin tool, say — issuing each its own key means a bug or a runaway loop in one never threatens the rate limit or credit balance the other one depends on. It's a safeguard that costs nothing when everything's working normally and saves a lot when it isn't. It's the kind of safeguard you barely notice until the day it quietly does its job.

A signed webhook when a batch finishes

Team tier gets an HMAC-SHA256-signed completion callback the moment a batch job finishes, with automatic retries — so a bulk pipeline doesn't have to poll for status. That removes an entire class of polling logic from your own code — instead of checking batch status on a timer and wasting API calls on "still running" responses, your endpoint just gets called once, exactly when there's actually something to act on. It's one fewer background job your own infrastructure has to run and monitor. It's a small piece of infrastructure that replaces a recurring engineering chore.

FAQ

Email verification API & webhooks, answered.

How is an API call authenticated?

By an API key issued from the dashboard (ulv_live_...), not a login session — Starter gets 2 live keys, Team gets 10, each independently revocable without affecting the others. That independence matters operationally: if one key is ever compromised or simply needs rotating, revoking it doesn't require touching any of the others or coordinating downtime across every integration using the API at once. Rotating a key is as simple as issuing a new one and updating whatever calls the old one. Nothing about revoking one key touches the credit balance or usage of another.

Can I get notified instead of polling for a batch result?

On Team, yes — a completion webhook fires once a batch job reaches a terminal status, signed with HMAC-SHA256 against a secret you control, with automatic retries if your endpoint is briefly unavailable. Verifying the signature on your end confirms the callback genuinely came from UptimeLuna and wasn't spoofed, and the automatic retries mean a brief deploy or restart on your side won't cause the notification to simply be lost. It's the kind of detail that makes an integration feel production-grade rather than held together with a polling loop. It's the difference between a pipeline that reacts in real time and one that's always a little behind.

What happens if I run out of credits mid-integration?

The API returns a clear error rather than a misleading result, so a signup form or pipeline calling it can handle the situation explicitly — failing open, failing closed, or prompting someone to top up — instead of silently getting back an unreliable verdict. Checking the credit balance endpoint proactively is the easiest way to avoid hitting that wall unexpectedly. It's designed so a credit shortfall is something your code can react to, not something that fails silently. It's designed to fail loudly to your code, never silently to your users.

Get Started

Email verification API & webhooks. Free, starting now.

Start Free →