What a courier API actually gives you

Malaysian couriers offer integration, and the capability is uneven in a specific way. What they do well is operational: create a shipment, print a label, follow a parcel. What is patchier is financial: what this consignment will cost and what it eventually did cost.

That gap is the reason delivery is the least well accounted-for cost in most ecommerce businesses.

What is usually available

Rate quoting. Given origin, destination, weight and dimensions, what will this cost. Available from most, and worth verifying against your actual rate card rather than assuming it reflects your negotiated pricing.

Shipment creation. Book a consignment, receive a consignment note number, get a label to print. This is the core function and it is the one that matters most, because it is what lets the reference be captured automatically — see capturing the consignment note against the order.

Label generation, in a printable format.

Tracking. Status by consignment note, either by polling or by notification. Widely available and the quality of the status detail varies considerably — see tracking statuses and what they do not tell you.

Pickup scheduling, where the courier collects rather than you dropping off.

Cancellation, before collection.

For running a fulfilment operation, that set is sufficient.

What is usually missing

The actual charged amount per consignment. A quote is an estimate. The invoiced amount includes corrections and surcharges applied later, and very few courier APIs expose the final billed figure per parcel in a way you can pull — see courier invoices and how to reconcile them.

Surcharge detail as it is applied. You discover a weight correction on the invoice, not through the integration.

Invoice data at all. Usually a document by email or a portal download rather than a queryable source.

Cash-on-delivery remittance detail. Which collections make up which remittance, which is its own reconciliation — see cash on delivery remittance and your cash.

Claim status, for lost or damaged parcels.

So the integration handles the parcel and stops short of the money. That asymmetry is worth knowing before scoping, because it means the financial side of delivery is a document-processing problem rather than an API problem.

The practical design

Given that split, the workable architecture is straightforward.

Use the API for everything operational. Quote, book, label, track, and capture the consignment note against the order automatically. This is where the integration earns its cost.

Store the expected charge from the quote or your rate card at the moment of booking. It is your baseline for checking the invoice later.

Process invoices separately, matching each line to a recorded consignment. Whether the invoice arrives as a file, a portal export or a document depends on the courier, and all three are workable.

Attribute the difference between expected and invoiced to the order that caused it.

That gives you delivery cost at order level without depending on courier APIs to provide something most of them do not.

Working with several couriers

Most Malaysian stores of any size use more than one, because no single carrier is best across every destination and weight — see choosing couriers by destination.

The consequence is several integrations, each different.

Different data shapes. Fields, status vocabularies and identifier formats vary, so a normalisation layer is required — one internal representation of a shipment, populated from whichever courier handled it.

Different reliability. Some are stable; some have quiet periods and undocumented changes. Build for the weakest rather than the best.

Different invoice formats, which is where most of the ongoing effort actually sits.

This is what makes courier aggregators attractive: one integration, one invoice, several carriers behind it. It is also what they charge for, and there are trade-offs in rates and in control — see aggregators versus direct courier accounts.

What to ask a courier before integrating

Six questions, and the answers vary more than you would expect between providers.

Does the rate quote reflect my negotiated rates or public ones. Is the consignment note returned at creation, or assigned later. How is tracking delivered — polling, notifications, or both. Is the final charged amount per consignment available anywhere programmatically. What format is the invoice, and can it be delivered rather than downloaded. Is there a test environment.

The fourth question is the one that matters most for accounting and the one most often answered vaguely. A clear no is more useful than an unclear yes, because it settles the design: the invoice is the source of truth for cost, and everything is built around processing it properly.

Common questions

What do Malaysian courier APIs typically support?

Rate quoting, shipment creation returning a consignment note number, label generation, tracking by polling or notification, pickup scheduling and cancellation before collection. That set is sufficient to run a fulfilment operation and to capture the consignment reference against the order automatically.

What is usually missing from a courier API?

The financial side. The actual charged amount per consignment including corrections and surcharges applied after dispatch, surcharge detail as it is applied, invoice data in queryable form, cash-on-delivery remittance breakdowns, and claim status. Delivery cost is therefore a document-processing problem rather than an API problem.

How should delivery cost be captured given that gap?

Use the API operationally to quote, book, label, track and record the consignment against the order, storing the expected charge at booking as a baseline. Then process the invoice separately, matching each line to a recorded consignment and attributing any difference between expected and invoiced to the order that caused it.

What changes when you use more than one courier?

Each integration has different field shapes, status vocabularies and identifier formats, so an internal normalised representation of a shipment is needed regardless of which carrier handled it. Reliability differs, so the design should assume the weakest rather than the best, and the differing invoice formats are where most ongoing effort sits.

Related: capturing the consignment note against the order · aggregators versus direct courier accounts · what APIs you need for Shopify reconciliation