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 checklist for integrating shipment and tracking data
Concrete checklist for developers: which endpoints, authentication, webhooks and tests you need to connect shipment and tracking data to your systems.
Quick answer
In short: a reliable integration needs clear endpoints for order creation, status queries and tracking, secure authentication, dependable webhooks and thorough test cases. Prepare for retries, error codes and idempotency. Use this checklist to build a stable link between your ERP/shop and a courier like x25pronto in Switzerland.
1. Define the integration outcome
Start with clear goals. Decide which data you need in real time: orders, tracking numbers, status updates, proof of delivery (photo or signature) or basic tracking only. Identify the target systems (ERP, shop, WMS) and mandatory fields (sender, recipient, dimensions, service level).
2. Essential endpoints
Plan these endpoints: 1) create-order: send sender, recipient, parcel data and references; 2) get-order-status: synchronous current status; 3) get-tracking: timestamps, location, status codes; 4) update-order / cancel-order; 5) get-rates: optional for selecting services. Document required fields and response JSON schemas.
3. Authentication and security
Use token-based auth (OAuth2 client credentials or short-lived API keys). Protect all endpoints with HTTPS/TLS. Implement roles and scopes so write access can be distinct from read-only tracking. Rotate keys regularly and log failed auth attempts. Restrict IPs or use mTLS for higher security.
4. Webhooks and event model
Use webhooks for real-time status updates (pickup-confirmed, in-transit, out-for-delivery, delivered, exception). Define a retry policy (e.g. 3 attempts with exponential backoff) and include an HMAC signature so you can verify authenticity. Provide a test endpoint and document payloads and expected HTTP responses (200 OK on success).
5. Error handling, idempotency and retries
Standardize error codes (4xx for client, 5xx for server). Support idempotency keys on order requests to avoid duplicate shipments. Implement automatic retries for transient errors and return informative error messages for developers and support staff.
6. Test cases and sandbox
Provide a sandbox environment. Test: valid/invalid order creation; status changes via webhook; cancellations; rush orders; high load and rate-limiting; auth failures. Automate tests in CI to catch regressions early. Publish example requests/responses and Postman or OpenAPI specs.
Frequently asked questions
Which fields are mandatory for order creation?
Typically: sender/recipient details, parcel dimensions/weight, service level, reference number and order reference. Exact mandatory fields depend on the API provider; include them in your integration spec.
How do I verify a webhook is authentic?
Use an HMAC signature header or a shared secret. Compute the hash of the payload and compare it with the header. Accept only HTTPS connections.
What is idempotency and why does it matter?
Idempotency prevents duplicate orders during network retries. The client sends an idempotency key; the server performs the action once and returns the same result for repeated requests using the same key.
How do I safely test rate limits?
Simulate load in the sandbox. Gradually increase requests and observe when 429 responses appear. Implement client-side backoff and caching to respect limits.