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.
API integration: Real-time booking data between courier and ERP
Connect your ERP to a courier with REST APIs and webhooks: secure auth, compact JSON model, idempotent endpoints, structured errors and webhook signing for real-time booking data.
Quick answer
Connect your ERP to the courier via REST API for bookings and Webhooks for live status updates. Use secure authentication (OAuth2 or API keys), a compact JSON data model for pickup and delivery, idempotent endpoints, structured error codes and retries. Sign webhooks to verify authenticity. This reduces manual work and speeds up processes for Swiss operations in Zurich, Basel or Geneva.
Define use cases first
Clarify what you need: instant status updates, automated bookings, or returns handling? Define required fields: pickup address, delivery address, parcel dimensions, time windows, service code, reference IDs and contact info. Decide whether your ERP will create bookings (REST POST) or only receive status (webhooks).
Suggested compact JSON model
A small model lowers errors. Example fields: booking_id, client_reference, pickup {name, street, city, postal_code, country, earliest, latest}, delivery {name, street, city, postal_code, country, contact_phone}, parcels [{weight_kg, length_cm, width_cm, height_cm}], service_code, special_instructions. Use ISO-8601 for times and ISO country codes (CH, DE, FR).
Authentication and security
Use OAuth2 Client Credentials or short-lived API keys with IP restrictions. Enforce TLS 1.2+. Sign webhook payloads with HMAC-SHA256 and a shared secret so your ERP can verify events. Log requests with a request ID for tracing.
Webhooks: design and best practices
Send status events (accepted, pickup_scheduled, picked_up, in_transit, delivered, failed). Ensure idempotency: each event carries a unique event_id and timestamp. Acknowledge with HTTP 2xx. The courier should retry with exponential backoff when your ERP returns 5xx or times out. Version and document event schemas.
Idempotency, versioning and errors
Make POST/PATCH idempotent to avoid duplicate bookings. Use a unique client_reference from the ERP. Keep API versions in URL paths (/v1/, /v2/) instead of changing payloads. Standardize error responses: 4xx for validation, 401 for auth, 429 for rate limits, 5xx for server issues. Provide machine-readable error details.
Testing and monitoring
Provide a sandbox with webhook replay and sample payloads. Publish an OpenAPI spec and Postman collections. Run contract tests and end-to-end checks. Monitor webhook success rate, latency and error counts. A dashboard helps operations teams in Zurich, Basel or Lausanne to react quickly.
Frequently asked questions
Which webhook events are essential?
Minimum events: booking_created, booking_confirmed, pickup_scheduled, picked_up, in_transit, delivered, delivery_failed. Include event_id, booking_id and timestamp with each event.
How do we avoid duplicate bookings?
Send a unique client_reference per order. The API checks this and returns the existing booking_id or makes the POST idempotent.
How should we secure webhooks?
Sign payloads using HMAC-SHA256 and a shared secret. Validate the signature and timestamp and reject replayed requests.
What rate limits should we expect?
Apply per-key rate limits, for example 1000 requests per minute per client. Expose limits via response headers and return 429 with Retry-After.