One endpoint for every step of the shipment. You call Qapla', and Qapla' talks to the right courier: in your code there is no separate line written for BRT, one for GLS and one for Poste.
API and webhooks in detailEach courier writes updates its own way. The webhook reaches you already translated into one of Qapla' 9 statuses, with the courier's original text next to it. Your ERP, management software and helpdesk read a single format.
You test everything in a separate environment, then switch keys. API versions stay stable, so a Qapla' update won't break your code.
You don't need to change your warehouse flow. Your system keeps printing, and sends the statuses to Qapla' via API. From there come the customer alerts, the tracking page with your brand and the reports, just as for any other courier.
Also useful for local couriers, own fleets and deliveries to each floor.
The answers IT, procurement and legal need before signing.
Documented REST APIs to create shipments and labels, import orders, read tracking, request quotes and look up pickup points, plus webhooks at every status change.
No. You integrate Qapla’ once and work with 45+ couriers for labels and 450+ for tracking, with the same statuses for all of them.
Yes. There is a sandbox, with separate keys for each channel and environment.
If you already print labels with your own system, you send status updates to Qapla’ via API, and from there customer alerts and the tracking page are triggered.
Yes. The Qapla’ MCP server gives your AI assistants access to shipment data, and the public qapla-api skill helps the assistant write the integration.