API integration for Colissimo
We build your Colissimo connector
We connect your store or WMS to the Colissimo web services so checkout offers a real pickup-point choice, the pre-alert leaves with the label, and the parcel number lands on the order.
- Senior product team
- carrier connectors in production
- from scoping to monitoring
What does the Colissimo API provide and why integrate it into a shipping workflow?
Colissimo is La Poste's standard parcel service, used by the majority of e-commerce businesses and companies that ship across France and Europe. Its API lets you generate a shipping label, display eligible pick-up points in your checkout, and track each parcel. You integrate it to automate shipping from the back office or ERP, eliminate double data entry between the management software and the Colissimo client area, and automatically send the tracking link to the recipient as soon as the parcel is collected.
What our clients build on the Colissimo API
Checkout with a pickup-point map
findRDVPointRetraitAcheminement lists eligible points at the address typed in. The pickup point is no longer a dead field in the funnel.
SLS label at packing
generateLabel files the pre-alert and returns PDF or ZPL. The thermal printer prints, La Poste already knows the parcel.
Returns with no printer
getListMailBoxPickingDates then planPickup: the customer no longer has to print or drop off at the post office. That is an e-commerce argument.
Export with CN23 in the same call
getProductInter and generateLabel carry the international options. The business software no longer has to know the customs form.
What it changes in your logistics
Engineering in service of a measurable outcome: a chosen pickup point, a pre-alert sent, a return with no printer.
The pickup point is a checkout object
Hours, eligibility, identifier stored on the order. No longer a list copied from a map PDF.
The parcel is no longer a stranger at the depot
The pre-alert leaves with the label. Without it, two tools, two gestures, and a parcel La Poste is not expecting.
A second generateLabel is not a reprint
The parcel number and the PDF are persisted. Reissuing means reprinting the stored file, not sending a second pre-alert.
Checkout survives a Pudo outage
If supervision.jsp returns [KO], we degrade to home delivery or a queue, we do not show an empty map.
How we ship your Colissimo connector
Scoping
Home, pickup points, international, letterbox returns, SOAP or REST. We reread the product codes on the contract, we do not freeze a 2022 enum.
Development
Address and phone normalisation before the call, checkGenerateLabel at checkout, generateLabel once per carton, PDF and CN23 kept.
Acceptance testing
SLS test labels, no live parcels. SOAP XML order checked, Pudo supervision [KO] replayed, a malformed phone rejected before franking.
Monitoring
Health-check of supervision.jsp, alerts on generateLabel failures, an inspectable dead letter queue. You see a pickup-point WS down before your customers do.
What the Colissimo API allows
- SLS franking
- generateLabel: pre-alert, label (PDF, ZPL, DPL) and CN23 in the same call. REST v2 or SOAP v2, it is the same business contract.
- Validation without a parcel number
- checkGenerateLabel replays the checks with no pdfUrl and no identifier. The funnel can fail cleanly before the logistics commitment.
- Pickup points
- findRDVPointRetraitAcheminement and findPointRetraitAcheminementByID. The widget is faster to drop in, with less graphic control.
- Letterbox collection
- getListMailBoxPickingDates then planPickup, on return products CORE 8R and CORF CQ. Support no longer requires a printer from the customer.
The vocabulary of the Colissimo API
- SLS
- Simple Label Solution: the franking contract. SOAP v2 and REST v2 coexist, v2 includes all the features of version 1. Choosing REST does not remove the SLS business rules.
- checkGenerateLabel
- A blank check: the same rules as generateLabel, with no number, no XOP links, no pdfUrl. It is not a silent dry-run of the same parser.
- outputPrintingType
- The label format requested: PDF, ZPL or DPL. A thermal warehouse does not expect an A4 PDF. The choice is frozen during scoping, not in an if at packing.
- CN23
- The customs declaration returned with the label for international. Keep it: La Poste does not serve these documents back as an eternal CDN.
- supervision.jsp
- The pickup-point WS supervision page, which contains [OK] or [KO]. A checkout that ignores [KO] shows an empty map the day the Pudo is down.
- unmarshalling error
- A SOAP error when the XML order does not follow the WSDL. A client that serialises by field name rather than by sequence is the first bug of a homemade SDK.
The real constraints of the Colissimo API
The recipient phone makes the label fail
The spec tightened formats (006/007 towards 00336/00337). A poorly normalised « 06 12 34 56 78 » breaks generateLabel, not only Predict SMS. We normalise before the call.
Product codes move
5W, 7U, A2P/9H, BPR/9M, CORF-CQ, EN through EX: an enum frozen in 2022 is wrong in 2026. Codes are reread in the current spec and against the contract tariff.
No native idempotency
One generateLabel per order (or per carton), number persisted, PDF stored. Reissue = reprint. A second call sends a second pre-alert.
SLS quotas are not published
The July 2022 spec does not number throughput or the retry policy. We confirm it during scoping with the business portal, we do not invent a ceiling.
Colissimo or Chronopost for your shipments?
La Poste network density on one side, express on the other. Both require a contract. The right one depends on what checkout promises.
| Criterion | ColissimoThis page | ChronopostExpress |
|---|---|---|
| Protocol | SOAP and REST v2, same SLS contract | SOAP only, public WSDLs |
| Network | Home, post office, locker, pickup point | Express Chrono 10 / 13 / 18 / Relais |
| Label | generateLabel: pre-alert and PDF together | shippingV7 then getSkybill |
| Validation without a parcel | checkGenerateLabel, no number and no pdfUrl | No equivalent documented method |
| Returns | Letterbox collection (planPickup) documented | Return label tied to the original order |
| Idempotency | To be built in your database | To be built in your database |
| The right case | Dense French checkout, letterbox returns | B2B express, delay sold at checkout |
The two combine behind an internal abstraction (create, track, cancel). Distinguishing SLS, pickup points, the widget and the tracking WS avoids the « we wire Colissimo » quote at 4 days. It is a scoping trade-off.
What we measure on a Colissimo integration
The other carrier APIs
If La Poste density is not the network you sell, these options are worth discussing during scoping.
Colissimo & La PosteWe build your Colissimo connectorThis page
ChronopostExpress SOAP: labels, rates, pickups, skybill tracking.
Mondial RelayPickup points and Dual Carrier, including cross-border partner flows.We combine Colissimo with
The stack that surrounds Colissimo on our projects.
Colissimo integration: your questions
Four building blocks, not one. The pickup-point WS in checkout, with a health-check of supervision.jsp and a home-delivery fallback if the page returns [KO]. checkGenerateLabel to validate address, phone (0033 format) and product without consuming a number. generateLabel at preparation, once per carton, PDF or ZPL and CN23 kept. Letterbox returns (dates then planPickup) if support must work without a printer. SOAP or REST v2 is the same SLS contract: we choose the envelope during scoping, we do not mix XML order. The pickup-point widget is faster to drop in, with less graphic control.
A first useful flow, typically pickup points at checkout and an SLS label at packing, ships in three to four weeks. A complete chain with checkGenerateLabel, letterbox returns, international CN23, mapping of the contract product codes and Pudo supervision is closer to six to eight weeks. Duration depends less on REST than on access to the business portal, the products actually open on the contract, and the printer format. We scope the perimeter up front and give a firm estimate before we start.
Both v2 coexist on the same SLS business contract. La Poste recommends v2, which includes all the features of version 1. Choosing REST does not remove field order, product codes or checkGenerateLabel. In SOAP, XML order is contractual: a client that serialises by name rather than by WSDL sequence gets an unmarshalling error, the first bug of a homemade SDK. We settle it during scoping according to your stack, and we freeze one envelope, not both in parallel on the same flow.
Colissimo is density (home, post office, locker, pickup point) with SLS in SOAP and REST, checkGenerateLabel, and documented letterbox returns. Chronopost is express in SOAP only, with rate and delay (quickCostV3, calculateDeliveryTime) before confirmation, and tracking by polling with no public webhook. Both need a contract, neither has native idempotency. You pick Colissimo when checkout must offer the densest network. You pick Chronopost when the delay you sell is express. The two combine behind an internal abstraction.
Because it is not a silent generateLabel. The spec deliberately omits the parcel number, XOP links and pdfUrl. It is the business sandbox: validate without committing. Code that parses the same response shape on both methods breaks in staging, usually the day generateLabel is finally wired. We keep two response types, we only call generateLabel once the order is confirmed, and we store PDF, ZPL and CN23: La Poste does not serve them back as a CDN.
A Colissimo integration project?
Let's talk. 30 minutes to scope your flows, check what SLS and the pickup-point WS actually allow and tell you honestly what is feasible.
Discuss my Colissimo project