How to Stop Fake SaaS Signups

Check server-side, at account creation — not client-side, not after the fact

Client-side checks are trivially bypassed by anyone submitting the form programmatically, which is exactly who you're trying to catch. The check needs to happen on your server, as part of the signup request, before the account is created — not as a batch job that runs afterward and flags accounts you've already provisioned resources for.

Use the signup context, not generic

The API's context parameter changes which signals matter. In the signup context specifically, disposable-domain, randomized-local-part signals, and brand-new-domain signals are all weighted up relative to generic — because those are exactly the patterns automated account creation produces, while a role-based address (which matters a lot for a B2B lead form) is largely irrelevant here. Passing context: "signup" isn't cosmetic — it changes the actual score.

A routing framework, not a single filter

The decision field does the routing work for you — allow, review, or block — but what you do with each matters:

The review band is doing the most important work here. It's tempting to treat anything non-zero as suspicious and block it, but that band exists specifically to avoid a binary allow/block decision — most real signups will land somewhere in it, and hard-blocking the entire band will cost you real customers. Email confirmation is a cheap, low-friction secondary check that resolves most of the ambiguity: someone using a throwaway or generated address usually never confirms it.

What not to do

• Don't block every free-provider signup (Gmail, Outlook) — that's most of your legitimate user base, not your fraud
• Don't treat "review" the same as "block" — you'll reject real customers along with the fraud
• Don't run only a fast-mode check for a high-value action (a paid plan, not a free trial) — the confidence value tells you when a check was too shallow to lean on
• Don't check once and never again — if you allow account creation before email confirmation completes, the risk state at signup and at confirmation can differ if you re-check

What this looks like in code

const result = await fetch("https://api.emailriskradar.com/v1/email/check", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.EMAIL_RISK_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ email, mode: "standard", context: "signup" }),
}).then((r) => r.json());

if (result.decision === "block") {
  return reject("This email address can't be used to sign up.");
}

const account = await createAccount({ email, needsConfirmation: result.decision === "review" });

if (result.decision === "review") {
  await sendConfirmationEmail(account);
  // Grant full trial access only after confirmation completes
}

At higher signup volume

If you're processing a backlog of existing accounts rather than checking at signup time, the bulk endpoint accepts a batch of addresses and processes them asynchronously, with results available by polling a job status endpoint or delivered to a webhook when the batch completes — useful for retroactively scoring an existing user base rather than only new signups.