PROXYRADAR DEVELOPER GUIDES
How to Choose a Proxy & VPN Detection API
Choose a proxy detection API by checking what its results mean, how it handles IPv4 and IPv6, what happens when a lookup fails, and how its query allowance fits your traffic. An easy endpoint matters, but a clear response contract matters more.
1. Define the result your application needs
Start with the action you intend to take. Do you need an overall proxy flag, a separate Tor category, or a way to distinguish hosting traffic from VPN traffic? Providers can use the word “proxy” differently. If you treat every positive as evidence of a VPN, a broad flag that includes hosting may produce the wrong application behavior.
| Question to ask | Why it matters | ProxyRadar’s response |
|---|---|---|
| Does the overall flag include hosting? | Legitimate servers can use hosting networks. | Yes. Read the available category flags for more context. |
| Can categories overlap? | An address can be both a hosting address and a Tor exit. | Yes. Multiple flags can be true. |
| Can the overall result be positive without a category? | A missing category must not erase a positive result. | Yes. The overall result is separate from the category flags. |
| Are unknown results explicit? | An outage must not be interpreted as a clean connection. | Failed lookups return an error HTTP status. |
| Is it a behavioral fraud score? | Network type and malicious intent are different questions. | No. ProxyRadar provides IP network classification. |
2. Test on traffic that resembles your own
Build a small evaluation set with both positive and negative examples. Include IPv4, IPv6, hosting addresses, legitimate business connections and any proxy types relevant to your application. Record the query time because an address’s network use can change.
If you compare two services, count results in a four-cell table: both positive, both negative, only the first positive and only the second positive. Keep errors in a separate group. Do not count timeouts as negative answers or treat agreement between providers as proof of accuracy.
Repeated addresses need care. Reporting both unique IP counts and traffic-weighted counts shows whether one frequently queried address dominates the result. Review disagreements against evidence from your own controlled connections where possible. A provider’s marketing claim is not a substitute for a test that matches your use case.
3. Check the integration before automating decisions
- Authentication: keep the API key on your server and prefer a request header over a URL parameter.
- Response validation: check the HTTP status, success field and expected data types before using a verdict.
- Timeouts: set a deadline that fits your application. Return an unknown state when the deadline is reached.
- Retries: respect
Retry-After, use a bounded retry policy and avoid retrying invalid input or an invalid key. - Address handling: verify both IPv4 and IPv6. Make sure your integration passes the intended public client address.
- Logging: record enough context to investigate decisions without storing API keys in URLs or error logs.
For ProxyRadar, use GET /v1/check with an Authorization bearer header and format=json. The API documentation defines the supported fields and error responses. The code guide shows the same integration in three languages.
4. Match the allowance to your request pattern
A daily allowance and a monthly allowance are not interchangeable. A daily limit can be exhausted by a single busy day even if your monthly average is low. Estimate successful lookups at the point where you plan to call the API, and include retries that may succeed after a client-side timeout.
ProxyRadar’s free account includes 1,000 successful queries per day. Paid plans increase the daily allowance and renew monthly. Each successful lookup counts once; failed classifications do not consume the account’s query allowance. Daily quotas reset at 00:00 UTC, and the API also has a burst limit. Review the current plans and the limits reference before deployment.
Keep the first rollout reversible
Run the new classification alongside your existing policy before it starts denying requests. Review positive results, errors and customer reports. Then enable rules for a clearly defined action and keep an alternative path for legitimate users. This makes the rollout easier to assess than changing every access rule at once.
Put the guide into practice.
Check an IP in your browser or start with 1,000 free API queries per day.