In most shipping-heavy companies we look at from the inside, the warehouse always has two tabs open — the ERP panel and the courier panel. Someone retypes the delivery address by hand into the label, sometimes with a typo, sometimes pulling a phone number from an order a year old. There's a better way to do this once and get a dozen hours a week back.
It sounds trivial, but this is one of those places in SMEs where money is lying on the floor. The order is in the ERP. The billing address is in the ERP. The parcel weight from the product card is in the ERP. Meanwhile the packer opens the DPD panel, retypes everything by hand, prints the label, sticks it on, goes back to the ERP and ticks "shipped". Five minutes per parcel. Times 150 parcels a day. Times 21 working days. Do the math.
What "courier integration" actually means
Integration isn't magic. It's a few concrete things that stop being done by hand:
- Generating the waybill from the order — one click, with sender, recipient, weight, COD and insurance auto-filled.
- Printing the label automatically on the warehouse printer (usually a Zebra), without opening the courier panel.
- Writing the tracking number back to the order in the ERP, so it's clear what shipped through whom.
- Updating order status based on webhooks from the courier ("out for delivery", "delivered", "return").
- COD handling — the amount flows to the courier from the invoice, and after settlement comes back as "paid" in the ERP.
- Return label generated alongside the outbound waybill, if your policy requires it.
Every one of these can be coded against the courier's API. DPD has an API. InPost has an API (a pretty good one). GLS has one. DHL has one. Even Poczta Polska has one. The question isn't "can it be done" — it's "who has time to wire it into your specific ERP".
What it looks like at one of our clients
Concretely. A 30-person e-commerce company selling small home appliances, warehouse near Łódź. They ship about 180 parcels a day via DPD and InPost — roughly a 60/40 split. The ERP is Comarch Optima, the storefront runs on PrestaShop, orders flow into Optima through a stock plugin.
Before integration it looked like this. Two warehouse staff, taking turns, packed and pasted labels by hand. Each label meant opening the DPD or InPost panel, retyping the address from the order, entering the weight (guessed, because the product weight was only filled in for half the catalogue in Optima), picking a service, printing, sticking. Four minutes per parcel, plus errors. Over an hour a day went on fixing labels returned with the wrong address — 6–8 complaints a week from typos alone.
After integrating Comarch Optima with the DPD API and the InPost API (via custom middleware that bridges both channels), it looks like this. The packer scans a barcode on the release document, the system picks the courier (per the preference on the order), generates the waybill and prints the label on the Zebra. Time: 5 seconds instead of 4 minutes. Wrong-address complaints dropped to zero, because the data comes straight from the customer record. The warehouse got back about 18 hours a week — enough that one weekend shift disappeared from the rota.
Project cost: three months of work on our side. Production-ready in week seven, another five weeks polishing edge cases (COD, palletised parcels, parcel locker delivery with the specific locker picked at checkout). Payback in under 7 months counting only the saved headcount — not counting the complaints avoided and the customer goodwill.
What not to buy
There are plenty of "ready integrators" on the market — Baselinker, Apilo, ErliExpress. They make sense if you sell across 10 channels and ship 30 parcels a day. A 200–500 PLN monthly subscription pays for itself then.
It stops paying for itself if:
- You ship over 100 parcels a day and the shipping subscription alone tops 2,000 PLN.
- You have your own ERP and don't want orders living "next to" it in someone else's tool.
- You have non-standard logic (consolidating parcels, shipping from 3 warehouses, custom COD rules).
- You care that the tracking number comes back to the specific document in the ERP, not to an aggregator in the middle.
A bespoke API integration is then cheaper on a yearly basis and much more flexible. Typical project cost is 25–60 thousand PLN net, depending on how many couriers and how many edge cases you need. At 150+ parcels a day it pays back in under a year.
What to ask the vendor doing the integration
If someone shows up offering to integrate a courier with your ERP, ask four questions:
- Are you using the courier's official API, or scraping the panel? Scraping "works" until the next layout change. API only.
- What happens if the courier's API goes down for 2 hours? A good integrator has a retry queue and doesn't block order entry in the ERP.
- Who maintains the integration after go-live? Couriers ship API updates several times a year. Either you have your own developer, or you have a maintenance contract.
- Do we get the source code and the documentation? If the answer is "that's our know-how" — walk away. You have a right to what you paid for.
What next
Courier-to-ERP integration is one of the fastest-paying-back projects in a typical shipping SME. It's not a "digital transformation" and it's not "AI in logistics". It's just plugging the hole through which a dozen man-hours leak every day.
If you ship over 50 parcels a day and someone is still retyping addresses by hand from the ERP into the DPD panel — worth talking. Half an hour of conversation is usually enough to estimate whether your case is a 25k or a 60k project and how many months to payback.
Courier integration isn't technology or AI. It's just plugging the hole through which a dozen man-hours leak every day.