API integration for Mondial Relay
We build your Mondial Relay connector
We wire Mondial Relay into your site or OMS: shoppers pick a Parcelshop in your funnel, the label is created at packing, tracking and returns stay inside your platform.
- Senior product team
- carrier connectors in production
- from scoping to monitoring
What does the Mondial Relay API provide and why integrate it into your platform?
Mondial Relay is the densest network of parcel pick-up points in France, Belgium and Spain. Its API lets your application list Parcelshops, create the shipment, generate the label and track the parcel until handover. You integrate it so all of that lives in your product: native checkout with no external widget, labels created from the OMS at packing, returns started from the customer account and wired into support, European Dual Carrier export from the same system.
What Mondial Relay changes in your platform
Native checkout, no external widget
Shoppers pick their Parcelshop in your funnel. Cart weight and size filter eligible points: delivery stays in your journey, not on a third-party site.
Label created from the OMS
When the order moves to packing, your tool generates the Dual Carrier label. The warehouse prints and ships without opening the Mondial Relay portal.
Return wired into support
The customer starts the return from their account: QR or label, drop-off at a Parcelshop, and the support ticket updates as soon as the parcel is accepted.
European export from the same system
Germany, Austria, Spain: one Dual Carrier label from your platform. The partner (Hermes, Correos…) is already on it, with no second logistics process.
What it changes in your product
Engineering in service of a measurable outcome: native checkout, labels from the OMS, returns wired into support.
The funnel no longer jumps to a third-party site
The Parcelshop is chosen in your checkout, filtered by the cart. The shopper stays in your journey through to confirmation.
The warehouse no longer opens the Mondial Relay portal
The OMS creates the Dual Carrier label at packing. The team prints and ships from the tool they already use.
Support sees the return without chasing the customer
The return starts from the account: QR or label, drop-off at a Parcelshop, and the ticket updates when the parcel is accepted.
European export stays in the same system
Germany, Austria, Spain: Dual Carrier carries Mondial Relay and the partner on one label. No second parallel process.
How we ship your Mondial Relay connector
Scoping
Where Mondial Relay enters your product: checkout, packing, support, export. We map the flows, split API1 and API2, and drop any lib that still creates the label over SOAP.
Development
A connector wired into your checkout, OMS and returns. Two distinct API clients, Dual Carrier on the sandbox, idempotency, label stored and never transformed.
Acceptance testing
Real journeys: Parcelshop choice at checkout, label at packing, return from the account. Dual Carrier sandbox, 24L multi-parcel, XOH refused without EDI, tracking capped.
Monitoring
Alerts on Dual Carrier failures, bounded per-parcel tracking, an inspectable dead letter queue. You see an incident before it breaks checkout or packing.
What the API brings to your platform
- Feed checkout with Parcelshops
- 10 to 30 eligible points around the cart, filtered by weight and size. Enough to power your native picker, without exposing the whole network.
- Create the shipment from the OMS
- Dual Carrier creates outbound or return from your packing tool. Collection REL or CCC, delivery 24R, 24L, HOM, LCC, XOH.
- Print from the warehouse
- PDF, ZPL or IPL for the printer already on site. QR for some REL returns: the return journey can live in the customer account.
- Surface tracking in the customer account
- Five stages through to handover, displayable in your product. Bounded pace (4 to 6 calls per parcel per day), then stop at a terminal status.
The vocabulary of the Mondial Relay API
- Dual Carrier
- REST XML API2: one URL, outbound and return, Request/Response XSDs. It is the only supported path to create a label, including Hermes or Correos Express.
- API1 / API2
- Two incompatible secrets. API1: brand code + private MD5 key. API2: Connect Login and Password, « API Version V2.0 » menu. A plugin that asks for both is not redundant.
- 24L
- XL pickup point, the only multi-parcel mode (LD1/LDS). A parcelCount > 1 on 24R is a 100xx error, not a warning.
- XOH
- Express D+1. The Dual Carrier spec requires an EDI action on top of the API. Skipping EDI means an express parcel the network was not told about.
- MD5 hash
- API1 signature: parameters concatenated in the imposed order, often uppercase, private key at the end. One extra character, and every search fails with an opaque code.
- LCC
- Dual Carrier return mode. Paired with the QR (v2.6 change) for some REL returns, it lines Mondial Relay up with current e-commerce expectation.
The real constraints of the Mondial Relay API
Creating the label on API1 is dead
The official April 2025 sentence: API1 shipment-creation methods « are no longer maintained and should not be used ». A plugin audit starts there.
No magic sandbox on API1
Dual Carrier has a -sandbox host. API1 has no equivalent documented here. We never test an API1 label creation just to see: that hits production.
Tracking is not a fleet cron
4 to 6 queries per parcel per day, spread through the day, stop at a terminal status. The presentation says it « should not be called in batch mode ».
COD stopped, label untouchable
Cash on delivery disappeared in v2.7 (February 2023). Resizing or cropping the Dual Carrier PDF breaks the partner flow: print it as-is.
Mondial Relay or Colissimo for your shipments?
Native Parcelshop delivery in your platform on one side, La Poste density (home included) on the other. Both wire into your system, with a different error contract.
| Criterion | Mondial RelayThis page | ColissimoLa Poste density |
|---|---|---|
| Network core | Pickup points / lockers | Home, post office, locker, pickup point |
| Protocols | SOAP API1 + REST API2, two secrets | SOAP and REST v2, one SLS contract |
| Label creation | Dual Carrier only | generateLabel (pre-alert included) |
| Cross-border | Dual Carrier (Hermes, Correos…) | SLS international products, CN23 |
| Tracking | 4 to 6 calls/day/parcel, no batch | Tracking WS behind the business portal |
| Staging | Dual Carrier sandbox, not API1 | Documented SLS test labels |
| The right case | Native Parcelshop in checkout / OMS / support | French checkout, home + pickup points |
The two combine behind an internal abstraction (create, track, cancel) in your platform. A plugin that still creates the Mondial Relay label on API1 is to be replaced, not « updated ». It is a scoping trade-off.
What we measure on a Mondial Relay integration
The other carrier APIs
If the Parcelshop is not the core of your customer journey, these options are worth discussing during scoping.
Mondial RelayWe build your Mondial Relay connectorThis page
ChronopostExpress SOAP: labels, rates, pickups, skybill tracking.
Colissimo & La PosteFrench density: home, pickup points, lockers, letterbox returns.We combine Mondial Relay with
The stack around Mondial Relay when we wire it into a site or an OMS.
Mondial Relay integration: your questions
We wire it into your product touchpoints: Parcelshop picker at checkout, label creation from the OMS, tracking and returns in the customer account or support. Technically, two distinct clients: SOAP API1 for search and tracking, Dual Carrier API2 to create the shipment. We persist the number before marking the order, store PDF or ZPL without transforming it, and cap tracking at 4 to 6 calls per parcel per day. Any lib that still creates the label on API1 is dropped during scoping.
A first useful flow, typically the Parcelshop picker in your checkout and the Dual Carrier label from the OMS, ships in three to four weeks. A complete chain with returns wired into support, 24L multi-parcel, cross-border Dual Carrier, XOH + EDI and tracking in the customer account is closer to six to eight weeks. Duration depends mainly on the touchpoints to wire, Connect access and splitting API1/API2. We scope the perimeter up front and give a firm estimate before we start.
Because the historical API1 shipment-creation methods remain in libs and tutorials. The April 2025 WebServices presentation is explicit: they are no longer maintained and should not be used. Creation goes through Dual Carrier REST. Keep API1 for search and tracking, API2 for the label. Mixing the secrets, or testing an API1 creation « just to see », produces real parcels and real invoices. That is the first filter of an audit.
Mondial Relay is a pickup-point network, with two APIs (SOAP search/tracking, REST Dual Carrier for the label) and cross-border constraints (the partner on the same label). Colissimo is La Poste density, home included, with a single SLS contract in SOAP and REST, checkGenerateLabel, and letterbox returns. Mondial Relay caps tracking at 4 to 6 calls a day. Colissimo documents a tracking WS behind the business portal. You pick Mondial Relay when the pickup point is the product. You pick Colissimo when checkout must also sell La Poste home delivery. The two combine.
No. The official rule is not to call tracking in batch. 4 to 6 queries per shipment per day, spread out, and a finished parcel is not queried again. Beyond that you monopolise the WS and you get cut off. For real volume, the presentation mentions EDI or webhook as alternatives, with no spec in the PDF read here: the exact contract is asked from the account, we do not invent it. Until then, a bounded queue and a stop on terminal status hold production.
A Mondial Relay integration project?
Let's talk. 30 minutes to scope where Mondial Relay enters your platform (checkout, OMS, support) and tell you honestly what is feasible.
Discuss my Mondial Relay project