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.
Technical checklist: API implementation for courier booking
A concise technical checklist for integrating a courier booking API for Swiss companies. Covers endpoints, sample payloads, return codes, rate limits and security tips.
Quick answer
This checklist summarizes the technical points your engineering team needs for a stable and secure integration of a courier booking API: endpoints, authentication, example payloads, common response codes, rate limits, error handling and security best practices.
1. Project kickoff and requirements
Start by defining scope and use cases: standard delivery, overnight, same-day within Switzerland. Confirm allowed package sizes and packaging rules. Agree on expected logging, monitoring and a sandbox test environment separate from production.
2. API endpoint overview
List required endpoints. Typical endpoints: POST /bookings (create booking), GET /bookings/{id} (get status), PUT /bookings/{id} (update), DELETE /bookings/{id} (cancel), GET /rates (price quote), POST /webhooks (register webhook). Use consistent versioning like /v1/bookings.
3. Authentication and authorization
Prefer token-based auth (OAuth 2.0 Client Credentials or API keys with HMAC). Transmit tokens only over HTTPS. Use role-based access to separate test and production rights. Plan for token rotation and refresh.
4. Example payloads
Provide JSON payloads for main actions. Example POST /v1/bookings: {"sender":{"name":"Sample AG","address":"Bahnhofstrasse 1, 8001 Zürich"},"recipient":{"name":"Client","address":"Limmatquai 10, 8001 Zürich"},"pickup_time":"2026-09-06T09:00:00+02:00","service":"overnight","package":{"weight_kg":2.5,"dimensions_cm":{"l":30,"w":20,"h":10},"content":"documents"}}. Specify required and optional fields and formats (use ISO 8601 for timestamps).
5. Response codes and error handling
Use standard HTTP status codes. Examples: 201 Created (booking created), 200 OK (status), 400 Bad Request (validation), 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests, 500 Internal Server Error. Return machine-readable error codes and short messages in the body.
6. Rate limits, throttling and retries
Document limits per endpoint and client, e.g. 60 requests/min for bookings. Implement exponential backoff on 429 and 5xx responses. Use idempotency keys for POSTs to avoid duplicate bookings.
Frequently asked questions
How do I test integration without live bookings?
Use a sandbox environment with non-production data and separate API credentials. Test webhooks with simulated events before enabling production callbacks.
Which security measures are mandatory?
Require HTTPS, token-based auth, input validation, rate limits, webhook IP whitelisting and encryption of sensitive data at rest and in transit.
How to prevent duplicate bookings?
Use idempotency headers (e.g. Idempotency-Key) and store external booking_id references locally to detect repeated requests.
What logging and monitoring should I implement?
Log request/response IDs, status codes, latencies and error details. Alert on sustained 5xx errors, rising 4xx rates or breached rate limits.