API rate limits and retries

API rate limits and retries are part of 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

When the API returns 429, read Retry-After if present instead of sleeping a fixed interval blindly. Bound the retry count, add jitter to exponential backoff, and avoid automatically replaying operations that can create duplicate side effects. For a real request and the current API contract, see 2ip API.