Express courier. Direct.
Also overnight.
x25pronto Switzerland takes goods direct to the destination. Small loads go by car. Larger loads go by van or Van XL. Direct, express and overnight trips run Monday to Sunday when a slot is free. Free times are shown in the booking calendar. This keeps the plan clear.
Idempotency, retries and rate limiting for courier APIs
How to prevent duplicate bookings, apply retry strategies with backoff and handle rate limits in everyday courier API operations.
Quick answer
In short: prevent duplicate bookings with idempotency keys, use staged retry strategies with exponential backoff and handle rate‑limit responses (HTTP 429). This keeps bookings consistent and your operations in Zurich, Basel or Geneva stable.
Why idempotency matters
Repeated requests to a courier booking endpoint can cause duplicate shipments. Duplication wastes time and creates chaos for dispatch in Zurich or drivers on the road. Idempotency ensures that repeated requests with the same intent do not create multiple operations. Critical actions remain safe and predictable.
Idempotency key best practices
Generate a unique idempotency key for every user intent. Use a client‑side UUID v4 or similar. Store the key with the booking reference in your system. Treat the same key as the same operation for a fixed window (for example, 24 hours). Verify how long the courier API keeps idempotency history in its docs.
Retries: when and how often
Retries are useful for transient errors: network timeouts, brief outages or connectivity blips. Do not retry on client errors (HTTP 4xx except 429). Limit automatic retries to a safe number (for example 3–5). Only retry idempotent endpoints or use idempotency keys. Log all attempts for later review.
Backoff strategies: exponential with jitter
Exponential backoff increases wait time between attempts (1s, 2s, 4s). Add jitter (random variance) to avoid synchronized retries from many clients. Example: base=500ms, multiplier=2, jitter=random(−250..+250)ms. This reduces spikes on the courier API and lowers the chance of repeated 429 responses.
Handling rate limits in operations
APIs often expose rate info in headers (e.g. X-RateLimit-Remaining, Retry-After). Respect 429 responses with a calm backoff and place the request into a retry queue. Build a central request queue in your system to smooth spikes and allow priority handling (urgent vs standard).
Monitoring, alerts and fallbacks
Track error rates, latencies and rejected requests. Set alerts for sustained rises in 5xx or 429. Define fallbacks: retry later automatically, notify manual dispatch or show a user message that the booking is under review. Keep transaction logs to investigate any inconsistencies fast.
Frequently asked questions
What is an idempotency key and who creates it?
An idempotency key is a unique identifier for a specific action. The client (your ERP or booking frontend) usually creates it and sends it to the courier API. This tells the provider to treat repeated requests as identical.
How should I handle an HTTP 429 (Too Many Requests)?
Read the Retry‑After header, start a backoff, increase wait time on repeated 429s, and enqueue the request. Notify stakeholders if delays are business‑critical.
Can I retry any endpoint safely?
No. Only retry idempotent endpoints or those protected by an idempotency key. Avoid automatic retries on non‑idempotent actions without safeguards.
How long should idempotency keys be stored?
Common windows are 24–72 hours, depending on cancellation policies and audit needs. Choose a retention that fits your operational requirements.