Connecting Your Online Store to a Courier in Nepal

Most online sellers in Nepal ship by copying orders from their store into a courier’s portal, one at a time. It works to about thirty orders a day, and then it stops working — not because it becomes impossible, but because the person doing it becomes the bottleneck and starts making mistakes.

The errors are predictable: a mistyped phone number, a COD amount that does not match the order, an address pasted from the wrong row. Each one becomes a failed delivery or a reconciliation dispute weeks later.

What an integration actually replaces

A working integration does four things, and each removes a category of manual work:

Push the consignment. When an order is ready to ship, your store sends it to the courier and receives a tracking number back. Nobody retypes an address.

Print the label. The courier returns a label — usually a PDF for a thermal printer — that your packing station prints directly.

Pull the status. Delivery status flows back automatically, updating the order and, ideally, notifying the customer. This alone removes most of your customer service volume.

Reconcile COD. The courier’s settlement is matched against your orders automatically, so you know what you are owed without a spreadsheet.

The fourth is the one sellers underestimate and the one that saves the most time at volume.

What to ask a courier before committing

Not every courier in Nepal has a usable API, and “we have an API” covers a wide range. Ask specifically:

1. Is there documentation? If the answer is “we will send you a sample”, expect a long integration.
2. Is there a sandbox? Testing against production means creating real consignments to find out how errors behave.
3. Can I get a label back, and in what format? A tracking number without a printable label leaves you writing labels by hand.
4. How do status updates reach me — webhook or polling? Webhooks are better; polling works but you need to know the rate limits.
5. Does the COD amount flow both ways? You send what should be collected; they should report what was.
6. Is there a settlement or remittance API? This is what makes automatic reconciliation possible. Many couriers only email a statement, which caps what you can automate.
7. What are the status codes, and what do they mean? In particular, how are failed attempts, reschedules and returns represented.
8. Rate limits, and what happens when I exceed them?

Questions five and six separate couriers who can actually be integrated with from those who can only be sent orders.

Map their statuses to yours

Every courier has its own status vocabulary, and they do not agree with each other. If you ship with more than one, you need a mapping layer: a small, explicit table converting each courier’s codes into your own set.

Keep your own set short and meaningful to a customer: pending pickup, picked up, in transit, out for delivery, delivered, failed attempt, returning, returned. Everything the courier reports maps into one of those, and anything unmapped raises an alert rather than being silently dropped.

Without this, adding a second courier means duplicating status logic everywhere it appears.

Do not couple your store to one courier

Sellers frequently integrate directly against one courier’s API throughout their codebase, then find they need a second one for districts the first does not cover well — and discover the integration is threaded through the order system, the customer emails and the admin screens.

The fix is to define your own internal shipping interface — create shipment, get label, get status, cancel — and implement each courier behind it. Adding a courier then means writing one adapter, not editing the store.

This matters more here than in markets with one dominant carrier, because coverage in Nepal genuinely varies by district and most sellers at volume end up using more than one.

Address data is the real problem

An integration is only as good as what you send it. Nepali addresses are landmark-based and frequently incomplete, and a courier API that requires structured fields will reject or mangle them.

Practical measures at the checkout, which pay for themselves:

• Make the phone number mandatory and validate its format — it is the actual delivery mechanism
• Provide a district or zone selector rather than free text, so routing works
• Give an explicit landmark field, because customers will put it somewhere regardless and it is more useful in its own field
• Store any correction the courier makes back onto the customer record, so the next order is right

Handle the failures

Integrations fail, usually briefly and at the worst moment. Build for it:

• Courier API down at ship time. Queue and retry rather than blocking the order.
• Duplicate consignment created. Your retry succeeded the first time and you did not hear back. Idempotency keys, or check before creating.
• Status webhook arrives for an unknown consignment. Log it, do not crash.
• Order cancelled after the consignment was created. Needs a cancellation path to the courier, and a check that it succeeded.

The sequence worth following

1. Push consignments and get tracking numbers — removes retyping, the biggest single win
2. Label printing — removes the second manual step
3. Status sync and customer notification — removes most support contact
4. COD reconciliation — removes the monthly spreadsheet

Each step is independently useful, which matters because you cannot pause shipping while you build.

We build eCommerce software for sellers in Nepal and the logistics systems on the courier side of the same integration, so we tend to know what both ends can actually do. If order entry is your bottleneck, talk to us.