Prynt vs IPQualityScore: IP Reputation vs Device Identity

IPQualityScore (IPQS) and Prynt both appear in searches for “fraud score API,” and both return a verdict you can act on. They start from different evidence, though, and that difference decides which one helps with your problem.

IPQS is known for reputation lookups: send an IP address, email or phone number, and get back a judgment about that identifier, such as whether the IP is a proxy, whether the email is disposable, or whether the number is a VoIP line. Prynt starts from the device: recognize the browser or phone in front of you, keep recognizing it when everything else changes, and tell you what it has done before.

Two kinds of question

“Is this identifier risky right now?” That’s a reputation question. It’s useful at a single checkpoint, like a checkout, a login from a new IP, or a lead form, when you want a fast read on the network or contact details in front of you. Reputation lookups are good at it, and they need nothing more than the identifier.

“Is this the same person as before?” That’s an identity question. A trial farmer on a residential proxy with a fresh Gmail address can pass every reputation check: the IP belongs to a real home ISP, and the email is real and deliverable. What gives them away is that the fifth account arrives from the same laptop as the first four. Reputation of the identifier can’t see that, because the identifier is new every time.

Most fraud programs need both questions answered. The mistake is expecting one tool to answer the other’s question.

How IPQualityScore approaches it

IPQS describes a suite of lookup APIs covering proxy and VPN detection, email validation, phone validation, URL scanning and device fingerprinting, each returning a fraud score and supporting fields. Its strength is breadth of reputation data about identifiers. You can call it from a backend with nothing but the value the user typed, or the IP they connected from.

That makes it a natural fit for one-off risk checks: scoring a lead before sales calls it, screening a payment’s IP and email, or filtering form spam. For the details of each product, and for pricing, check IPQS’s own documentation. We won’t characterize their pricing or limits here.

How Prynt approaches it

Prynt is device identity first. The agent produces a visitorId that survives cleared cookies, incognito and IP changes. Your server fetches the event with a secret key and gets the device’s history alongside its network context:

const ev = await prynt.getEvent(requestId);

ev.visitorId                 // same device, new IP and new email
ev.accountsOnDevice.count    // your accounts already linked to this device
ev.smartSignals.residentialProxy.result
ev.smartSignals.vpn.result
ev.decision                  // 'allow' | 'challenge' | 'block'

Because the identifier persists, signals accumulate. Prynt tracks velocity, multiAccount (2+ accounts on a device in 30 days), deviceSpread (one account on many devices) and impossibleTravel across a device’s and an account’s history, and emits reason codes like MULTI_ACCOUNT, RESIDENTIAL_PROXY and IP_REPUTATION with each decision.

Prynt also covers the identifier side in a narrower form. Network signals (VPN, Tor, datacenter, proxy, residential proxy, IP reputation) arrive with every identification, and POST /v1/enrich scores an email, phone or IP with your secret key when there’s no browser in the loop:

curl -X POST https://api.pryntid.com/v1/enrich \
  -H "Authorization: Bearer sk_live_…" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","ip":"203.0.113.7"}'

Which signals matter for which problem

Problem	Signals that decide it	Better starting point
One person, many trial accounts	Same device across accounts, account history	Device identity
Banned user coming back	Device seen on a banned account	Device identity
Lead or form spam from scripts	Bot, form automation, disposable email	Either; both cover it
Checkout from an anonymizing network	VPN, proxy, datacenter, IP reputation	Either
Fabricated email or phone, no device context	Email and phone reputation depth	Reputation lookup
Fraud ring spread across many devices	Shared devices and accounts between clusters	Device identity plus a graph

The pattern: when the abuser can rotate the identifier cheaply (IPs through proxies, emails through aliases), reputation weakens, because every rotation brings a fresh, clean value. Why IP blocklists fail covers this for IPs. A device is much more expensive to rotate, which is why identity holds up where reputation thins out.

Residential proxies: where it shows most

Residential proxies are the clearest example. Traffic exits through real home connections, so a reputation lookup on a single IP often comes back clean. That’s not a flaw in the lookup. The IP really does belong to a consumer ISP. Prynt approaches it from two sides: a residentialProxy signal with its own reason code, and the device ID, which stays constant while the exit IP changes on every request. Even when the proxy goes undetected, the fifth account from one device is still the fifth account. IP reputation explained covers what reputation can and can’t tell you.

Pricing and deployment

Reputation APIs are commonly priced by lookup volume. Check IPQS’s site for their current model. Prynt’s plans are flat: Free with 20,000 identifications a month, Pro at $29/month, Scale at $99/month, with a soft cap instead of overage billing, as listed on the pricing page. Prynt can also be self-hosted from its open-source core.

When each fits

IPQualityScore fits when your main need is scoring identifiers at a checkpoint without a browser agent, especially deep email and phone validation.

Prynt fits when the abuse is repeat behavior from the same people: multi-accounting, trial farming, ban evasion, promo abuse. In those cases the identifier changes every time and the device doesn’t. Its built-in network signals cover most of the reputation checks a signup flow needs.

The two can also run together, a reputation lookup on the email plus a device check on the browser, if your fraud spans both. To see how the device side behaves when you switch networks, open the playground, toggle a VPN, and watch the visitorId stay put. The best FingerprintJS alternatives has a broader look at the identity side.