A proxy detection integration passes through a trusted ingress and evidence service to an account action
Original illustration for Relay Signal Review. Guide and sources checked October 23, 2026.

Explore checkers, demos and evaluation routes →

Summarize this page with

A reliable proxy detection integration starts before the vendor call. Establish the client address through trusted infrastructure, retrieve the entitled evidence, associate it with the correct visit or account, and define what happens when data is late or unavailable. The API response is one input to an application decision.

  1. 1Trust the ingress
  2. 2Retrieve evidence
  3. 3Bind the action
A practical sequence for the question covered in this guide.

Establish the trusted client address

At a reverse proxy or CDN, only trust forwarding headers inserted by infrastructure you control. MDN documents how X-Forwarded-For can contain a chain and why arbitrary values supplied by the public internet are unsafe for security decisions. Configure the trusted hop count or provider-specific header explicitly.

Record the observed socket address and chosen client address for debugging. For server-to-server requests, decide whether the caller address or an authenticated downstream customer context is the relevant entity. Avoid accepting a client-supplied ip field without validation.

Choose the correct product route

An IP lookup can enrich any address. A browser SDK or session-assessment product requires collection on the current visit. A local database trades network latency for update and licensing operations. A managed traffic product may make or enforce decisions at the edge. Compare these shapes before comparing millisecond claims.

Keep private API credentials on trusted servers. A public site key, when a vendor documents one, is not interchangeable with a secret API token. Validate signed callbacks or webhooks according to vendor documentation and store an idempotency key for repeat delivery.

Associate the result

Attach provider results to a server-side event ID and include visitor, device and authenticated-user identifiers where legitimately available. Record the product version, fields used, response time and missing-state reason. Keep the original response for later review instead of replacing it with a fresh lookup.

Handle failure explicitly

Set separate time budgets for collection, provider lookup and application response. Decide whether a timeout means continue, request verification or defer a high-risk action. Monitor timeout rate, error code, quota exhaustion and missing fields. Test direct-to-origin requests and malformed forwarding headers.

A provider-neutral event envelope

The following is an application-side example, not a request or response schema for any named vendor. Map the provider's documented fields into a record that preserves both the evidence and its origin.

{
  "event_id": "signup-test-0042",
  "client_ip": "203.0.113.42",
  "action": "signup",
  "observed_at": "2026-10-23T10:30:00Z",
  "provider": "selected-provider",
  "product": "selected-product-and-plan",
  "assessment_status": "available",
  "account_reference": "internal-test-account",
  "evidence_reference": "stored-provider-response"
}

203.0.113.42 belongs to documentation address space, defined in RFC 5737. Replace it with the trusted client address in a real integration. Keep provider evidence and the application's eventual action in separate records, so a later review can reconstruct what was known at decision time.

Test failure cases before enabling a restriction

Comparison of the methods and conditions discussed in this section.
Failure What to test Useful behavior
Spoofed forwarding header Client supplies an arbitrary address Trusted ingress configuration selects the actual client address
Invalid API credential Provider rejects the call Authentication error is recorded and surfaced to operations
Quota exhausted Provider returns the documented limit error Assessment remains unavailable; the application uses its explicit fallback
Browser collection absent Script is blocked or event is missing Missing evidence is distinguishable from a clean result
Repeated callback Same event arrives twice One business action is processed through idempotency
Slow response Result arrives after the decision budget Late evidence is logged without duplicating the action

MDN's X-Forwarded-For guidance explains why proxy configuration determines which address can be trusted. This is a prerequisite for an IP lookup, not a detection feature to outsource to the vendor.

For live visitor products, use the documented collection and trusted retrieval flow. Fingerprint's Server API and ShieldLabs documentation describe their respective integrations; neither should be replaced with invented endpoints. If the application only needs local IP enrichment, evaluate database delivery and its update process instead.

FAQ

Can I call a proxy API directly from the browser?

Only when the vendor explicitly supports a protected public-client flow. Secret API credentials belong on the server. Browser collection and trusted result retrieval are separate responsibilities.

What should I cache?

Cache only according to the vendor’s freshness semantics and your decision window. Store the response used for an event. Do not assume a long-lived IP result represents a rotating proxy pool indefinitely.

What happens when the provider is unavailable?

Use an explicit fallback tied to the protected action. Measure unavailable results separately, alert on quota and authentication errors, and avoid silently converting missing evidence into trusted evidence.

Sources

Sources reviewed October 23, 2026.

Continue reading

Compare all ten tools or read the complete deployment guide.