VPN Detection API for SaaS: A 2026 Implementation Guide

Here is the mistake most teams make the first time they add IP intelligence to a signup form: they detect VPN traffic, see that a chunk of it correlates with abuse, and start blocking every VPN signup. Two weeks later, support tickets pile up from real customers on Mullvad, corporate laptops behind a company VPN, and iPhone users with iCloud Private Relay turned on.

A VPN signup is not fraud. It is a weak signal that becomes strong only in combination. This guide is about adding a VPN detection API the right way — what it returns, the distinctions that actually matter, and how to score it without torching legitimate users. It is the API-integration companion to the conceptual VPN and proxy detection guide; if you want the proxy-specific build, see proxy detection for SaaS.

What a VPN detection API returns

Give it an IP, get back a small object of network signals:

• is_vpn — commercial VPN service (NordVPN, Mullvad, Proton VPN, …). Common and often benign.
• is_proxy — anonymizing or residential-proxy relay. More strongly tied to automated abuse.
• is_tor — the connection exited the Tor network. Rare, and high-risk for most SaaS.
• is_datacenter — the IP belongs to AWS, GCP, Hetzner, DigitalOcean, and similar. A real person almost never browses from a server, so this is a strong red flag for consumer signups.
• country, asn, asn_org — geolocation and the owning network, for consistency checks.
• risk_score — a 0–100 roll-up of the above.

The reason these are separate flags instead of one "anonymous IP" boolean is that they carry very different weights. Tor and datacenter are loud; VPN is a whisper.

VPN vs proxy vs datacenter vs Tor

The four get lumped together and they should not be:

A developer-tools product will see more legitimate datacenter traffic than a consumer app; a fintech will weight Tor harder than a blog. The weights are yours to tune — but the four signals need to arrive separately for you to tune them at all.

The one call

Capture the client IP server-side and pass it with the email:

const resp = await fetch("https://api.vouchley.getrevlio.com/v1/verify", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.VOUCHLEY_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ email, ip_address: clientIp }),
});

const { score, recommendation, ip } = await resp.json();

// Strong negatives: stack them, don't gate on one
const highRiskIp = ip.is_tor || ip.is_datacenter;

if (recommendation === "block" || (highRiskIp && ip.risk_score > 80)) {
  return reject();
}
if (recommendation === "review" || ip.is_vpn || ip.is_proxy) {
  return createLimitedAccount({ email }); // verify + gate expensive features
}
return createAccount({ email, trustScore: score });

Getting the real client IP matters more than the API call. Behind a load balancer or CDN, read the leftmost trusted hop of X-Forwarded-For — not the socket address, which is your proxy, and not the rightmost value, which a client can spoof.

Score, don't block

The single rule that keeps you out of trouble: no individual IP flag should reject a signup by itself.

The actual fraud fingerprint is a combination — a datacenter or flagged IP plus a brand-new email domain plus a geolocation that disagrees with the declared country plus an account that immediately reaches for an expensive feature. Any one of those is noise; together they are signal. That is why VPN detection belongs in a combined score, not a firewall rule.

For the gray zone — VPN or proxy but nothing else damning — the right move is async enforcement: create the account in a limited state, then lift the limits once the user verifies their email and behaves like a human for a day or two.

Build vs buy

You can build the cheap half: block Tor exit lists and datacenter ASNs from public data. What is hard to run in-house is fresh commercial-VPN range mapping and IP reputation — both change hourly, and stale data means both false positives (blocking a moved-on IP) and false negatives (missing a new VPN range). Most teams build the datacenter/Tor lists and buy the parts that need constant freshness. If you are comparing vendors, the IPQualityScore alternatives roundup and the Vouchley vs IPQualityScore page lay out the trade-offs.

The honest gap: residential proxies

VPN and datacenter ranges are well-mapped. Residential proxies — real home IPs rented out by the gigabyte — are designed to look exactly like legitimate consumer traffic, and no IP-only signal reliably catches them. This is the documented limit of IP intelligence, and it is why the combined score leans on email, domain-age, and behavioral signals too rather than IP alone.

Wire it in

• Full response shape: the /v1/verify docs show every ip field.
• Why VPN/proxy matters at signup: the conceptual guide.
• Proxy-specific build: proxy detection for SaaS.

Add the one call, read the four IP flags, and score instead of block. You get the fraud-fighting value of VPN detection without the support tickets that come from treating every privacy-conscious user like an attacker.

Start free with 100 Vouchley credits → — IP, email, and domain signals in one call.