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.
Integration checklist: connecting tracking APIs to ERP
Connect a tracking API to your ERP so shipment events arrive reliably. Define data fields, authentication, webhook rules, error handling and tests first.
Quick answer
Connect the tracking API so your ERP receives consistent shipment events in real time or near‑real time. Start by defining required data fields, authentication method and webhook behaviour. Establish error handling and test plans. This checklist helps Swiss companies plan a stable integration with clear milestones.
1. Define scope and objectives
Begin with clear goals: which tracking events should reach the ERP? Typical events: pickup, in‑transit, delivery, returns. Decide on delivery mode (real‑time webhooks vs. polling) and which ERP modules will consume the data (order management, warehouse, billing). Set success metrics, for example maximum display latency in the ERP.
2. Data fields and mapping
Create a mapping table listing source fields (API) and target fields (ERP). Key fields: tracking number, status code, timestamp (ISO 8601), location (city, postal code, coordinates optional), partner ID, weight and notes. Document formats, mandatory fields, max lengths and default values for missing data.
3. Authentication and security
Pick a secure auth method: OAuth2, API keys with IP restrictions or signed tokens. Use HTTPS/TLS for all endpoints. Plan key rotation and scopes so systems only get needed rights. Avoid logging sensitive fields.
4. Webhooks, polling and event model
Choose webhooks (push) or polling (pull). Webhooks reduce latency but require reliable public endpoints and acknowledgement (e.g. 200 OK). Define the event model: which status changes trigger events and what payloads are sent. Design idempotency so duplicate events don’t corrupt order states.
5. Error handling and retry policies
Classify errors: transient (network), persistent (invalid payload) and business errors (invalid status). Define retry rules: exponential backoff, max attempts and a dead‑letter queue for manual review. Add monitoring and alerts for recurring failures.
6. Testing and test data
Provide a separate test environment for API and ERP. Use realistic test data covering normal flows and edge cases. Test error scenarios: latency, timeouts and malformed payloads. Automate end‑to‑end and regression tests before production rollout.
Frequently asked questions
Which fields are essential to start?
At minimum: tracking number, status code, timestamp and a location or destination. These allow the ERP to match updates to orders and reflect current status.
When are webhooks preferable to polling?
Webhooks suit low‑latency needs and when your ERP has stable, reachable endpoints. Polling is useful when network constraints exist or you want full control over fetch timing.
How do we ensure idempotency for repeated events?
Include a unique event ID with each webhook. Have the ERP check if the event ID was already processed. Alternatively use a combination of tracking number, status and timestamp.
How to test safely in production?
Use a staging environment and anonymised production‑like data. Roll out in phases (canary) starting with a small set of shipments, increase scope after validation.