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 for courier bookings: tech, security and testing
A practical guide for Swiss companies: required API endpoints, authentication and transport security, plus test cases and monitoring for automated courier bookings.
Quick answer
To automate courier bookings you need stable endpoints for quotes, booking, tracking and cancellations; secure authentication (API keys or OAuth2); a sandbox for testing; and monitoring. These pieces let Swiss companies integrate a courier service reliably into their systems.
What the API must provide
A courier API for automated bookings should expose clear endpoints: quote/pricing, create booking, pickup and delivery time windows, tracking, cancel/modify, and document retrieval (e.g. waybill). Ensure JSON responses and consistent error codes. For Swiss routes include postal code, city (Zürich, Bern, Genève) and pickup windows.
Authentication and authorization
Secure authentication protects your orders. Common methods are API keys with role restrictions or OAuth2 for more complex setups. Use separate keys for test and production. Restrict keys by IP or service where possible. Avoid logging secrets in plain text.
Secure transmission and privacy
Send all API calls over HTTPS/TLS. Protect personal data under DSGVO/DSV rules and send only what is necessary (name, phone, address, packing notes). Log access attempts for audits but exclude confidential fields.
Key test cases and sandbox setup
Plan tests for positive and negative flows: successful booking, missing required fields, invalid addresses, pickup outside business hours, cancellation before pickup, address change, and repeated requests (idempotency). Use a sandbox with test API keys. Simulate network failures and delayed responses to validate timeouts and retry logic.
Webhooks, polling and tracking
Webhooks are efficient for live status: events like order accepted, driver en route, delivered or cancelled are posted to your URL. Validate incoming webhook requests (signatures, timestamps). If webhooks are not available, use polling with an exponential backoff. Provide a clear status timeline in your UI (pickup ETA, live tracking link).
Monitoring, alerting and SLA checks
Monitor API latency, error rates and throughput. Create alerts for spikes in errors, increased response times or sandbox failures. Run regular end‑to‑end checks: book, confirm pickup, receive tracking updates, cancel. These tests show whether integrations hold up under load.
Frequently asked questions
Which endpoints are essential to start?
At minimum: quote/pricing, create booking, tracking and cancel. Also a health‑check endpoint to monitor availability.
How do I test delivery statuses without live orders?
Use the provider's sandbox with simulated status events or a webhook replay feature. Alternatively run a mock server that returns expected responses.
How to avoid duplicate bookings during network issues?
Implement idempotency keys for booking creation. The API should treat repeated requests with the same key as one order.
What belongs in logs without breaking privacy?
Store request IDs, status codes, timestamps and non‑sensitive metadata. Mask or omit names, phone numbers and addresses.