What “integrating a courier” actually involves
The phrase covers four very different jobs:
- Picking the right rate at checkout, based on size, weight, destination, and service level.
- Generating the waybill and printable label after payment.
- Sending parcel data into the courier's intake (manifest, pickup, status webhooks).
- Showing the customer accurate tracking, end to end.
Most engineering teams think of integration as the second job. The customer notices when the third and fourth fail.
The four data points checkout has to send
The hardest courier integrations are the ones where checkout is missing the data the courier needs. At minimum, your checkout has to capture and pass:
- Parcel size and weight estimates good enough for the rate to be honest.
- A delivery address structured well enough for the courier to geocode it.
- A recipient phone number that actually rings.
- A service-level choice (standard, express, scheduled) that matches what the courier offers in that region.
Skip one of those at checkout and you will pay for it later in failed deliveries, mis-rated parcels, or angry phone calls.
Where these integrations usually break
Three failure modes turn up again and again.
The rate at checkout disagrees with the rate the courier actually charges. The customer paid R85 for shipping. The courier invoiced R142 because the parcel fell into the next size bracket. Someone has to absorb the difference. Send the same data into the rate quote that you will send into the eventual waybill, and this gap closes.
Tracking events arrive out of order, or stop arriving entirely. The courier sends “out for delivery” before “collected”. Your status state machine refuses both. The customer sees nothing. Build the tracking layer to be order-tolerant, and to show the most recent status even when intermediate events are missing.
Address validation runs at the wrong moment. A customer types “Cnr Voortrekker and 14th” at checkout. The courier rejects it on intake. Now the order is paid, the parcel is in your warehouse, and the integration team is on a call. Validate addresses before payment, never after.
A pragmatic order of operations
If you are wiring a courier into a fresh checkout, build in this order.
Start with the rate at checkout. Fail loudly when the courier API is down. Show clear messaging when the destination is unsupported. The rate quote is the contract for everything that follows.
Then waybill creation. Make it idempotent. Log the courier's parcel reference against your order in your own database. Do not depend on retrieving it from the courier later.
Status webhooks come third. Treat them as eventually-consistent. Store every event raw before deriving customer-facing status from them. Reconciling later beats fighting the courier's event ordering live.
Last, the customer-facing tracking page. This page is one of the most-visited on the e-commerce site after launch. Make it fast, mobile-first, and tolerant of missing events.
How this looks with CouriB
CouriB sits on the courier side of the integration, not the e-commerce side. We see the same four breakage points from the other angle. Delivery records, parcels, contacts, and tracking events live on one record, so an integrator can read what the courier knows without writing four separate adapters.
The tracking features page covers the customer-facing side, and the e-commerce use-case page is the right next stop for an e-commerce ops lead. If you want the operator's view of the same flow before you start coding, how CouriB works walks through it from intake to settlement.