Developer tools & APIs
Free API tiers get farmed. Protect the tier without making your best users prove themselves.
What the problem actually is
Any generous free tier is eventually treated as free infrastructure. Users script signups to mint keys in bulk, run them from cloud instances, and resell or aggregate the quota. The awkward part is that your genuine power users also come from cloud IPs and also use VPNs, so the naive defence — block datacenter traffic — blocks precisely the developers you want.
Signals that carry the weight here
A developer evaluating your API for work uses a work address. A throwaway suggests the key is the product, not the evaluation.
Distinguishes one developer with several test accounts, which is fine, from one script minting hundreds, which is not.
The shape of farming is many signups sharing infrastructure in a short window — a pattern invisible in any single request.
Where to start
strictness=0 (lenient) — Lenient, deliberately. Your audience lives behind VPNs and cloud IPs; act on disposable email and velocity, and leave network signals as context rather than grounds for refusal.
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":0}'1,000 lookups a month free, no card. Get an API key.
Questions
Why lenient for developer products specifically?
Because the signals that look suspicious elsewhere are normal here. A developer on a corporate VPN, testing from an EC2 box, with a plus-addressed email is a completely ordinary customer. Applying e-commerce thresholds to this audience produces false positives against exactly the users most likely to pay.