# Idempotency, retries and rate limiting for courier APIs

Canonical: https://x25pronto.ch/en/blog/idempotenz-retries-und-rate-limiting-bei-kurier-apis.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

# 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.

9 September 2026

## 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.

## 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: Idempotency, retries and rate limiting for courier APIs

Key points from this article. Follow the links to read each explanation.

Why idempotency matters Repeated requests to a courier booking endpoint can cause duplicate shipments. [Read this section](https://x25pronto.ch/en/blog/idempotenz-retries-und-rate-limiting-bei-kurier-apis.html#courier-article-step-1)

Idempotency key best practices Generate a unique idempotency key for every user intent. [Read this section](https://x25pronto.ch/en/blog/idempotenz-retries-und-rate-limiting-bei-kurier-apis.html#courier-article-step-2)

Retries: when and how often Retries are useful for transient errors: network timeouts, brief outages or connectivity blips. [Read this section](https://x25pronto.ch/en/blog/idempotenz-retries-und-rate-limiting-bei-kurier-apis.html#courier-article-step-3)

Backoff strategies: exponential with jitter Exponential backoff increases wait time between attempts (1s, 2s, 4s). [Read this section](https://x25pronto.ch/en/blog/idempotenz-retries-und-rate-limiting-bei-kurier-apis.html#courier-article-step-4)

Handling rate limits in operations APIs often expose rate info in headers (for example X-RateLimit-Remaining, Retry-After). [Read this section](https://x25pronto.ch/en/blog/idempotenz-retries-und-rate-limiting-bei-kurier-apis.html#courier-article-step-5)

More on this topic These guides cover related questions: [Implementing idempotency and retries in shipping integrations](https://x25pronto.ch/en/blog/idempotenz-und-retries-bei-versandintegration-implementieren.html) · [Best practices for idempotency and event versioning in courier APIs](https://x25pronto.ch/en/blog/best-practices-fur-idempotenz-und-event-versionierung-in-kurier-apis.html)