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.
Webhook architecture: Best practices for reliable delivery status events
How to build a robust webhook architecture for delivery status events. Focus on retries, HMAC signatures, persistent queues and monitoring for Swiss integrations.
Quick answer
A reliable webhook architecture delivers delivery status events safely, consistently and traceably to your systems. Key components are idempotent events, staged retry logic, HMAC signatures, persistent queueing and comprehensive monitoring. Together they cut lost events, duplicates and incorrect states.
Why use webhooks for delivery status
Webhooks push real‑time events to your system, such as pickup and delivery updates in Zurich, Basel or Geneva. They reduce the need for polling and provide timely state changes. The receiver must be able to handle events reliably.
Idempotent events and unique IDs
Every event needs a stable, unique ID (for example UUIDv4) and a clear event type. Your API should detect duplicates and handle them idempotently. Idempotency prevents double bookings and incorrect status transitions when the same event is sent more than once.
Retry strategies: backoff, limits and dead‑letter
Use exponential backoff with randomized jitter, e.g. 1s, 2s, 4s, 8s plus jitter. Cap retries (for example 5–10 attempts) and move undeliverable messages to a dead‑letter queue (DLQ). Keep context in the DLQ for manual inspection or replay by support teams in Bern or Lausanne.
Persistent queueing and best‑effort delivery
Place a persistent message queue (for example RabbitMQ, Kafka, managed Pub/Sub) between event producers and dispatchers. The queue smooths spikes, preserves order when needed, and exposes backlog. A write‑ahead log in your database can be an alternative when a separate message layer is not wanted.
Security: HMAC signatures and TLS
Sign payloads with HMAC (SHA‑256) using a shared secret. Send the signature in a header so receivers in Basel or Zurich can verify authenticity. Require TLS (HTTPS) and current ciphers. Rotate secrets and version signature headers.
Receiver processing and validation
The receiver should acknowledge quickly (2xx) and process events asynchronously. Validate schema, timestamps and signature. Enforce valid state transitions: a package cannot be 'delivered' then later 'picked up'. Reject invalid events with clear HTTP codes and logs.
Frequently asked questions
How long should a sender wait for acknowledgement?
Answer: Use short HTTP timeouts (for example 5–10s) for initial acceptance to avoid blocking connections. Perform actual work asynchronously via the queue.
What if the receiver has network outages?
Answer: Retry with backoff, then DLQ. Alert operators. Offer a replay API to resend events manually when systems recover.
How to prevent replay attacks?
Answer: Combine HMAC signatures with a timestamp header. Accept events only within a narrow time window (for example 5–15 minutes) or keep processed event IDs to detect replays.
Which monitoring metrics matter most?
Answer: Success rate (2xx), error split (4xx/5xx), latency distribution, queue length, DLQ entries and replay counts. Show these in dashboards and set alerts for anomalies.