Cybersecurity, Identity & Fraud
IP Reputation Intelligence API
You already log every client IP. The question is whether that address belongs to a residential broadband customer, a data centre, a commercial proxy pool, or something that has been attacking other people all week.
- Security vendors
- Payment platforms
- Marketplaces
- Trust-and-safety teams
- CDN and WAF providers
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
IP reputation is the cheapest risk signal in existence and the one most often used badly. A single blocklist membership gets treated as proof of malice, so a shared mobile carrier gateway ends up blocking a few hundred thousand legitimate customers. Meanwhile residential proxy networks — which rent out real consumer connections by the hour — pass straight through, because the address genuinely is a home line.
The useful product is not a yes/no list. It is a set of separately-reported attributes: is this a hosting provider, is it a known VPN exit, has it been seen in automated scraping or credential-stuffing traffic, how stable is its assignment, how many distinct accounts in your own system have touched it. Each of those answers a different question and deserves to be kept distinct rather than mashed into one number.
Doing this well is mostly careful data engineering plus restraint. Routing data and network registry records are public. Hosting and proxy classification comes from scanning your own infrastructure's inbound traffic and from published provider ranges. The hard parts are freshness — address assignments move — and resisting the urge to over-claim on signals that are genuinely weak.
Who buys this
Security vendors, Payment platforms, Marketplaces, Trust-and-safety teams, CDN and WAF providers
What the API returns
What comes back
- Network classification: residential, mobile, business, hosting, education, government
- Proxy and VPN indicators split by type, including commercial, residential-proxy and Tor exit
- Automated-traffic indicators observed on consenting participating infrastructure
- Abuse history with first-seen, last-seen and category, not just a binary flag
- ASN, registry allocation, country and whether geolocation is reliable for this block
- Assignment stability: how often this address appears to change subscriber
- A composite risk score with per-signal contributions, never a bare number
- Confidence and freshness per attribute, so weak evidence is visibly weak
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/ip/{address} | Full reputation record for one address |
| POST | /v1/ip/batch | Look up several thousand addresses in one call |
| GET | /v1/asn/{asn} | Network-level profile and aggregate behaviour for an ASN |
| POST | /v1/ip/{address}/feedback | Report a confirmed abuse or confirmed-good outcome |
| GET | /v1/ranges/hosting | Current hosting and cloud provider ranges as a downloadable set |
| WS | /v1/stream | Push newly-classified addresses matching your filters |
Request and response
illustrativeRequest
{
"address": "203.0.113.42",
"include": ["classification", "proxy", "abuse", "stability"],
"context": { "product": "signup", "account_id": "acct_41827" }
}Response
{
"address": "203.0.113.42",
"as_of": "2026-10-21T15:12:04Z",
"classification": {
"type": "hosting",
"asn": 64496,
"asn_name": "Example Cloud Services",
"country": "NL",
"geo_reliable": true
},
"proxy": {
"is_proxy": true,
"kinds": ["commercial_vpn"],
"residential_proxy_suspected": false,
"confidence": 0.88,
"last_confirmed": "2026-10-20T07:41:00Z"
},
"abuse": {
"categories": ["credential_stuffing", "scraping"],
"first_seen": "2026-08-02",
"last_seen": "2026-10-21",
"observation_count": 1842
},
"stability": { "subscriber_changes_30d": 0, "assignment": "static" },
"risk": {
"score": 76,
"band": "elevated",
"contributions": [
{ "signal": "hosting_range", "weight": 0.34 },
{ "signal": "recent_credential_stuffing", "weight": 0.29 },
{ "signal": "commercial_vpn_exit", "weight": 0.21 }
]
},
"freshness": { "classification_age_hours": 6, "abuse_age_hours": 2 }
}Where the data comes from
| Regional internet registry data | Public allocation records giving ASN, block ownership and registration country — authoritative and freely redistributable |
| BGP routing tables | Public route collectors, which show how a block is actually announced rather than how it is registered |
| Published provider ranges | Cloud and hosting providers that publish their own ranges; the cleanest hosting classification source there is |
| Your own inbound traffic | Request logs from your infrastructure, with your agreement — by far the strongest abuse signal, because it is abuse against you |
| Consenting participant telemetry | Aggregated indicators from other customers who opt in; contribution is opt-in and the terms have to say so plainly |
| Licensed geolocation and proxy feeds | Where commercial coverage genuinely beats what can be observed, licensed with redistribution rights checked first |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Separate classifiers per attribute rather than one model producing one score, because hosting detection and abuse prediction are different problems with different evidence
- Hosting and cloud detection from published ranges first, inferred ranges second, with the basis recorded so an inferred classification can be overridden
- Residential-proxy detection from behavioural signatures — concurrent sessions, geographic impossibility, request timing — since the address itself looks ordinary
- Abuse decay functions, so an address that misbehaved in August does not carry the same weight in October
- Carrier-grade NAT and mobile gateway detection, which is where naive blocking does the most collateral damage
- Calibration against your confirmed outcomes, so the score means something in your traffic rather than in general
- Churn monitoring on address assignment; a block changing hands silently is the most common cause of stale false positives
- Latency budget enforced by design: hot records held in memory, cold lookups bounded, no synchronous external calls in the request path
What it changes for the business
Cheap first filter
A sub-millisecond lookup removes a large share of obviously automated traffic before expensive checks run.
Fewer collateral blocks
Separating carrier NAT and mobile gateways from genuine hosting abuse stops mass blocking of real customers.
Signal for other models
Network attributes are among the strongest features in fraud, account-takeover and bot models you already run.
Explainable enforcement
Per-signal contributions let support tell a blocked customer something more useful than “our system flagged you”.
How it fits into your product
How it embeds
- Single-address lookups designed for the synchronous request path, with a documented latency budget
- Batch and bulk-range endpoints for offline log analysis and retrospective review
- Downloadable range sets for environments where an in-process check beats a network call
- Feedback endpoint so your confirmed outcomes recalibrate the score for your traffic
- Deployment inside your infrastructure where request logs cannot leave your network
- Webhooks for addresses that cross a threshold you define, for retrospective account review
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you detect residential proxies reliably?
Partially, and we will not oversell it. The address really is a consumer line, so the address itself tells you almost nothing. Detection relies on behavioural signatures — impossible concurrency, timing patterns, mismatch with the account's history. That catches a meaningful share of commercial residential-proxy traffic and misses some. The API reports it as a suspicion with a confidence value, not a fact.
Is IP reputation enough on its own?
No. On its own it is a weak signal and a dangerous one to enforce against. Shared addresses mean one bad actor can taint thousands of legitimate users. We would build this as one input to a decision, and we would push back on a design that blocks purely on an IP score.
How is the abuse data collected?
From your own infrastructure's logs, from public honeypot and route data, and from other customers who explicitly opt in to contribute aggregated indicators. Nothing is collected by probing third-party networks, and participation in the shared pool is opt-in with the reciprocity written into the contract rather than assumed.
How fresh is the data?
Registry and routing data refreshes hourly. Hosting ranges refresh daily or on provider publication. Abuse observations are near-real-time from participating sources. Every attribute carries its own age in the response, because a six-hour-old classification and a six-week-old one are not interchangeable.
Can we resell the lookups to our own customers?
Depends on the sources in the final build. Registry, routing and your own telemetry are fine. Commercially licensed geolocation or proxy feeds usually are not redistributable without a specific agreement. We establish that during discovery and, if resale is the point, design the service to avoid sources that forbid it.
Related blueprints
Phishing URL Detection API
Risk scores and threat classification for any URL or domain, as a check your email gateway, browser or messaging product can run inline.
Account Takeover Detection API
Detects compromised sessions from login, device, session and in-account behaviour, and returns a step-up decision rather than a bare score.
Domain Security Monitoring API
Continuous passive monitoring of DNS configuration, certificate expiry and externally visible services for domains you are authorised to watch.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.