IPv4 and IPv6 in IP APIs

Handling IPv4 and IPv6 in IP APIs depends on the contract between a client and an API. A client should distinguish success, validation errors, authentication failures, rate limits and temporary server errors. JSON versus XML does not change HTTP semantics, and IPv4/IPv6 values must be preserved without IPv4-length assumptions.

How to handle the response

Validate Content-Type, status code, documented fields and quota. Handle HTTP 429 separately, respect Retry-After when supplied, and use bounded exponential backoff with jitter. Consider idempotency before retrying. Log request identifiers, status and latency, but never API secrets.

The detail that matters

Do not store an IP API field in a schema sized only for dotted IPv4. Preserve canonical IPv6 text or a suitable binary representation, accept compressed forms on input, and test loopback, mapped or dual-stack cases according to the API contract. For a real request and the current API contract, see 2ip API.