Prynt vs Cloudflare Bot Management: Bot Scores vs Account-Level Abuse

Cloudflare Bot Management and Prynt both get called “bot detection,” and both can make an allow, challenge or block call before your app does real work. That’s where the similarity ends. One scores requests as they cross the network edge. The other identifies the device behind them and remembers what it did with your accounts.

If you’ve already read our comparison with Turnstile, this is a different product and a different question. Turnstile is a challenge widget. Bot Management is Cloudflare’s per-request bot scoring at the edge. The useful question isn’t which one wins; it’s which problems each can see.

What a per-request bot score is good at

Bot Management sits in front of your origin and assigns each request a score for how likely it is to come from automation, using what Cloudflare sees across its network: TLS and HTTP fingerprints, request patterns, IP behavior and its own models. You write firewall rules on the score, and bad traffic never reaches your servers.

That’s the right tool for:

• Volumetric scraping and credential stuffing, where you want to drop traffic before it costs you compute.
• Inventory and checkout bots hammering an endpoint during a drop.
• Known automation clients whose network fingerprint gives them away on the first request.

It’s fast, it’s at the edge, and it needs no code in your app. If you’re on Cloudflare and dealing with high-volume automation, it’s a strong layer.

What a per-request score doesn’t carry

A bot score is a judgment about one request. It doesn’t know which of your accounts that request belongs to, or how many others the same device has opened. That’s by design: Cloudflare sees traffic, not your user table.

Plenty of costly abuse is done by humans, or by automation good enough to pass as a browser, and it only shows up at the account level:

• Free-trial farming. One person, one laptop, a new email each week. Every request looks human because it is.
• Multi-accounting for bonuses or referrals. The same phone creating account after account, each one clean in isolation.
• Ban evasion. A suspended user returning from the same browser with a fresh account.
• Low-and-slow fraud spread across residential proxies, where no single request is suspicious.

To catch those, you need a stable device identity tied to your accounts. Prynt’s visitorId survives cleared cookies and private windows, and on the server accountsOnDevice lists every account you’ve linked to that device. The multiAccount signal flags two or more accounts on one device in 30 days; accountSharing flags more than three in a day. Residential proxy bots covers the network side of the same problem.

Side by side

	Cloudflare Bot Management	Prynt
Where it runs	Cloudflare’s edge, every request	Browser or mobile agent + your server (optionally an edge Worker)
Core output	Bot score per request	visitorId, Smart Signals, decision with reason codes
Knows your accounts	No	Yes, via linkedId
Repeat-device detection	Not its job	accountsOnDevice, multiAccount, accountSharing
Explanation	Score and detection fields	Reason codes such as MULTI_ACCOUNT, RESIDENTIAL_PROXY, TLS_AUTOMATION
Requires Cloudflare	Yes	No
Pricing	Ask Cloudflare	Flat plans from $0; Pro $29/mo, Scale $99/mo

Prynt also does bot detection: headless and automation frameworks, AI agents, JA4 TLS fingerprints, tampering. So there’s overlap at the request level. The difference is what each is anchored to: Cloudflare to the request on its network, Prynt to the device and your accounts.

Running both from a Worker

If you’re on Cloudflare, you don’t have to choose. A Worker can let Cloudflare filter the obvious automation and then ask Prynt about the device on the routes that matter: signup, login, checkout, promo redemption.

The page identifies with Prynt and sends the requestId in a header. The Worker fetches the authoritative decision with your secret key:

export default {
  async fetch(request, env) {
    const requestId = request.headers.get('X-Prynt-Request-Id');
    if (!requestId) return fetch(request);

    let decision = 'allow';
    try {
      const res = await fetch(`${env.PRYNT_ENDPOINT}/v1/events/${requestId}`, {
        headers: { Authorization: `Bearer ${env.PRYNT_SECRET_KEY}` },
      });
      if (res.ok) decision = (await res.json()).decision || 'allow';
    } catch (_) { /* fail open */ }

    if (decision === 'block') return new Response('Forbidden', { status: 403 });
    return fetch(request);
  },
};

This follows the Cloudflare Worker recipe in the Prynt repo. It fails open, so a Prynt outage never takes your site down. The decision it reads was made when the page identified; fetching the event doesn’t recompute it.

There’s also a fuller edge package that serves the agent first-party through your own domain, so ad and tracker blockers don’t strip it. It gates requests through GET /v1/edge/gate, forwarding the visitor’s real IP and the JA4 fingerprint from Cloudflare’s bot management fields when they’re present, so that gate decision does include the network-layer signal. It passes X-Prynt-Decision to your origin for allow and challenge.

Two rules keep this sane:

• Let Cloudflare drop volume; let Prynt make account decisions. Don’t call Prynt on every static asset. Call it on the handful of routes where an account is created or money moves.
• Re-check at the origin before you write anything. The Worker is an early filter. Your signup handler should still fetch the event and check accountsOnDevice before creating the account, because the edge doesn’t know your limit or your user table.

Which do you need?

If your pain is high-volume automated traffic and you’re already on Cloudflare, start with Bot Management. If your pain is people, or polished automation, creating and reusing accounts, a per-request score won’t see it, and device identity will. Many teams end up with both: an edge score for volume, a device check where accounts are made.

See edge bot detection on Cloudflare for the Worker setup in depth, the bot detection page for what Prynt flags at the request level, and pricing for the plans. Deploy the Worker in front of signup only, watch the decisions for a week, then widen it.