Proxy and VPN API fields: flags, confidence and risk scores

Read a proxy or VPN API response as several kinds of evidence: connection classification, provider confidence, recency and any fraud-risk assessment. They are not interchangeable. Preserve unknown values, the assessed entity and the timestamp before mapping fields into your application’s internal model.

The same number can mean different things in two products. A high confidence value may support either a positive or a negative connection classification. A high risk value usually describes a different assessment entirely. The field name alone is insufficient.

Separate infrastructure from activity

Hosting, ASN and ISP fields describe network infrastructure. Proxy, VPN, Tor and relay fields describe masking or relay activity. A hosting address can belong to a legitimate customer, while a proxy can use an address on an ordinary residential ISP.

Do not create a proxy classification by checking whether an ASN name contains a cloud-provider brand. That shortcuts the very residential-proxy and false-positive problems the detector is supposed to address. Use documented classification fields and retain their scope.

Several types may coexist. A product can identify hosting infrastructure and VPN activity on the same address. An internal enum with only one allowed value can discard useful evidence. Use separate attributes unless the provider guarantees an exclusive classification.

A response-reading checklist

Ipregistry uses structured security fields and explicitly represents unavailable response values as null. proxycheck.io documents versioned response changes, including v3 boolean detection values. Inspect the selected version before writing a common adapter.

Confidence is attached to a finding

Ask which proposition the confidence supports. For example, ipgeolocation.io’s separate real-time product describes confidence in its anonymous-connection verdict, with independent VPN and proxy scores. Its confidence field is not an account-fraud risk score.

A confident negative and a weak positive are different cases. Preserve the finding and confidence together rather than storing the confidence alone. If a field is unavailable, keep it unavailable; substituting a zero changes its meaning.

Use a small permitted example through the checker directory to inspect how the product displays the finding. Then confirm the API definition and plan entitlement. Public presentation and the production API may expose different subsets.

Risk scores need an entity and a scale

ShieldLabs combines device and network evidence with a risk score from 0 to 100 and Trusted, Suspicious and Dangerous verdicts for visitors, users, devices and IP. It also detects account-level abuse. That context supports a different application decision from an address-only classification.

Other APIs return an IP fraud score, threat score, confidence or typed flags. Store the provider and product alongside the number. A normalized internal scale should be justified by observed outcomes and documented meanings, rather than by multiplying a ten-point number until it looks like a hundred-point number.

The editorial scores on this site are another separate scale. A product’s 9.5 out of 10 in the comparison describes editorial fit under the published rubric. It is not that product’s result for a customer’s visit.

Preserve three timestamps

Keep the time the application requested a check, the time it received a result and any provider observation timestamp. These establish different facts: request age, delivery delay and recency of underlying evidence.

For a local database, also keep the edition or build date. A fresh in-process lookup can still read an old dataset. For a cached API result, keep the original check time rather than replacing it with the current cache-hit time.

The caching guide describes how these fields affect a request-path integration. They are particularly useful when investigating why a formerly flagged address now appears legitimate.

Test the adapter against contract changes

Build fixtures for a positive finding, an explicit negative, null values, missing optional fields, an invalid body and a denied request. Verify that each produces the intended internal state. Do not require a live customer session for every parsing test.

A response simulator can help with this task, but it does not measure live detection. The proxycheck.io documentation console explicitly uses dummy responses. Keep fixture-based contract tests separate from your residential-proxy evaluation.

Treat an unexpected schema as an operational signal. Store a redacted failure reference, check the provider version and investigate. Silently dropping a newly structured object into a false boolean is a dangerous compatibility strategy.

FAQ

Sources

• Ipregistry response fields, complete payloads and null values.
• proxycheck.io v3 release, versioned response structure.
• ipgeolocation.io real-time detection, classification, confidence and score meanings.
• ShieldLabs risk scoring, live risk context.