How does caller IP lookup work?
Send GET /ip with no address after the route. IPRout identifies the address making the authenticated request, using the request connection and forwarding information accepted from trusted proxy infrastructure, and then resolves that address to the standard GeoIP and ASN response. The absence of a path parameter is intentional: adding /8.8.8.8 changes the operation into an explicit lookup and no longer describes the caller.
When is caller lookup the right choice?
Use caller lookup when your server needs context about the current inbound request and has not already stored a reliable client address. Common examples include suggesting a timezone during signup, selecting a broad regional default, enriching an authentication event, or adding country and network context to an abuse review. It avoids creating a separate browser-side IP discovery step and keeps the API key in trusted server infrastructure.
How do reverse proxies affect the result?
Production traffic often reaches an application through CDNs, load balancers, or reverse proxies. IPRout's caller resolution accounts for trusted forwarding behavior at the API edge so the response is not simply the final proxy connection. Your own application should still configure proxy trust carefully: blindly accepting client-supplied forwarding headers in unrelated systems can allow an attacker to claim an arbitrary address.
What should the application do with the result?
Use the returned country, city, timezone, and network fields as request context, then let the user correct any important default. Do not block an account solely because caller IP location differs from a profile, since travel, VPN use, and carrier routing are normal. For security workflows, combine IP context with authentication history, device signals, user behavior, and explicit verification instead of treating one lookup as a verdict.
How do I request the caller address?
Keep the API key in a server environment or secret manager and send it through the Authorization header. The request ends at /ip. Add a timeout and reject non-success statuses before reading the response as location data. HTTP 401 indicates authentication trouble, while HTTP 429 indicates a key cap or shared monthly allowance has been reached.
curl --fail-with-body --max-time 10 \
-H "Authorization: Bearer $IPROUT_API_KEY" \
https://api.iprout.com/ipHow should caller lookups be operated?
Give the calling service a descriptive key when the plan supports multiple active credentials, monitor its usage separately, and set a suitable Pro cap when isolation is important. Cache only when that matches the freshness and privacy needs of the workflow. Redact the key from logs, avoid logging more IP data than necessary, and document which product decisions consume the location result.
Which IPRout plan fits this workload?
Use the 7-Day Developer Key for a short evaluation with 1,000 requests. Free supports ongoing low-volume use with 10,000 monthly requests and 1 active key. Starter adds 100,000 requests, 2 active keys, and up to 5 exact CORS origins per key. Pro provides 1,000,000 requests, 5 active keys, up to 10 origins per key, and a configurable 100 to 1,000,000 request cap when each key is created. All active account keys consume one shared monthly allowance.
| Plan | Monthly requests | Active keys |
|---|---|---|
| Free | 10,000 | 1 |
| Starter | 100,000 | 2 |
| Pro | 1,000,000 | 5 |
What are the key benefits?
This feature uses the same authenticated HTTPS interface and predictable JSON conventions as the rest of IPRout. That keeps the integration small while letting teams separate product logic from the details of IP intelligence and API key controls.
- Personalize regional defaults
- Add location context to sign-in events
- Avoid client-side IP discovery code
How do I get started?
Generate a 7-Day Developer Key for evaluation or create an account key for an ongoing integration. Begin with the documented request, add status-aware error handling and a finite timeout, then connect only the response fields your product needs. Review usage before launch, keep the secret in trusted infrastructure, and follow the linked documentation for feature-specific configuration.