These two get compared as alternatives, and they are not. They sit at different layers, and the honest version of this comparison starts with a disclosure: Sentinel's network intelligence is Spur-powered. The vpn, proxied, and tor signals in a Sentinel verdict originate from Spur's Context API. We say so on our homepage and in our API documentation, and it would be strange to write a comparison that pretended otherwise.

So the question is not which is better. It is how much of the detection pipeline you want to build yourself.

What Spur sells

Spur is a network intelligence company. Its Context API answers a hard question with unusual accuracy: is this connection, right now, traversing a VPN, a proxy, or an anonymization network — and which one. That is genuinely difficult work involving continuous measurement of tunnel infrastructure, and very few organisations do it well.

Spur also publishes Monocle, a client-side component that validates a session from the browser rather than inferring everything from the address alone.

What Spur deliberately does not do is decide anything for you. It returns context. What that context means for your signup form, your checkout, or your promotion redemption is left to you — which is the right design for a data provider, and the reason it is trusted by teams who want to build their own logic.

What Sentinel sells

Sentinel is a decision layer. It consumes network intelligence — Spur's, plus provider-published cloud ranges and the Tor Project's exit list — and adds the parts that live above the network:

  • Device intelligence. A stable visitor identifier that survives cookie clears and incognito, plus a browser-tampering score that catches antidetect browsers. This is a different layer from the network entirely, and it is what catches an operator whose IP is genuinely clean.
  • Per-customer account linking. Correlating which accounts share a device environment, hash-only and strictly within one customer's own data. This is what defeats rotation: forty accounts across forty residential exits trace back to one machine.
  • A verdict, not a dataset. A 0–100 risk score and an allow/review/block decision, with every contributing signal returned separately so your own rules can override it.
  • The operational surface. A rules engine, webhooks, an events log, a dashboard, and SDKs — the plumbing you would otherwise build around a data feed.

The layering, concretely

A Sentinel verdict on a single address is assembled roughly like this. Spur is asked what the connection is doing. Provider-published cloud ranges add the dch signal when the address sits in a hosting provider's own advertised space, worth 40 points toward the 0–100 score. A VPN or proxy tunnel contributes 60. A Tor exit floors the score at 90. Review starts at 40, block at 80.

Critically, a cloud-range match never short-circuits tunnel detection, because VPN exits are themselves hosted in datacenters — so skipping the tunnel checks on a range hit would miss exactly the cases that matter. That ordering is an architectural decision recorded in our ADRs, and it exists because the primary source has to stay primary.

Then device signals and per-customer history are layered on top, and the result is a decision rather than a description.

When to use Spur directly

Go straight to the source if any of these describe you.

  • You have engineers who want raw context and intend to build the decisioning themselves. Paying an intermediary for logic you plan to write anyway is a bad trade.
  • Your problem is genuinely network-shaped — you need to know what a connection is doing and nothing else. Device identity and account correlation would be dead weight.
  • You are integrating into an existing risk platform that already has rules, case management, and storage, and needs one more high-quality feed.
  • You want to control exactly how signals are weighted, with no vendor opinion baked in.

When a decision layer makes more sense

  • The abuse you are fighting is not primarily a network problem. Multi-accounting, bonus abuse, and trial farming are committed by real humans on real connections; the network looks fine and the correlation is what exposes them.
  • You need device-level identity as well as network context, and would rather not run a second vendor and reconcile two sets of signals.
  • You want a verdict at a specific action — signup, login, checkout — with rules, webhooks, and an events log around it, and you do not want to build that.
  • You want to start in monitor mode and tighten gradually, using someone else's scoring as a baseline before writing your own rules.

The honest summary

If you only need network context and have the engineering to act on it, use Spur directly. You will get the same underlying intelligence without a layer in between, and that is a perfectly good outcome — it is what the Context API is for.

If you want that intelligence combined with device identity and account correlation, delivered as a decision with the operational surface already built, that is the gap Sentinel fills. The network signals will still be Spur's underneath, and we would rather tell you that plainly than have you discover it later.

Either way, evaluate on your own traffic. The single most useful test is a residential address that looks clean by every reputation measure — see whether the tool tells you anything at all about it, and whether what it tells you is actionable.

FAQ

Frequently Asked Questions

Does Sentinel use Spur?

Yes. Spur's Context API is the primary source for Sentinel's network intelligence, and the vpn, proxied, and tor signals in a Sentinel verdict originate from it. This is stated on the Sentinel homepage and in the API documentation. Provider-published cloud ranges and the Tor Project's published exit list add further signals, but they are only ever allowed to add context — never to override or short-circuit the primary source.

Is Sentinel just a wrapper around Spur?

No, though it would be fair to call the network layer exactly that. What Sentinel adds sits above the network: device fingerprinting with a stable visitor identifier and a browser-tampering score, per-customer device-to-account linking that survives IP rotation, a rules engine, webhooks, an events log, and a single allow/review/block verdict. If your problem is purely network-shaped, that additional layer is weight you do not need and going direct to Spur is the better call.

Should I use Spur or Sentinel?

Use Spur directly if you want raw network context and have engineers who will build the decisioning, or if you are feeding an existing risk platform that already has rules and case management. Use a decision layer like Sentinel if the abuse you face is not primarily network-shaped — multi-accounting, bonus abuse, and trial farming are committed by real people on clean connections, where device correlation rather than IP reputation is what exposes them.

Why would a vendor disclose its own data supplier?

Because the alternative is worse. Any engineer evaluating both products carefully would work it out, and a comparison that implied superiority over an upstream supplier would fail the moment they did. Stating the architecture plainly also makes the actual value proposition legible: the network layer is bought, the device layer, the account correlation, and the decisioning are built.

Go deeper

See the whole stack on your own traffic

Network, device, and account signals in one server-side verdict.

Try Sentinel free →