How do I look up 8.8.8.8?
Pass the address as the final path segment and authenticate the request.
curl -H "Authorization: Bearer YOUR_API_KEY" https://api.iprout.com/ip/8.8.8.8Does this endpoint use my caller IP?
No. Once an address is present in the path, IPRout resolves that explicit address only.
How should invalid input be handled?
Validate obvious formatting errors before calling the API and handle HTTP 422 for addresses the endpoint cannot accept.
- Encode IPv6 addresses correctly in the URL path
- Do not retry a permanent 422 error
- Log validation failures without logging API keys
How should explicit IP lookup be implemented?
Validate one IPv4 or IPv6 value, append it as the final /ip path segment, and keep the original input separate from the normalized value. Never accept hostnames, CIDR ranges, or multiple addresses in this route. Keep this responsibility close to the IPRout client so the behavior documented in Look Up a Specific IP Address remains consistent across web requests, workers, and scheduled jobs.
How should explicit IP lookup be verified?
Use 8.8.8.8 as the documented deterministic fixture, then cover valid compressed IPv6 and malformed input. Confirm that invalid addresses return 422 and never fall back to resolving the caller. Automate the stable cases and reserve live checks for controlled environments so verification is repeatable without consuming unnecessary production allowance.
How should explicit IP lookup be operated?
Track validation failures separately from upstream availability. A burst of 422 responses indicates an application input problem, while transport errors and 500 responses point to a different operational boundary. Write down the owner and expected behavior so an alert or product change can be handled without reconstructing the original integration decisions.
Where does explicit IP lookup stop?
The endpoint answers for the supplied network address only. It does not perform DNS resolution, subnet analysis, batch enrichment, device positioning, or confirmation that a user owns the address. Treat that limit as part of the feature contract and direct callers to the related guide when they need a different guarantee or control.
What belongs in the release review for explicit IP lookup?
Review the deployed implementation of Look Up a Specific IP Address, not only a local sample. Confirm the intended endpoint, credential source, timeout, response model, and fallback from the environment that will carry real traffic. Use the verification cases above as release evidence, inspect generated browser assets and logs for secret exposure, and make sure dashboards identify the workload without storing raw credentials or unnecessary IP data. Record the configuration owner and rollback action before enabling the feature broadly.
When should explicit IP lookup be revisited?
Revisit explicit IP lookup when traffic volume, plan capacity, application ownership, deployment regions, browser origins, data retention, or the product consequence of a lookup changes. Compare the current implementation with the documented operating boundary rather than assuming the original decision still fits. Update tests and internal runbooks together, then verify the public API contract and related IPRout guides before rolling the change across every service that shares the client or account.
External references
Continue with the standards and official documentation most relevant to this guide.