A Note on What This Is

Details of the businesses involved are withheld: this work was delivered under employment, and the systems and clients are not ZaidanLab's to claim. What follows describes a real pattern of engineering work, with names, data and internal details left out.

The Problem Pattern

In a single-store shop, every parcel leaves from one address. In a marketplace, each seller ships from their own origin, so one customer order can become several shipments with different pickup points, couriers and prices. A shipping integration that works for one origin can look fine in a demo and then fail on the first real multi-seller order.

Rates and Labels Are Different Problems

Getting a rate quote and issuing a booking with a printable label are separate calls with separate rules. A courier that returns a valid rate does not always accept a booking in a test environment, and test environments often behave differently per courier. The practical lesson is to verify the whole path (quote, booking, label) for each courier you intend to offer, and to allow-list couriers by what actually completes end to end, not by what appears in a rate list.

Origin Data Is a Data-Quality Problem

Most failed bookings trace back to incomplete seller data: a missing area code, an unmapped district, a postcode that does not match the courier's coverage. Fixing this is operational as much as technical. It needs validation at seller onboarding, clear errors that name the missing field, and a way to correct data without a deployment.

Data That Disappears Between Quote and Order

Platforms often copy address data from the quote stage to the order stage through a field mapping. Custom fields can be dropped silently if the copy step has no real setter for them, so the integration sees an empty value only at booking time. The fix is an explicit step that carries the field across and a test that asserts the value on the saved order, not just on the quote.

Making Failures Diagnosable

Courier errors are rarely self-explanatory. A dedicated log channel for the shipping integration, with request context but without credentials or customer data, turns a vague booking failure into a one-minute diagnosis. It is worth setting up before launch, not after the first incident.

Why This Matters

The same discipline applies to any third-party integration: treat the provider's sandbox as a hint rather than proof, own the data quality on your side, and make failures visible. That is the unglamorous work that decides whether a marketplace can fulfil orders reliably.