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.
Using webhooks effectively: real‑time events for your supply chain
Webhooks push pickup, delivery and delay events in real time to ERP, WMS or CRM. This guide explains architecture, security and idempotency for Swiss companies.
Quick answer
Webhooks are an efficient way to push pickup, delivery and delay events in real time to your ERP, WMS or CRM. Set up a secure HTTPS endpoint, validate signatures, make payloads idempotent and implement retries with a dead‑letter path. That keeps shipment status current for operations in Zurich, Basel or Geneva.
What webhooks do for logistics
Webhooks are HTTP callbacks a courier sends when a shipment status changes. Typical events: pickup_confirmed, driver_en_route, delivered, delayed, exception. Instead of polling, your systems receive updates immediately. That reduces latency, simplifies inventory updates and improves customer notifications.
Which events to push to ERP, WMS and CRM
Core events: pickup_requested, pickup_confirmed, in_transit, delayed, delivered, exception. ERP needs order numbers, item counts and delivery states. WMS requires slot releases, return info and time windows. CRM benefits from tracking links, proof of delivery and customer alerts.
Payload design and idempotency
Keep payloads clear: stable field names (order_id, shipment_id, event_type, timestamp, location). Include an event_id that uniquely identifies each message. Your receiver should deduplicate by event_id or by checking shipment state. Idempotent handling prevents double-posting or wrong inventory adjustments.
Security and authenticity
Use HTTPS/TLS and accept requests only from known IP ranges or signed headers. A common method is an HMAC signature header (e.g. X‑X25pronto‑Signature) computed over the payload with a shared secret. Check timestamps to block replay attacks and log suspicious requests separately.
Reliability: retries, backoff and dead‑letter handling
Implement retries with exponential backoff. Consider HTTP 200/201 as success signals. After repeated failures, move the message to a dead‑letter queue and alert ops or your monitoring system. This preserves critical delivery state even when receivers are down.
Practical tips for Swiss companies
Begin with a sandbox and a small set of events. Match your correlating IDs to those used in SAP, Abacus or other ERPs. Simulate delays (motorway congestion) and test how your CRM triggers customer messages. Publish a versioned schema and a change policy so teams stay aligned.
Frequently asked questions
How fast do webhook events arrive?
Events typically arrive within seconds to a few minutes, depending on network and processing. They are much faster than periodic polling.
How do I handle duplicate events?
Use an event_id and idempotent processing. Ignore repeated event_ids or check whether the status has already been applied.
How do I verify a webhook's authenticity?
Validate an HMAC signature in a header using your shared secret. Accept only HTTPS and, where possible, requests from known IP ranges.
Which fields should be in a minimal payload?
At minimum: event_id, shipment_id, order_id, event_type, timestamp, location (optional: lat/long) and a human_readable_message if useful.