Account takeover protection
Score the login, not just the signup — the attacker arrives later.
What the problem actually is
Credential stuffing uses real credentials from someone else's breach, so the password check passes. What differs is everything around it: the network, the device, and the sheer rate. A login flow that only checks the password has no way to notice.
Signals that carry the weight here
A known-good device on a normal network is the strongest evidence a login is the real owner. A first-seen device on a datacenter IP is the opposite.
Stuffing runs on automation, and automation markers are visible in the browser.
The infrastructure used against you has usually been used against someone else first.
Where to start
strictness=2 (strict) — Strict on login. Step up to a second factor on review rather than locking the account — an owner locked out is a support ticket and a churn risk.
A defensible starting point, not a guarantee. Strictness moves the verdict thresholds only; the risk score itself never changes, so you can re-tune without re-scoring anything.
The call
curl -X POST "https://www.layercall.com/v1/score/user" \
-H "X-Api-Key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"ip":"$IP","email":"$EMAIL","device_id":"$DEVICE_ID","strictness":2}'1,000 lookups a month free, no card. Get an API key.
Questions
Should a high score block the login outright?
Rarely. Blocking punishes the real owner when you are wrong, and you will sometimes be wrong. Step up to a second factor instead: an attacker without the second factor is stopped, and a genuine owner is mildly inconvenienced.