Integration of a carrier API
The label is a business object, not a portal PDF
We integrate Chronopost, Colissimo or Mondial Relay into order preparation. Out-of-order tracking, pickup points that expire, labels never duplicated: the carrier contract comes before the API.
- Carrier connectors in production
- idempotent label
- tracking scoped
What is a carrier API and when should you have it integrated?
A carrier API lets your application create a shipment, get a label, track the parcel and, depending on the network, offer a pickup point. Carrier portals kept by hand hold for a while. You have the connector built when the label must come out at order validation, when delivery status must flow back into the customer file, or when pickup-point choice is part of the funnel. Without that, logistics and product ignore each other, and support answers “we do not know where the parcel is”.
What leaves without a label or tracking
The carrier ships. Until the address stops being retyped in their portal, the customer has no tracking and the chosen pickup point is no longer the right one.
We recopy addresses into the carrier portal
The order pushes the shipment. The label comes out, tracking comes back. No more double entry in the morning in logistics.
The customer asks for tracking, we have nothing
Tracking events feed the file. Support reads the same status as the carrier.
The pickup point chosen is no longer right at shipping
The pickup point is order data, revalidated at shipping. A closed point is visible before the label.
A duplicate label, one parcel too many
Idempotency on shipment creation. A replay does not produce a second label, nor a second pickup.
What each carrier API actually involves
Chronopost
ExpressAn express network. No invented routes: the integration is judged on shipment creation, the label, tracking. Scoping fixes products (home, pickup point), carrier accounts and anomaly handling. A Chronopost web portal is not a connector.
- Label at validation
- Tracking in the file
- Anomalies handled, not ignored
Colissimo & La Poste
La PosteColissimo and more broadly La Poste. Useful as soon as volume goes through that network. Scoping fixes the contract, options (signature, pickup point) and status return. “la poste api” is in the cluster: we stay on the shipping need, without inventing a group API catalogue.
- Order to label
- Tracking for customer and support
- Options scoped with the contract
Mondial Relay
Pickup pointsThe pickup-point case: choosing the point is part of the funnel, the point identifier travels through to shipping. A closed or out-of-area point is handled before the label. No detailed sheet: scoping confirms access and the selection journey.
- Pickup point chosen in the funnel
- Identifier carried through to the label
- Point closure handled
Four flows the warehouse and CS recognise
Label at preparation
A ready order creates the label once. A double click does not create an extra parcel.
Tracking in the customer account
Events arrive out of order. The status shown is recomputed, not pasted.
Pickup point chosen in the tunnel
The relay has a lifetime. At ship time we re-check, we do not reuse a dead id.
Anomaly that blocks the file
Return, damage, saturated relay: the logistics file stops. CS answers with a status, not a guess.
Warehouse, CS, customer, finance: the multi-carrier layer
We do not “plug Chronopost in”. We set a carrier layer and label idempotency.
The warehouse stops retyping addresses
Preparation prints. The carrier portal leaves the daily ritual.
CS answers with a status
Tracking sits in the file. Fewer “we'll ask the carrier”.
The customer gets the relay they chose
We re-check at ship time. A closed pickup point is a case, not a surprise on the round.
Finance reads the shipping cost
Weight, offer, surcharge: the connector brings them back. The portal is no longer the only price truth.
What we have shipped, and why it transfers here
The method a carrier API forces
Carrier contract
Contract, offer codes, sandbox, who talks to the carrier sales rep.
Deliverable: confirmed API accessMulti-carrier abstraction
Internal shipment object, mapping per carrier, shared fields.
Deliverable: shipment modelOut-of-order tracking
Dedup, state machine, late events.
Deliverable: tracking machineRelay validity
Relay TTL, re-check, fallback offer.
Deliverable: relay ruleWhat nobody tells you before you sign
The carrier contract precedes the API
Without an account and an offer, there is no label. Scoping confirms real access and the sandbox, not public docs. Starting the connector before the contract is coding into the void.
The label is a business object, not a PDF
Without idempotency, a retry creates a second shipment. The tracking number is the business key, not the PDF. The label is stored as an object, with its status, not as a throwaway file.
Tracking arrives out of order
A “delivered” status can precede “out for delivery” depending on the network. We deduplicate and reread state, we do not assume a sequence.
The pickup point has a lifetime
A point chosen 10 days earlier may be closed at ship time. Re-checking is not optional: TTL, fallback offer, and a business case if the relay has vanished.
What we measure on a carrier project
Carrier API integration: your questions
Three steps. First freeze the label moment (validation, preparation, pickup) and the products (home, pickup point, express). Then build an idempotent connector, which creates the shipment, stores tracking and handles events. Finally test incomplete address, closed pickup point, anomaly. The difficulty is not getting a PDF, it is not shipping twice.
A label plus tracking costs far less than a pickup-point funnel, multi-network, with customer notifications. The carrier contract and anomaly cases weigh as much as the code. We scope the perimeter up front and give a firm estimate.
Yes, and it is common: express on one side, pickup points on the other. We put an internal shipment model, independent of the network, before it reaches logistics. Without that layer, each carrier duplicates the file and support.
The category covers shipping, not a WMS. Stock stays in your ERP or business tool. The carrier connector consumes an order to ship, it does not compute inventory. If stock is the topic, see the ERP page.
By carrying the point identifier from the funnel, revalidating it at shipping, and treating closure as a business exception (new choice, delay, contact). A pickup point “by guesswork” at label time is the first cause of parcels on hold.
Is the carrier contract already signed?
30 minutes to review accounts, sandbox, multi-carrier, and what a duplicate label would cost in the warehouse.
Discuss my carrier project