The two-call model: browser collects, backend decides

The problem with single-call fraud SDKs

Many fraud products ask the browser to talk to a third party and then trust whatever comes back. That is simple — and usually the wrong shape for account protection.

Typical problems:

1. More personal data than necessary leaves your environment early
2. The browser can tamper with a verdict before your backend sees it
3. Your critical signup path depends on a black-box third party
4. Server-side context you already have never informs the decision

The two-call model

AbuseGraph separates the work into two steps:

Call 1 — Browser → AbuseGraph
  Collect limited device and session context
  Return a short-lived, integrity-protected token + preliminary view

Call 2 — Your backend → AbuseGraph
  Attach the identifiers and event context you already hold
  Receive the authoritative score, verdict, and reasons

Call 1: collect in the browser

Your frontend gathers the context needed for a first look — without treating the browser as the source of truth for the final decision.

Call 2: decide on your backend

Your server completes the check with the email, event type, and other context you already process for signup or login. That is where the authoritative result belongs.

Why this is better

What we keep private

We publish the contract: what you send, what you get back, and how to enforce it. We do not publish how tokens are formed, which enrichments run, or how scores are composed. Customers need a trustworthy decision path. Attackers do not need a map.

Trade-offs

The two-call model adds a small amount of coordination between browser and backend. In return you get stronger integrity, cleaner data boundaries, and enforcement that stays in your product.

For account protection, that tradeoff is usually the right one. See how AbuseGraph works end to end, or try the live demo on this visit.

Further reading

• How AbuseGraph works
• Session risk scoring
• API docs
• Live demo