An IP Reputation API That Answers in One GET
GET /v1/lookup/{ip} returns a 0–100 risk score, five network signals — VPN, proxy, Tor, datacenter, anonymity — and the ASN, organization, and cloud provider behind the address. No client snippet, no batch upload, no stale database file to sync.
Why raw IP data isn't a reputation check
A geo lookup tells you nothing about risk
Country, city, and ASN are facts, not judgments. The address that just hit your login endpoint resolves to a Frankfurt ISP — is it a customer on holiday or a VPN exit? A reputation check has to answer that question, not restate the question in JSON.
Downloaded blocklists rot in days
Proxy pools rotate addresses continuously, VPN providers stand up new exits weekly, and yesterday's abusive IP is reassigned to a home broadband customer. A CSV you sync nightly is wrong by morning — in both directions.
Building your own scoring is a second job
Stitching together tunnel intelligence, cloud ranges, Tor exits, and ASN data means juggling licences, refresh schedules, and conflicting formats — then inventing a weighting scheme and defending it. That is a product, not a feature of yours.
Slow enrichment blocks the request path
An IP reputation check usually sits inline: before the login proceeds, before the order confirms, before the webhook is trusted. A lookup that takes half a second turns your fraud control into your latency problem.
What one lookup returns
- A verdict (allow / review / block) plus the 0–100
risk_scorebehind it - Five stable signals per IP:
vpn,proxied,tor,dch(datacenter),anon - Network attribution: ASN, organization, country, city — and the cloud provider when the IP sits in published datacenter space
- Quota monitoring via
GET /v1/usage— free to call, never consumes a request - Answers in under 40ms, with
latency_msreported in every response
One GET, wherever an IP shows up
No client snippet and no browser token — this endpoint is built for the places where all you have is an address: screening a login before the session issues, enriching your own logs, checking a webhook caller, scoring a signup queue. Works for IPv4 and IPv6. Same API key and same hourly bucket as the full /v1/evaluate endpoint.
// Reputation check for a bare IP — server-side, no client code needed const res = await fetch(`https://sntlhq.com/v1/lookup/${ip}`, { headers: { 'Authorization': 'Bearer ' + process.env.SENTINEL_KEY } }); const rep = await res.json(); // rep.risk_score -> 0-100 rep.verdict -> 'allow' | 'review' | 'block' // rep.signals -> { vpn, proxied, tor, dch, anon } // rep.network -> { asn, org, country, city, cloud } if (rep.verdict === 'block') return deny(rep.signals); if (rep.risk_score >= 40) queueForReview(rep);
Watching your quota is one more GET. GET /v1/usage authenticates with the same key, consumes nothing, and is safe to poll from a dashboard or alerting job:
curl https://sntlhq.com/v1/usage -H "Authorization: Bearer sk_live_YOUR_API_KEY"
{
"key_type": "live",
"hourly_limit": 1000,
"used_this_hour": 412,
"remaining": 588,
"resets_at": "2026-07-19T15:04:11.000Z",
"total_evaluations": 52817
}Paste any address into the free IP lookup tool — it runs the same verdict pipeline as the API, no signup required. Or run your own connection through the live scanner on the homepage to see what a full evaluation adds.
How the reputation score is built
An additive score you can explain to an auditor. The risk_score is not a black-box probability: datacenter hosting contributes 40 points, an active VPN or proxy tunnel 60 each, anonymity infrastructure without a named tunnel 30, and a Tor exit floors the score at 90. The default thresholds — review at 40, block at 80 — produce the verdict field, but every input signal ships alongside it, so your policy can diverge from ours without another API call.
Attribution, not just detection. Every hit carries the network behind the address: ASN, organization name, country, and city. When the IP sits inside a cloud provider's own published address space, network.cloud names the provider — useful when you want to treat AWS egress differently from an unknown hosting reseller. Curated tunnel intelligence is the primary source; provider-published ranges and the Tor Project's own exit list only ever add signal on top, and every feed is fail-open.
"No data" is an answer, not a guess. If there is no intelligence on record, the response says known: false with a zero score and null signals — we never fabricate a number for an address we know nothing about. Downstream, that honesty matters: a policy that treats "unknown" as "clean" behaves very differently from one that treats an invented 50 as "suspicious."
Fields that never move under you. The signal spellings (proxied, dch) are parsed by production systems today, so the API stability policy is additive-only: new fields may appear, existing ones are never renamed or removed. Your integration from this page will still parse a year from now. When a browser session is available, /v1/evaluate layers 400+ device signals on the same network intelligence — use the lookup where no client runs, the evaluation where one does.
Common questions
verdict field applies our default thresholds (allow below 40, review from 40, block from 80), but the individual signals ship in every response so you can apply your own policy instead.known is false, risk_score is 0, and signals is null. We don't invent a score for an address we have no intelligence on — an honest "nothing on record" is more useful to your policy than a fabricated number.GET /v1/usage with the same Bearer key. It returns your hourly limit, usage this hour, remaining requests, and the reset time — and the call itself is free: it never consumes quota, so you can poll it from a dashboard or alerting job.Put a reputation check in front of every IP
Free tier: 1,000 requests/hour. No card, no expiry. One GET returns the score, the signals, and the network behind the address.