A courier integration can look straightforward until the first peak trading day exposes the gaps: an order is despatched but no label is created, a service is selected incorrectly, or a tracking number reaches the customer before the carrier has accepted the parcel. The result is extra work for the warehouse, customer service teams chasing updates, and Finance trying to reconcile unexpected carrier charges.

This courier integration implementation guide is designed for businesses connecting an ERP, eCommerce platform, warehouse system or marketplace to one or more delivery carriers. The aim is not simply to pass orders to a courier. It is to establish a dependable operational process from order release through to dispatch confirmation, tracking and exception management.

Start with the operational process, not the API

Before selecting endpoints or mapping fields, document how orders move through your business today. A retailer using Shopify and Sage 200 may release paid web orders to the warehouse, while a distributor may create orders in SAP Business One and send picked consignments from a warehouse system. These are different starting points, and they require different integration triggers.

The key question is: at what point is a parcel genuinely ready to be booked? Sending every new order to a courier system is rarely correct. Addresses may still need checking, stock may not be available, an order may be on credit hold, or several items may need consolidating into one consignment.

Agree the process with the people who run it. Warehouse staff need labels at the right point in the pick-pack-despatch flow. Customer service needs reliable tracking and clear visibility of failed bookings. Finance needs shipping charges and carrier invoices that can be checked against the right order or consignment. IT needs ownership of credentials, monitoring and change control.

A useful design exercise is to follow three real orders end to end: a standard UK parcel, an order requiring a premium service, and an international or exception order. This reveals where business rules differ from the assumed ‘standard’ flow.

Define the integration scope and rules

Courier systems do not all provide the same services, formats or tracking events. Likewise, ERP and eCommerce platforms hold information differently. Define the initial scope clearly enough that it can be tested, supported and expanded later.

This normally includes which sales channels are covered, the despatch locations involved, carrier services, countries, package types and required label formats. It should also state whether the integration will create shipments, produce labels, retrieve tracking details, update order status, send delivery notifications, or all of these.

Service selection needs explicit logic

Service selection should be based on agreed rules, rather than an assumption that one service suits every order. The choice may depend on destination, postcode, order value, weight, dimensions, customer-selected delivery method, dangerous goods indicators, signature requirements or cut-off times.

Keep these rules visible and maintainable. For example, an eCommerce delivery option labelled “next working day” may map to a particular courier service only if the order is packed before the relevant cut-off. If the warehouse misses that cut-off, the process needs a defined response rather than silently booking a service that cannot meet the promise made to the customer.

Consider who can override a service and where that decision is recorded. Controlled manual intervention is often sensible for unusual orders, provided it does not create duplicate consignments or break the audit trail.

Get the data model right

Most booking failures are data problems rather than connectivity problems. A courier booking usually needs recipient name, delivery address, postcode, country, contact details, parcel weight, service code and package count. Some services need dimensions, customs details, tax identifiers or commodity descriptions.

Decide which system is the source of truth for each field. Customer address information may originate in Magento or WooCommerce, but the warehouse may enter the final parcel weight and number of cartons. The courier platform returns a consignment number, tracking reference and label, which should then be written back to the systems that need them.

Address validation deserves particular attention. Free-text fields, missing company names, invalid postcodes and non-standard country values can all stop a booking. The integration should validate what it reasonably can before calling the courier, then return actionable messages when the carrier rejects a request. “Shipment failed” is not enough. The warehouse needs to know whether it is a missing telephone number, unsupported postcode or invalid service.

Design for idempotency and recoverable failures

A courier integration must cope with temporary failures. Carrier APIs can be unavailable, network connections can time out, and an order may be reprocessed after a user believes the first attempt failed. Without safeguards, the same parcel can be booked twice.

Use a unique business reference, such as an order number combined with a shipment or package sequence, and record the booking outcome before updating downstream systems. Where the carrier supports an idempotency key or equivalent reference, use it. If a response is uncertain after a timeout, check whether the consignment already exists before submitting another request.

Failures should fall into practical categories. Validation failures need correction by an operational user. Authentication failures need prompt technical attention. Temporary carrier or network failures may be safe to retry under controlled rules. Errors caused by an unavailable service or missing product configuration may require a different courier service or manual review.

Avoid unlimited automated retries. They can create duplicate bookings, fill monitoring queues and obscure the real issue. A clear exception queue, with an owner and escalation path, is more valuable than a process that repeatedly fails in the background.

Build the right status and tracking flow

Despatch confirmation should reflect what has actually happened. If a label has been generated but a parcel has not left the warehouse, marking the sales order as delivered or fully despatched can create confusion. Many businesses use separate statuses for shipment created, packed, manifested or collected, and delivered.

The appropriate approach depends on the systems in use and the level of operational control required. What matters is that customer-facing messages are aligned with reality. A tracking link or tracking number should only be sent when the data is valid and the carrier can recognise the consignment.

Carrier tracking events are not always consistent. One courier may provide detailed scans, while another offers only a small set of milestones. Map events into meaningful internal statuses without pretending that every carrier supplies the same evidence. Retain the original carrier event and timestamp where possible, particularly when customer service teams investigate disputed deliveries.

Returns need similar thought. A forward-shipment integration does not automatically solve returns labels, collection bookings or the movement of returned stock into the warehouse. If returns are in scope, define how the return is authorised, which carrier service is used, and when stock and credit processes are updated.

Test real scenarios before go-live

Testing should go beyond a successful label for one domestic order. Use representative orders and confirm the results across every affected system. The warehouse should test printed labels, packing documents and reprints. Customer service should see the tracking reference and any exception information. Finance should be able to identify the order and service associated with shipment charges.

Include scenarios such as:

• orders with multiple parcels or split fulfilment;
• incomplete or invalid addresses;
• remote-area, international or postcode-restricted deliveries;
• a failed booking followed by a correction and retry;
• cancelled orders and voided labels, where supported;
• duplicate submission attempts; and
• orders released during a carrier outage or after a daily cut-off.

Run a controlled pilot if volumes and operations allow it. This gives the team time to observe how the integration behaves under normal warehouse activity, rather than relying solely on test data. Agree the go-live support arrangements in advance, including who can pause the integration, reprint labels and process a shipment manually if needed.

Monitor the process after launch

The first few weeks should focus on operational evidence: bookings created, labels produced, failed requests, retry volumes, tracking updates and mismatches between despatched orders and carrier consignments. Daily review is often appropriate initially, particularly during a busy trading period.

Monitoring should help people act, not merely produce technical logs. An Operations Manager may need a report of shipments awaiting labels. An IT Manager may need alerts for authentication or connection failures. Finance may need visibility of service changes that affect delivery charges.

Courier accounts, service codes and API credentials change over time. Treat these as controlled configuration, not information held only by one employee or external supplier. Document ownership and review the integration when adding a new warehouse, sales channel, carrier service or international market.

Harmonise Solutions can help UK businesses map the process, design the data flow and implement practical automation between ERP, eCommerce, warehouse and courier systems. The right starting point is usually a short review of your current despatch process and the exceptions your team handles every day.