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 design for resilient ERP integrations
Design webhooks that keep ERP systems in Geneva, Zurich and Basel consistent. Covers idempotent events, HMAC signatures, retry backoff and monitoring.
Quick answer
Resilient webhook design ensures ERP systems in Geneva, Zurich or Basel receive and process events reliably. Use unique event IDs, signed payloads, exponential retries with jitter, and clear HTTP status conventions. Add dead‑letter queues, logging and health checks so late or repeated deliveries are handled safely.
Why robust webhooks matter
ERPs handle invoices, orders and stock levels. Webhooks push updates in real time. Poor webhook design causes duplicate entries, lost events or security gaps. A clear approach reduces recovery work and keeps Swiss operations running smoothly.
Unique event IDs and idempotency
Give every event a globally unique ID (UUID or object‑ID plus sequence). Make receivers process events idempotently: reprocessing the same ID must not create side effects. Keep a short-lived store of handled IDs based on your business retention needs.
Signature and authenticity
Protect payloads with HMAC signatures (e.g., SHA‑256 with a shared secret) or JWTs. Verify signatures on receipt and reject unauthorized requests. Add a timestamp to mitigate replay attacks and discard messages outside an allowed window.
Retry strategies and backoff
Use exponential backoff with jitter rather than fixed retries. Example: immediate, 2s, 8s, 1min, 5min, 30min. Cap retries and total retry time. Use HTTP codes semantically: 2xx = success, 4xx = client error (do not retry), 5xx = server error (retry). Document the policy in your API contract.
Deduplication and ordering
Rely on event IDs and optionally sequence numbers or version fields. When order matters (e.g., status transitions), use sequence checks. If ordering cannot be guaranteed, support compensating transactions or reconciliation jobs.
Dead‑letter queues and remediation
Move failed deliveries to a dead‑letter queue after retry limits. There ops staff or automated jobs can inspect and replay or correct events. Store metadata: last response, attempt count and timestamps to speed troubleshooting.
Frequently asked questions
How long should I keep processed event IDs?
Keep IDs at least as long as you need to revert or audit a business transaction. Common ranges are 30–90 days. Adjust for compliance and internal audit rules.
Which HTTP codes should webhooks use?
2xx for success. 4xx for permanent client errors (e.g., invalid signature or missing resource) — do not retry. 5xx for temporary server errors — schedule retries. 429 for rate limits and include Retry‑After header.
How do I prevent replay attacks?
Combine signature verification with timestamps and single‑use nonces or by checking for already processed event IDs. Reject messages outside the allowed time window.
When should I add a dead‑letter queue?
Add a DLQ when automated retries can’t resolve failures or when messages contain bad payloads. DLQs let operators or automated flows inspect, correct and replay events safely.