Add context to signup decisions

Combine an email check with the signing-up IP's network indicators to decide whether a signup should proceed automatically or go to review — computed on your backend with POST /v1/signup/check, or assembled from browser-side checks for early feedback.

Read the email-check reference See VPN and Tor detection →

One server-side call at submission

When the signup form is submitted, call POST /v1/signup/check from your backend with the address, the visitor's IP and optionally their User-Agent. It runs the full email check (disposable domain, missing mail server, typo, role address), looks up the IP's VPN/Tor/datacenter/threat indicators on plans that include security data, checks how recently the email domain was registered, and returns a 0–100 score with an accept/review/reject verdict and the reasons behind it. Because it runs on your server with your secret key, the visitor can't forge or skip it.

Early feedback in the form

For a better experience before submission, call POST /v1/email/validate from the form's own JavaScript with your publishable key: show a specific message for invalid_syntax or disposable_domain, and offer didYouMean as a one-click correction for a typo. This is a UX aid, not enforcement — anyone can disable JavaScript.

Network indicators

The signup check's ip.security (or GET /v1/geo's security object in the browser) reports isVpn, isTor, isDatacenter and isThreat for the connecting IP. These are list-based indicators, not a verdict — false means no match in the available data, not a confirmed-clean connection. On a plan without security data the signup score uses email signals only and says so with reason ip_security_unavailable.

Route review, don't just block

Treat reject as a strong signal and review as a reason for an extra step — a confirmation email, a CAPTCHA, a manual look before granting free credits — rather than an automatic rejection. Keep the specific consequence in your own policy; the score's weights are documented so you can see why a signup landed where it did.

Duplicate accounts

Store canonicalEmail (the address without +tags, and without dots for Gmail) alongside each account, and check for it at signup to spot the same person creating several trial accounts. Watch-IP keeps no per-customer history of your signups, so this lookup happens in your own database.

What this doesn't guarantee

No combination of email, domain-age and network signals proves an account is fraudulent or guarantees stopping trial abuse — it narrows which signups deserve a closer look before you commit support or promotional resources to them. None of the checks contacts the mailbox, so an accept is not a confirmed working address.