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.
Implementing idempotency and retries in shipping integrations
Use idempotency keys, controlled retry backoff and a Dead‑Letter Queue to avoid duplicate bookings, keep visibility and handle failed shipments reliably.
Quick answer
Generate an idempotency key per business-unique shipment, combine controlled retries with exponential backoff and route failed attempts to a Dead‑Letter Queue. This avoids duplicate orders and keeps shipment state clear for Swiss operations in Zurich, Geneva or Basel.
Why idempotency matters for shipping
Shipping integrations link your order system to carrier APIs and internal workflows. Timeouts, retries or user actions can cause duplicate sends. Idempotency prevents duplicated bookings. For Swiss companies this reduces customer calls, returns and unclear costs.
Core idea: a unique idempotency key
Each unique shipment action needs an idempotency key. Make it business‑unique, for example: orderID + packageIndex + checksum of critical fields. Send that key when creating a carrier order and persist it locally with the order state. Repeated requests with the same key should be treated as identical by the provider.
Key design rules
1) Keep the key constant for the same business action. 2) Do not change the key after send. 3) Retain keys at least as long as cancellation windows. 4) Use clear states: pending, confirmed, failed.
Retries: backoff strategies and limits
Classify errors: transient (network, 5xx) vs permanent (4xx, validation). For transient errors use exponential backoff with jitter. Example: start 500 ms, double until 30 s, add random jitter. Put a hard limit on attempts (e.g. 5). Log each attempt for auditing.
Dead‑letter handling and monitoring
When retries are exhausted or an error is permanent, move the order to a Dead‑Letter Queue (DLQ). Store idempotency key, payload, error code, timestamps and retry metadata. Alert on new DLQ entries and review them daily. Define escalation for critical shipments.
Integration steps — practical flow
1) Generate idempotency key before API call. 2) Persist key + payload + status "pending" locally. 3) Send request with key. 4) On success: set status "confirmed" and store provider ID. 5) On transient failure: retry with backoff. 6) After max retries → DLQ and notify ops.
Frequently asked questions
How does idempotency relate to delivery guarantees?
Idempotency does not change network guarantees. It ensures repeated requests produce the same effect, enabling at‑least‑once processing without creating duplicates.
How long should I keep idempotency keys?
Keep them at least as long as your cancellation or billing windows. Many teams keep keys 30–90 days. Consider auditing and Swiss data rules.
What triggers moving a request to a Dead‑Letter Queue?
Exhausted retries or clear permanent errors (validation or bad payload). DLQ entries should be inspected and resolved manually or reprocessed after fixes.
Any data protection concerns?
Yes. Store only necessary fields, encrypt sensitive data, control access and document retention according to Swiss and EU regulations where applicable.