# Idempotency & Retries for Shipping Integrations | x25pronto Canonical: https://x25pronto.ch/en/blog/idempotenz-und-retries-bei-versandintegration-implementieren.html VW Tiguan R · 320 PS 4MOTION · discreet · direct EXPRESS COURIER · DIRECT · MON–SUN Courier service Switzerland. 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. [Calculate price](https://x25pronto.ch/en/#quote)[How overnight works](https://x25pronto.ch/en/overnight.html) Direct Mon–Sun Overnight Mon–Sun Car & van up to 1,000 kg COURIER INSIGHTS # 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. 24 September 2026 ## 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. ## Plan a courier trip in Switzerland x25pronto Switzerland carries small and well packed shipments by car. Businesses can choose a direct courier trip or overnight service. Route, timing and shipment details can be entered online before booking. The guide price is then shown for the planned courier order. [Direct courier →](https://x25pronto.ch/en/direct-courier.html)[Overnight →](https://x25pronto.ch/en/overnight.html)[Services →](https://x25pronto.ch/en/services.html)[Calculate guide price →](https://x25pronto.ch/en/#quote) ### At a glance: Implementing idempotency and retries in shipping integrations Key points from this article. Follow the links to read each explanation. Why idempotency matters for shipping Shipping integrations link your order system to carrier APIs and internal workflows. [Read this section](https://x25pronto.ch/en/blog/idempotenz-und-retries-bei-versandintegration-implementieren.html#courier-article-step-1) Core idea: a unique idempotency key Each unique shipment action needs an idempotency key. [Read this section](https://x25pronto.ch/en/blog/idempotenz-und-retries-bei-versandintegration-implementieren.html#courier-article-step-2) Key design rules Keep the key constant for the same business action. [Read this section](https://x25pronto.ch/en/blog/idempotenz-und-retries-bei-versandintegration-implementieren.html#courier-article-step-3) Retries: backoff strategies and limits Classify errors: transient (network, 5xx) vs permanent (4xx, validation). [Read this section](https://x25pronto.ch/en/blog/idempotenz-und-retries-bei-versandintegration-implementieren.html#courier-article-step-4) Integration steps — practical flow Generate idempotency key before API call. [Read this section](https://x25pronto.ch/en/blog/idempotenz-und-retries-bei-versandintegration-implementieren.html#courier-article-step-6) More on this topic These guides cover related questions: [Idempotency, retries and rate limiting for courier APIs](https://x25pronto.ch/en/blog/idempotenz-retries-und-rate-limiting-bei-kurier-apis.html) · [Implementing OAuth2 flows for B2B logistics integrations](https://x25pronto.ch/en/blog/implementierung-von-oauth2-flows-fur-b2b-logistikintegrationen.html)