Understand which HTTP methods are safe and idempotent, and why this matters for retry logic in carrier integrations.
Safe vs Idempotent
A safe method doesn't modify server state (GET, HEAD, OPTIONS). An idempotent method can be called multiple times with the same effect as calling it once (GET, PUT, DELETE). POST is neither safe nor idempotent — calling it twice may create two shipments.
Why Retries Need Idempotency
Network timeouts are common with carrier APIs. If your POST /shipments times out, did it succeed? Without an idempotency key, retrying might create a duplicate. PUT with a client-generated ID is naturally idempotent. For POST endpoints, send an Idempotency-Key header if the carrier supports it.
Carrier Reality
FedEx's REST API supports idempotency keys on shipment creation. UPS does not — you must implement your own deduplication by querying recent shipments before retrying.
Retry Strategy
Use exponential backoff with jitter. Start at 1s, double each retry, add random jitter up to 50% of the delay. Cap at 5 retries. Never retry 4xx errors (except 429). Always retry 502, 503, 504.