"Just connect the courier" is one of the most underestimated line items in an e-commerce project brief. Done well, an order gets booked with the courier the moment it's confirmed, the customer gets automatic tracking updates, and cash-on-delivery money reconciles itself against a settlement report every week. Done poorly, someone in operations is manually copying order details into four different courier dashboards every morning.
This guide covers how courier API integration works in Bangladesh — Pathao, Steadfast, RedX, and Paperfly specifically — including the COD reconciliation and multi-courier failover patterns that separate a fulfillment process that scales from one that collapses the moment order volume grows.
The core decision: integrate one courier for simplicity, or build a courier-agnostic layer that can book with a second courier automatically when the first can't fulfill an order.
How Courier API Integration Actually Works
A working integration handles three separate flows, not one: creating the parcel booking the moment an order is confirmed, receiving status updates as the parcel moves through pickup, transit, and delivery (or return), and reconciling collected COD cash against what the courier actually remits. Most integration problems trace back to only the first flow being built properly and the other two being left as a manual, error-prone afterthought.
Order Creation
When an order is confirmed — whether paid online via a gateway covered in our payment gateway integration guide or placed as cash-on-delivery — the system calls the courier's API with the customer's address, phone number, parcel weight, and COD amount (if applicable), and receives back a consignment or tracking ID that gets stored against the order.
Status Updates
As the parcel moves through the courier's network, the courier sends status changes back — picked up, in transit, out for delivery, delivered, or returned. This should update the customer-facing order status automatically, without a support agent needing to check the courier's own tracking page and relay it manually.
COD Reconciliation
The courier collects cash on delivery, holds it, and remits it to the merchant on a settlement cycle — commonly weekly — minus their delivery charge. Every delivered COD order needs to be checked against that settlement report so a mismatch (a courier that reports a parcel as delivered but never remits the cash) gets caught within days, not discovered during a year-end audit.
Comparing Bangladesh's Major Courier APIs
| Courier | Strength | Status Updates | Best For |
|---|---|---|---|
| Pathao Courier | Strong Dhaka metro coverage and same-day delivery options | Delivery status webhooks with order and payment status fields | Fast-moving Dhaka-centric stores needing same-day options |
| Steadfast Courier | Wide nationwide coverage including remote upazilas | Status webhook plus a polling API for reconciliation | Stores shipping nationwide, not just to major cities |
| RedX | Competitive COD settlement cycle and hub-based tracking | Webhook with detailed hub-transit status codes | Stores that want granular in-transit visibility |
| Paperfly | Established B2B and bulk-order fulfillment relationships | Status polling API, webhook support varies by merchant tier | Higher-volume merchants with negotiated bulk contracts |
None of these share a common API standard — authentication, payload format, and status codes all differ per courier, which is why a multi-courier setup is built as separate adapters behind one internal order interface, not a single shared integration.
Why Multi-Courier Failover Matters
No single courier has complete, reliable coverage of every upazila in Bangladesh, and any courier can have a service disruption. A store that only integrates one courier has no automatic fallback when that courier rejects a pickup, has no coverage in a customer's area, or is simply down — the order sits unfulfilled until someone notices and re-books it by hand.
Building this properly means giving every order a courier-agnostic internal status (confirmed, booked, in transit, delivered, returned) separate from whichever courier-specific status code arrives, so a rejection from one courier can trigger an automatic re-booking attempt with a second courier without a human in the loop.
What a Reliable Integration Requires
Poll as a Backstop, Not Just Webhooks
Webhooks get dropped, delayed, or never sent during a courier outage. A reliable integration also polls the courier's status API on a schedule, so no order is left stuck on a stale status indefinitely.
A Courier-Agnostic Order Status
Track an internal status separate from each courier's own status codes, so switching couriers — or adding a second one — doesn't require rewriting how order status is displayed to customers.
Automated COD Settlement Matching
Match every delivered COD order against the courier's settlement report automatically, flagging mismatches for a human to review instead of trusting the remittance blindly.
Address Validation Before Booking
Validate phone number format and flag suspiciously incomplete addresses before booking, since a courier rejecting a parcel mid-transit for a bad address costs more in delay and customer frustration than catching it at checkout.
Common Integration Mistakes
- Relying only on webhooks for status updates with no polling backstop, so an order silently stops updating the moment a webhook is missed.
- Treating each courier's status codes as the source of truth shown to customers, making it painful to add a second courier later.
- No automated COD settlement reconciliation, so remittance mismatches go unnoticed for weeks or months.
- No fallback courier configured, so a single rejected booking becomes a manual fire-drill instead of an automatic re-route.
Frequently Asked Questions
Most growing stores integrate at least two — a primary courier for standard coverage and a secondary one as automatic failover when the first rejects a pickup or has no coverage in a customer's area. A single-courier setup is simpler to build but has no fallback when that courier has a service disruption.
The courier collects cash from the customer on delivery, then remits it to the merchant on a settlement cycle — typically weekly — minus their delivery fee. The merchant's system needs to reconcile every delivered order against the courier's settlement report, not assume the full order amount arrives automatically.
This is the single most common integration failure. Webhooks over the public internet can be dropped, retried out of order, or never sent at all if the courier's system has an outage. A reliable integration polls the courier's order-status API on a schedule as a backstop, so an order never gets stuck showing "Processing" for days after it was actually delivered or returned.
Yes, if the integration is built with that in mind from the start — the order needs a courier-agnostic internal status alongside each courier's own status codes, so a rejection from Courier A can trigger an automatic re-booking attempt with Courier B without a human having to notice and re-enter the order by hand.
No. Pathao, Steadfast, RedX, and Paperfly each have their own authentication method, order payload format, and status webhook structure — there is no shared standard. An integration built against one courier's API cannot be pointed at another without a real rewrite of that adapter, which is why multi-courier setups are built as separate adapters behind one internal order interface, not one shared integration.
Fulfillment Automation Pays for Itself Fast
The gap between a store manually re-typing orders into courier dashboards and one where confirmed orders book themselves is usually a few weeks of integration work — and it's the kind of fix that keeps paying back every single day fulfillment volume grows, covered further in our guide on starting an e-commerce business in Bangladesh.
Manually booking couriers every morning? BengalTech Solutions builds e-commerce websites with courier and COD reconciliation automation from day one. Tell us about your fulfillment process.