prevent fake signups

Prevent fake signups and account takeover

Coming soon

One server-to-server call returns a blended IP, email, and browser-reputation verdict plus multi-account correlation for any signup or login.

Start free Read the docs

The problem

The signals that catch a fake account are gone by the time your backend sees it

Your auth provider's user.created webhook carries no IP, user agent, or browser context, so by the time a fake account or a takeover attempt reaches your backend the signals that would have caught it are already gone. Disposable emails, datacenter IPs, and one person spinning up dozens of accounts all look identical at the point you can actually block them.

How it works

Score at the edge, resolve from your backend, decide on the verdict

The beacon scores the visitor before the form is submitted; one secret-key call returns the verdict, session continuity, and multi-account correlation so your server can flag, gate, or block.

Drop the beacon on your auth pages

Add the FormShield beacon to your signup and login views. It sets a first-party _fs cookie and scores the visitor at the edge (IP reputation, email signals, browser fingerprint, automation tells) before the form is ever submitted, so the verdict is ready when your server needs it.

Resolve the visitor from your backend

On signup or login, read the _fs cookie server-side and call POST /v1/sessions/resolve with a secret key. It returns the edge verdict, session continuity (fresh, history-less sessions are themselves a tell), and multi-account correlation, then binds the account id you pass so future lookups stay linked even after the cookie is cleared.

Flag, gate, or block on the verdict

Use the returned decision and the count of accounts sharing a fingerprint or IP to flag a signup for review, step up verification, or reject it. Because the verdict only ever returns to a secret-key backend call, it is never exposed to the browser and cannot be tampered with.

What you get

A blended verdict plus the multi-account tell

One secret-key call returns the fused IP/email/browser decision, the count of identities sharing a fingerprint or IP, session continuity, and a durable identity binding that survives a cleared cookie.

Blended reputation verdict

A single decision (allow, review, block) fused from IP class (datacenter, VPN, proxy, Tor, residential proxy), email reputation, and browser fingerprint, with the reason codes that drove it. The verdict crosses back only on a secret-key call, never to the browser.

Multi-account correlation

Counts of distinct identities that share this visitor's fingerprint, IP, or session. One person registering twenty accounts is invisible per-request but obvious here. This is the core fake-signup tell.

Session continuity

First-seen, last-seen, age, and an is_fresh flag. A brand-new, history-less session arriving straight at your signup form is weak but useful corroborating evidence of automation.

Durable identity binding

Pass external_user_id (e.g. a Clerk or Auth0 user id) and FormShield binds it to the visitor and persists the link in ClickHouse. Correlation survives a cleared cookie because the durable join is fingerprint plus IP, not the cookie alone.

The call

One secret-key call in, a full risk picture out

A signup on a datacenter IP whose fingerprint is shared by seven accounts returns a review verdict with reason codes, session continuity, and the correlation counts behind it — never exposed to the browser.

curl -X POST https://api.formshield.dev/v1/sessions/resolve \
  -H "Authorization: Bearer fs_live_YOUR_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "session_id": "<_fs cookie read server-side>",
    "ip": "203.0.113.42",
    "email": "user@example.com",
    "external_user_id": "user_2abc123",
    "observation_type": "auth.signup"
  }'

{
  "version": "1",
  "data": {
    "bound": true,
    "verdict": { "score": 0.82, "decision": "review", "reasons": ["datacenter_ip", "shared_fingerprint"] },
    "continuity": { "found": true, "first_seen": 1733500000000, "last_seen": 1733500120000, "age_seconds": 120, "observation_count": 3, "is_fresh": false },
    "correlation": { "accounts_sharing_session": 1, "accounts_sharing_fingerprint": 7, "accounts_sharing_ip": 4, "linked_emails": 6 }
  },
  "error": null,
  "metadata": {
    "request_id": "req_a1b2c3d4e5f6",
    "processing_time_ms": 38
  }
}

POST /v1/sessions/resolve is live now. A higher-level POST /v1/auth/check pre-flight that wraps the same signals into a single allow / review / block call is coming soon — join the early-access list to try it.

Get early access See live products

FAQ

Common questions

Add the beacon to your signup page, then call POST /v1/sessions/resolve from your backend (secret key, sessions scope) when an account is created. The response gives you a blended IP/email/browser verdict plus a count of other accounts sharing the same fingerprint or IP, so you can flag, step up, or reject. This endpoint is live now. A higher-level POST /v1/auth/check pre-flight that wraps the same signals into a single allow/review/block call is coming soon.

No. You pass your account id as external_user_id at signup and FormShield keeps the binding and history. To render risk later, call GET /v1/users/{external_user_id} for that identity's current verdict, first/last seen, and multi-account linkage. The customer stores nothing; FormShield owns the identity-risk state.

Credits are weighted per operation: a signup check is 5 credits, a login check is 1 credit, and a raw session resolve is 2 credits. You meter and bill in credits rather than raw request counts, so heavier auth decisions cost proportionally more than a simple login.

Stop fighting spam by hand

One API call. IP, email, content & behavior signals in a single intelligence platform. Start free, no credit card required.

Start Free View Docs