Courier APIs Explained for Non-Developers: What Merchants Should Know

If you sell online in Bangladesh, you have probably heard a developer, a courier salesperson, or another seller mention a courier API — usually in a sentence like “we push orders through the API, we never type them in.” If you nodded along without fully following, this article is for you. No code background needed: by the end you will know what a courier API actually is, what it does for your business, what the common terms mean, and exactly what questions to ask your courier.

Here is the short version up front. A courier API is a way for two software systems — your online shop and your courier’s system — to talk to each other directly, without a human copying information between them. Every order your shop receives can travel to the courier automatically, and every parcel status update can travel back, in seconds, with no typing and no typos.

What a courier API replaces

Think about how orders reach your courier today. In most Bangladeshi shops it is one of these:

• Someone reads each order from Facebook, WooCommerce, or Shopify and types the customer’s name, phone, address, and COD amount into the courier’s website.
• Someone fills an Excel sheet all day and uploads it to the courier in the evening.
• Someone messages the details to a courier agent on WhatsApp.

All three share the same problems: they cost staff time, they introduce typos (one wrong digit in a phone number usually means a failed delivery and a return charge), and they create a delay between “customer ordered” and “courier knows about it.”

An API removes the human bridge. Your shop’s software sends the order details to the courier’s software directly. Ten orders or a thousand — same effort: none.

The four things a courier API does

Almost every courier API in Bangladesh — Pathao’s, Steadfast’s, or the API of any courier running the Drix platform — covers the same four jobs:

1. Create an order (the “booking”)

Your shop sends the delivery details — recipient name, phone, address, and the COD amount to collect — and the courier’s system instantly answers with a tracking number (often called a consignment ID). That ID is the parcel’s identity for the rest of its life.

2. Check status (tracking lookup)

Your shop can ask, at any time, “where is consignment 12345?” and get back the current status: picked up, at hub, out for delivery, delivered, or returned. This is the same information behind any tracking page — if you want the full picture of how that works, read our explainer on how courier tracking systems work.

3. Push updates to you (webhooks)

Instead of your system repeatedly asking “any news?”, the courier’s system can notify yours the moment something changes — parcel delivered, parcel returned, delivery failed. This push mechanism is called a webhook, and it is what makes automatic customer SMS updates and real-time dashboards possible. We cover it in plain language in webhook parcel status updates explained.

4. Support reconciliation

Because every order, status, and COD amount is recorded as structured data, matching the courier’s weekly cash settlement against your delivered parcels becomes arithmetic instead of archaeology. Software can do it for you — this is exactly what a COD management system automates.

The jargon, translated

When your developer or courier talks about the integration, these are the words they will use:

• API (Application Programming Interface). A menu of requests one system can make to another. “Create order”, “check status” — each is an item on the menu.
• Endpoint. The specific address for one of those menu items. The “create order” endpoint is where your system sends new parcels.
• API key / token. A password for software. The courier issues it to you; whoever holds it can create orders in your name — so it must be kept secret, like a bank PIN.
• Request and response. Your system asks (request), the courier’s system answers (response). The answer to “create order” contains your consignment ID.
• Webhook. The reverse direction: the courier’s system calls yours when something happens, so you never have to keep checking.
• JSON. The text format the two systems use to exchange data. Human-readable, if you squint:

{
  "recipient_name": "Rahim Uddin",
  "recipient_phone": "01XXXXXXXXX",
  "cod_amount": 1250
}

(That snippet is a simplified illustration — every courier’s official API documentation defines its own exact format and field names.)

• Documentation (“the docs”). The instruction manual the courier gives your developer, listing every endpoint and field. No docs, no integration — it is the first thing to ask for.

What integration actually costs

You do not need a software team. Realistic options, cheapest first:

• Ready-made plugins. If your shop runs WooCommerce or Shopify, plugins or apps exist for the popular couriers. Setup is hours, not weeks.
• A freelance developer. A standard order-push integration against a documented courier API is a small, well-understood job for any competent web developer in Bangladesh.
• Your courier’s own tools. Couriers running Drix give merchants both a ready merchant panel — a dashboard where you or your staff manage parcels with zero code — and a documented API for when you are ready to automate fully. You can start with the panel today and integrate later without switching couriers.

What you are buying, in business terms: staff hours back, fewer failed deliveries from typos, instant tracking answers for customers, and clean numbers at settlement time. For a shop doing 30+ orders a day, the integration typically pays for itself within weeks in saved time and reduced returns alone.

Questions to ask your courier before integrating

Print this list and ask your courier’s account manager:

1. Do you have a merchant API, and can I see the documentation? If the answer is vague, integration will be painful or impossible.
2. How do I get API credentials, and can I test before going live? A test or sandbox mode saves your developer real parcels’ worth of mistakes.
3. Do you support webhooks for status updates? Without them, your system must repeatedly poll for changes — workable, but slower and clunkier.
4. What statuses will I receive? You want granularity: picked, at hub, out for delivery, delivered, partial, returned — not just “in progress” and “done”.
5. How do API orders appear in settlement reports? The whole point is matching parcels to money; ask to see a sample statement.
6. What happens when your API changes? You want advance notice, not a broken shop on a Friday night.

A courier that answers all six confidently is a courier that takes merchants seriously. Many of the couriers with the best answers run on Drix — because the platform gives them the API, webhooks, tracking pages, and reports as standard equipment, they can offer integrations that competitors still handling orders over WhatsApp simply cannot.

The bottom line

A courier API is not a developer luxury — it is the difference between a shop where order handoff, tracking, and cash matching run themselves, and a shop where a person retypes phone numbers all day. You now know what it does, what the words mean, and what to demand from your courier.

If your current courier cannot offer this, that is useful information too. To see what a fully integrated courier experience looks like — merchant panel, API, live tracking, and automated COD settlement in one system — book a Drix demo. Bring your toughest question from the list above.