API integration for Chronopost
We build your Chronopost connector
We connect your ERP or store to the Chronopost web services so the label is issued at packing, the skybill is tied to the order and tracking lands in the customer record, with no spreadsheet and no carrier portal.
- Senior product team
- carrier connectors in production
- from scoping to monitoring
What does the Chronopost API provide and why integrate it into business software?
Chronopost is the express delivery service of the La Poste group for express shipments in France and internationally. Its API lets your application create a parcel, generate the shipping label and track the delivery directly from your software. You integrate it to move label generation out of the Chronopost client area and into the dispatch process, attach the tracking number to the order or client file automatically, and display real-time delivery status without the team manually consulting the carrier portal.
What our clients build on the Chronopost API
Label at packing
The order moves to preparation, shippingV7 creates the parcel, the skybill is stuck on the delivery note. The warehouse prints, it no longer retypes the address.
Rate and delay before checkout
quickCostV3 and calculateDeliveryTime feed the checkout. Chrono 10, 13, 18 or Relais stop being a decorative menu.
Support with proof of delivery
The latest trackSkybillV2 event shows up on the ticket. searchPOD attaches the POD to the file, instead of a carrier email.
Evening pickup from the WMS
Once the last carton is weighed, creerEnlevementNational goes out. No more web form for a warehouse that ships every day.
What it changes in your logistics
Engineering in service of a measurable outcome: the label at packing, tracking in the record, zero duplicate parcels.
The label comes from the business software
No more PDF downloaded by hand from the carrier portal. The skybill is order data, printed at the right time.
Support reads the same status
Tracking lives in the ERP. You stop opening Chronotrace to answer « where is the parcel ».
A timeout does not create two parcels
The skybill is persisted before the order is marked shipped. A replay reads the table, it does not call shippingV7 a second time.
The existing contract is enough
Chronopost is often already the client's carrier. The integration does not add a network, it removes the spreadsheet.
How we ship your Chronopost connector
Scoping
Which products (Chrono 10, 13, 18, Relais), single or multi-parcel, pickup, returns. We freeze the SOAP operations before generating the client.
Development
SOAP client regenerated from the live WSDLs, operations frozen (shippingV7, trackSkybillV2, quickCostV3), idempotency table, print queue decoupled from the call.
Acceptance testing
Accented French addresses, a timeout replayed with no second parcel, PDF or ZPL label per the contract, tracking limited to open parcels.
Monitoring
Alerts on SOAP failures, an inspectable dead letter queue, a tracking job limited to undelivered parcels. You see a broken WSDL before the warehouse does.
What the Chronopost API allows
- Shipping and labels
- shippingV7 creates the parcel, shippingMultiParcelV7 handles split orders. The PDF or ZPL label comes afterwards, without recreating the skybill.
- Tracking and proof of delivery
- trackSkybillV2 polls the parcel, searchPOD brings back the POD. No webhook: a bounded job, not a scan of the full history.
- Rate and delay at checkout
- quickCostV3 and calculateDeliveryTime show a price and a date before confirmation, against the real contract, not a frozen grid.
- On-demand pickup
- faisabiliteESD then creerEnlevementNational: a flow separate from shipping, with depot constraints. Mixing them is a business error.
The vocabulary of the Chronopost API
- skybillNumber
- The Chronopost parcel number. It is the key to persist before marking the order shipped: without it in the database, a timeout followed by a replay creates a second parcel.
- shippingV7
- The current SOAP operation for creating a shipment. The WSDL still keeps shipping, shippingV2 through shippingV6: calling « whatever is last in the file » without freezing it is a library trap.
- reservationNumber
- The label reservation identifier, to be stored with the skybill. It is what you use to retrieve the document without running creation again.
- ESD
- On-demand pickup. faisabiliteESD then creerEnlevementNational, with depot constraints (hla, hlp, codeAgence). It is not a shippingV7 parameter.
- Chronotrace
- The tracking portal and the source of the API password, obtained from sales. Without a contract and a Chronotrace password, the WSDL answers but ships nothing.
- quickCostV3
- The contract rating operation. Paired with calculateDeliveryTime, it makes the Chrono 10 / 13 / 18 / Relais choice actually priced in the funnel.
The real constraints of the Chronopost API
No documented idempotency
Retrying shippingV7 after a timeout creates a second parcel. The key is yours: persist skybillNumber before treating the call as successful, and call the operation only once per order.
No public REST and no webhook
Native integration goes through the WSDLs. Tracking is polled (trackSkybillV2) or read in Chronotrace. A generic « carrier connector » that expects signed JSON produces silent tracking.
Versioning lives in the name
Seven shipping* versions coexist in a single WSDL. A library generated in 2022 can call an operation that is still listed but behaviourally stale. We regenerate from the live WSDL, and we freeze V7.
Quotas are not published
Nothing numeric is shown on chronopost.fr. Staging, sandbox and throughput are negotiated with sales. A quote that starts with « we take an API key » is wrong.
Chronopost or Colissimo for your shipments?
Two La Poste networks, two API contracts. Express on one side, home and pickup-point density on the other. The right one depends on the delay you sell.
| Criterion | ChronopostThis page | ColissimoLa Poste density |
|---|---|---|
| Protocol | SOAP only, public WSDLs | SOAP and REST v2, same SLS contract |
| Network | Express Chrono 10 / 13 / 18 / Relais | Home, post office, locker, pickup point |
| Label | shippingV7 then getSkybill | generateLabel: pre-alert and PDF together |
| Validation without a parcel | No equivalent documented method | checkGenerateLabel, no number and no pdfUrl |
| Real-time tracking | Polling, no documented webhook | Tracking web service behind the business portal |
| Idempotency | To be built in your database | To be built in your database |
| The right case | B2B express, delay sold at checkout | Dense French checkout, letterbox returns |
The two combine behind an internal abstraction (create, track, cancel). Chronopost and Colissimo do not share the same error contract. It is a scoping trade-off, not a permanent choice.
What we measure on a Chronopost integration
The other carrier APIs
If express is not the product you sell, these options are worth discussing during scoping.
ChronopostWe build your Chronopost connectorThis page
Colissimo & La PosteFrench density: home, pickup points, lockers, letterbox returns.
Mondial RelayPickup points and Dual Carrier, including cross-border partner flows.We combine Chronopost with
The stack that surrounds Chronopost on our projects.
Chronopost integration: your questions
Three steps. Obtain the contract number and the Chronotrace password from sales: without them the WSDLs answer but ship nothing. Generate a SOAP client from the live WSDLs (shipping, tracking, quickcost) and freeze shippingV7, trackSkybillV2 and quickCostV3, rather than calling an older operation still listed. Then put an order-to-skybillNumber table, written before marking the shipment, and a label print queue decoupled from the SOAP call. The sensitive part is not the WSDL: it is idempotency, because a timeout followed by a replay creates a second parcel.
A first useful flow, typically the label at packing with the skybill tied to the order, ships in three to four weeks. A complete chain with rates at checkout, multi-parcel, ESD pickup, POD in support and a bounded tracking job is closer to six to eight weeks. Duration depends less on SOAP than on contract access, the staging environment negotiated with sales, and the label format (PDF or ZPL). We scope the perimeter up front and give a firm estimate before we start.
No public REST API documented by Chronopost, and no tracking webhook on the public WSDLs. Native integration goes through SOAP: ShippingServiceWS, TrackingServiceWS, QuickcostServiceWS. Tracking is polled with trackSkybillV2, or read in Chronotrace. The PrestaShop, WooCommerce, Shopify or Magento modules are a shop shortcut, not an ERP connector. If your architecture assumes signed JSON and a self-service API key, scoping has to say so immediately: that is not the Chronopost contract.
Chronopost is express (Chrono 10, 13, 18, Relais) in SOAP only, with rate and delay exposed before confirmation. Colissimo is La Poste density (home, post office, locker, pickup point) with a single SLS contract in SOAP and REST v2, and checkGenerateLabel to validate without consuming a parcel number. Both require a contract, neither offers native idempotency. You pick Chronopost when the delay you sell is express. You pick Colissimo when checkout must offer the densest network, including letterbox returns. Sometimes the answer is both, behind the same internal abstraction.
By not trusting the network. shippingV7 has no documented idempotency header. We persist skybillNumber and reservationNumber before marking the order as shipped. A timeout reads that table, it does not call the operation again. Printing (PDF or ZPL) is a separate queue: a printer failure reprints the stored document, it does not recreate the parcel. The tracking job only covers open skybills. It is the same discipline as for Colissimo and Mondial Relay, with a different error contract each time.
A Chronopost integration project?
Let's talk. 30 minutes to scope your flows, check what the WSDLs actually allow and tell you honestly what is feasible.
Discuss my Chronopost project