How does IPv6 lookup differ from IPv4?
The API contract is the same: send a valid IPv6 address through GET /ip/{ip}, authenticate the request, and parse the standard location and network response. An application does not need a separate product, credential, or response model for IPv6. The practical difference is input representation and URL handling, so use a URL builder rather than informal string manipulation when inserting an IPv6 value into the path.
Why should applications support IPv6 now?
Mobile networks, consumer internet providers, cloud platforms, and modern operating systems increasingly use IPv6. Ignoring those addresses can create gaps in analytics, regional defaults, support tooling, and security context. A dual-stack lookup path lets the application enrich whichever public address family it actually receives instead of converting, discarding, or categorizing valid IPv6 traffic as unknown.
Which fields come back for IPv6?
IPv6 responses use the same fields as IPv4: resolved IP, continent and country data, region, city, timezone, UTC offset, coordinates, ASN, organization, currency, and calling code. Availability still depends on the network and underlying intelligence. Code should therefore share a tolerant response type across address families, allowing null geographic fields and future additions without failing the whole request.
What accuracy considerations apply?
IPv6 prefixes can represent networks containing many temporary or privacy-oriented device addresses. The lookup describes the network allocation and approximate routing location rather than one precise device. Corporate tunnels, mobile routing, privacy relays, and cloud infrastructure can affect results just as they do for IPv4. Avoid building logic that assumes a longer address is more individually identifying or geographically exact.
How should IPv6 requests be implemented?
Validate the value as an IP address, encode it as a path segment with a standard URL API, and send the same Bearer header used for other lookups. Test representative compressed and full forms in your own client. Handle HTTP 422 as a permanent input problem and do not retry it unchanged. The 8.8.8.8 request below remains a useful baseline for validating the shared response parser.
curl --fail-with-body --max-time 10 \
-H "Authorization: Bearer $IPROUT_API_KEY" \
https://api.iprout.com/ip/8.8.8.8How do I operate dual-stack lookup?
Keep one metrics view segmented by address family so failures are visible without splitting the implementation. Track latency and validation errors, bound background concurrency, and monitor shared usage. Named keys can separate services, but every key still consumes the account's monthly allowance. Preserve the original normalized address only as long as the product and privacy policy require it.
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.
- One integration for both address families
- Future-ready network enrichment
- Compatible response field model
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.