WMS courier integration - how it works and what it delivers

Behind the phrase sit four concrete operations the WMS performs instead of a human. One: registering the shipment in the carrier's system via API - the system sends address data, weight, dimensions and service type, and receives a consignment number back. Two: fetching the label - usually ZPL (sent straight to a Zebra or Citizen thermal printer) or PDF. Three: the manifest, i.e. closing the day - the list of all registered parcels handed to the driver at pickup. Four: status tracking - the WMS polls the carrier API and knows whether a parcel is delivered, waiting at a pickup point, or on its way back.

Of those four, the first two save the most labour, but the missing fourth causes the most damage. A shop without status feedback learns that a parcel is stuck only when the customer writes an angry email. At 50 parcels a day you can still manage that manually; at 500 you cannot.

Every carrier has its own API, its own data model and its own quirks. A few patterns worth knowing before scoping the project:

• Parcel locker networks (InPost, DPD Pickup, GLS ParcelShop). A locker or pickup-point shipment needs a valid point identifier chosen by the customer at checkout - the WMS must store it with the order and validate that the point still operates. Size classes are rigid, so the system should enforce dimensions at packing; exceeding the size class is billed to the sender.
• Classic couriers (DPD, GLS, DHL Parcel, UPS, FedEx). Mostly mature REST or SOAP APIs. Watch for consignment numbers allocated from pools (worth fetching in batches at volume), separate flows for cash-on-delivery, and additional-service flags whose combinations are not always legal - the WMS should know those rules, not the packer.
• National postal operators. Contracts and label validation tend to take longer than with private couriers, but for light shipments under 1 kg postal tariffs are often unbeatable - worth the paperwork if small parcels are a meaningful share of your mix.
• Pallet and freight carriers (DHL Freight, Raben, GEIS). Standard in B2B. Pallets add fields parcels do not have: number and type of load carriers, EUR-pallet exchange, delivery appointment booking, tail-lift service.

The practical takeaway: "we integrate with couriers" can mean very different things. Do not ask for a list of logos - ask specifically whether COD, multi-parcel shipments, pickup points, pallets and return labels are covered for the carriers you actually use.

There are two routes. First: the WMS talks to each carrier's API directly, on your contracts and your negotiated rates. Second: the WMS talks to an aggregator (a shipping broker or multi-carrier platform), which talks to the carriers.

• Direct integration pays off once you have negotiated rates of your own - typically above 1,000-2,000 parcels a month. No middleman margin, full control over additional services, but each new carrier is a separate onboarding and a separate contract.
• A broker makes sense at the start and at low volumes: one contract, one price list, a dozen carriers available immediately. You pay through a per-parcel margin and a dependency: when the broker's API is down, you ship with nobody.
• The mixed model is the most common end state: your main carrier (80% of volume) integrated directly on your own contract, the long tail - exotic international lanes, oversized shipments - through a broker.

Without integration, labels are produced in batches: someone sits down in the afternoon, exports orders, pastes them into a portal, prints 200 labels - and then those labels must be matched to 200 sealed boxes. Every match is an opportunity for a mistake, and shipping a parcel with someone else's label is the most expensive error a warehouse can make: two shipments, one return, two unhappy customers.

With integration, print-on-pack becomes the standard: the packer scans the order, the bench scale reports the real weight, the system registers the shipment and the label comes out of the printer at the packing desk exactly when the box is sealed. The label physically cannot end up on another box, because there is only one box at the station. A side benefit: real weight from the scale instead of catalogue weight ends the recurring dispute with carriers about under-declared parcels.

With several carriers on board, someone has to decide which parcel ships with whom. If that someone is the packer, the choice is arbitrary. Mature setups move the decision into a rules engine:

• The customer's choice wins. If the checkout says parcel locker, the case is closed - the system only validates the size class.
• Weight and dimension rules. Under 1 kg goes postal, 1-20 kg standard courier, above 30 kg or a second box - pallet freight. Hard thresholds, no discretion.
• Cost rules. The system knows the price lists and picks the cheapest service that still meets the promised delivery date. Saving EUR 0.30-0.70 per parcel at 5,000 parcels a month is EUR 18,000-42,000 a year.
• Fallback rules. When the main carrier's API stops responding 15 minutes before pickup, traffic switches to the backup. Rarely needed; priceless when needed.

Cash on delivery is still a significant share of e-commerce volume in Central and Eastern Europe. In the integration it means extra fields: COD amount, the bank account for transferring collected funds, sometimes a separate carrier contract. A good WMS checks that the COD amount equals the order value and flags mismatches - the classic manual-process error is a COD amount copied from the neighbouring order. Insurance works the same way: declared value should come from the order value, not from a hard-coded default, because in a damage claim the carrier pays up to the declared amount and not a cent more.

The third overlooked topic is returns. A return label generated from the WMS (emailed to the customer or included in the box) closes the loop: the return arrives with a number the system already knows, so receiving it is one scan instead of detective work titled "what is this box and who sent it".

Status feedback matters in two places. Customer service first: the tracking number flows to the shop and the shipping-confirmation email automatically, and "where is my parcel" tickets drop by tens of percent. Exceptions second: a list of shipments with statuses like "failed delivery attempt", "refused" or "held at depot" should land on a specific person's desk every morning, because each day of delay increases the odds the parcel comes back. With COD it is doubly important - the goods are gone, the money has not arrived, and the customer has often already bought elsewhere.

It also pays to measure carriers: first-attempt delivery rate, average days from dispatch to delivery per region, damage rate. After a quarter of collected data, the annual rate negotiation with the carrier's sales rep looks very different.

A realistic timeline for one carrier, assuming the WMS has a ready-made integration module: carrier contract and test environment access (1-2 weeks - the longest step is usually on the carrier's side), service configuration and sandbox tests (2-4 working days), label validation by the carrier - some operators approve printed samples before production go-live (a few days), then go-live with a week of running alongside the old process. Total: 3-5 weeks for the first carrier; the next ones go faster because the warehouse-side process already exists.

If the WMS has no ready module and the integration is to be custom-built, multiply by three to five. Which is the strongest argument for checking the list of ready integrations before choosing a system, not after.

• A list of ready integrations covering the carriers you use today and those you plan to use within 2 years - broken down by scope (labels, statuses, manifests, returns, COD, multi-parcel, pallets).
• Direct ZPL printing to thermal printers at the packing stations, without opening PDFs. The difference is 2-4 seconds per parcel - half an hour of labour at 500 parcels a day.
• Bench scale support at packing, with real weight passed to the carrier.
• A carrier-selection rules engine configurable without a developer.
• Behaviour during API outages - queueing and retrying registrations instead of blocking the packing station.
• Tracking numbers returned automatically to the shop and the ERP, linked to the order and the dispatch document.

Courier integration is the fastest-returning part of a WMS rollout in e-commerce: the effect shows on day one and is easy to price - hours of manual data entry plus the cost of label mix-ups versus the cost of the module. The order of work is simple: first straighten out the packing process (station, scale, printer), then connect the main carrier, then add routing rules and exception handling. And do it on a system where the integrations are ready, not promised.

Weaver WMS ships with courier integrations (including InPost, DPD, GLS, DHL, FedEx and GEIS) built into the packing process: the shipment is registered the moment the box is closed, the ZPL label prints at the station, tracking numbers flow back to the shop and ERP, and delivery statuses are collected in a single view. Carrier-selection rules are configured in the admin panel, no developer required - which matters, given how often carrier price lists have been changing lately.