Steadfast Courier API Integration: Developer's Guide

Steadfast is one of the most popular couriers among Bangladeshi online sellers, and a big reason is its developer-friendly merchant API. A proper Steadfast API integration lets your shop push orders straight from your database to the courier the moment a customer confirms — no copy-pasting names and phone numbers into a dashboard, no Excel uploads at midnight, and far fewer address typos that turn into failed deliveries.

This guide walks through the integration as a developer would build it: authentication, order creation, status tracking, webhooks, and the error handling that separates a demo from a production system. One note before we start: Steadfast’s exact endpoint paths, field names, and limits change over time and are documented in their official merchant API documentation. Everything below describes the typical flow with illustrative pseudocode — always confirm the specifics against the official docs before you ship.

What a Steadfast API integration actually does

At its core, the integration covers four jobs:

1. Create a consignment — send the recipient’s name, phone, address, COD amount, and your order reference; get back a consignment or tracking ID.
2. Look up status — query the current state of a parcel by its consignment ID or your own invoice reference.
3. Receive status updates — get notified (via webhook or polling) when a parcel moves from pending to picked, in transit, delivered, or returned.
4. Reconcile COD — match delivered parcels against the cash the courier remits to you.

If you only build the first one, you have already eliminated the most error-prone manual step in your fulfilment workflow. The rest is what makes the integration genuinely operational.

Prerequisites

Before writing code, you need:

• A Steadfast merchant account. API access is tied to your merchant profile.
• API credentials. Typically an API key and secret (or similar token pair) issued from the merchant dashboard. Treat these like passwords — environment variables or a secrets manager, never committed to git.
• A stable order model on your side. Your system should have a unique order/invoice ID, a validated Bangladeshi phone number (11 digits, 01XXXXXXXXX), a full delivery address, and a COD amount for every order you intend to push.
• The official API documentation. Request it from Steadfast or find it via your merchant panel. This guide intentionally does not reproduce their endpoint URLs or exact field names.

Authentication: the typical pattern

Most Bangladeshi courier APIs, Steadfast included, use header-based credentials rather than a full OAuth dance. The common pattern looks like this in pseudocode:

# Illustrative only — consult the official Steadfast API docs
# for the real base URL, header names, and field names.

request:
  method: POST
  url: {BASE_URL}/create-order        # placeholder path
  headers:
    Api-Key:    {YOUR_API_KEY}        # placeholder header names
    Secret-Key: {YOUR_SECRET}
    Content-Type: application/json

Practical advice that applies regardless of the exact scheme:

• Keep credentials in configuration, not code, and use separate credentials for staging and production if the courier offers them.
• Wrap the API in a single client class or module so header logic, base URL, retries, and logging live in one place.
• Log every request and response (with credentials redacted). When a parcel dispute happens weeks later, that log is your evidence.

Creating orders

Order creation is the heart of the integration. Conceptually, you send a payload like this:

{
  "invoice": "SHOP-10023",
  "recipient_name": "Customer Name",
  "recipient_phone": "01XXXXXXXXX",
  "recipient_address": "House, Road, Area, District",
  "cod_amount": 1450,
  "note": "Fragile - handle with care"
}

The field names above are illustrative — Steadfast’s documentation defines the exact keys, required fields, and validation rules. The response typically contains a consignment ID and an initial status. Store both against your order record immediately.

Three implementation details matter more than most tutorials admit:

• Idempotency. Networks fail. If your request times out, you must not blindly retry and create a duplicate consignment. Use your invoice number as the unique reference, check whether a consignment already exists for it (many courier APIs let you look up by invoice), and only then retry.
• Validation before submission. Reject bad phone numbers and empty addresses in your own code first. A parcel with a wrong phone number does not fail at the API — it fails three days later as a return, which costs real money.
• Bulk versus single. If you push hundreds of orders at once (an Eid flash sale, for example), check whether the API offers a bulk creation route, and add client-side rate limiting either way. Never assume a specific requests-per-minute figure — test conservatively and read the docs.

Tracking and status lookups

Once a consignment exists, you can query its status by consignment ID or your invoice reference. A typical status lifecycle for a Bangladeshi COD parcel looks like:

pending -> picked up -> in transit / at hub -> out for delivery
        -> delivered | partially delivered | returned | on hold

The exact status codes are courier-specific, so build a mapping table in your code: courier status string on one side, your internal canonical status on the other. That mapping layer is what lets you later add Pathao, RedX, or any other courier without rewriting your order logic — a pattern covered in more depth in our Pathao Courier API guide.

For customer-facing tracking, avoid making a live API call on every page view. Cache the latest known status and refresh it on a schedule or via webhook. A dedicated parcel tracking system does exactly this at scale — one status timeline per parcel, updated as events arrive, viewable by both merchant and end customer.

Webhooks: stop polling, start listening

Polling every parcel every few minutes works at 20 orders a day and collapses at 2,000. The better pattern is a webhook: you expose an HTTPS endpoint, register it with the courier, and they POST a payload to you whenever a parcel’s status changes.

Rules for a production-grade webhook receiver:

• Verify the source. Use whatever signature, token, or secret mechanism the courier documents. Never trust an unauthenticated POST to change financial state (like marking COD as collected).
• Respond fast, process later. Acknowledge with a 200 immediately, queue the payload, and process it asynchronously. Slow webhook handlers get retried and create duplicate events.
• Be idempotent. The same event may arrive twice. Processing it twice must not, for example, double-count a delivered parcel in your COD ledger.
• Fall back to polling. Webhooks get missed. A nightly reconciliation job that re-queries any parcel not in a terminal state catches whatever slipped through.

Delivered-status webhooks feed directly into COD reconciliation: when the courier remits cash, you match remitted amounts against parcels your system already marked delivered. If you’d rather not build that ledger yourself, COD management in Drix handles the matching, discrepancy flags, and merchant settlement automatically.

Error handling and edge cases checklist

Before calling the integration done, make sure you handle:

• Timeouts and 5xx responses with capped, jittered retries.
• Validation errors (4xx) surfaced to your operations team, not silently swallowed.
• Address changes after submission — usually a phone call to the courier; your system should at least flag the mismatch.
• Partial deliveries where the customer accepts some items and returns others, changing the COD amount collected.
• Cancellations — cancelling in your shop must trigger cancellation with the courier before pickup, or you will pay return charges.
• Status mapping gaps — log any unknown status string instead of crashing, and alert so you can extend the mapping.

Where Drix fits in

Everything above assumes you are a merchant integrating outward to Steadfast. There is a second angle worth knowing. Courier companies that run on Drix, a courier management platform built for Bangladesh, expose the same kind of merchant API to their own customers — token auth, order creation, status webhooks, and tracking lookups out of the box. If you operate a courier or plan to launch one, that means you can offer shops the integration experience described in this guide from day one, without building an API platform yourself. Merchants get a self-service merchant panel plus API access, and you get structured order data flowing in instead of phone calls and spreadsheets.

For merchants, the practical takeaway is to ask every courier you work with — not just Steadfast — whether they offer an API. Couriers running Drix will say yes. If you are new to these concepts, start with our plain-language explainer on courier API basics for merchants.

Wrapping up

A Steadfast API integration is a well-trodden path: header-authenticated requests, a create-order call keyed by your invoice number, a status mapping layer, webhooks with polling as a safety net, and COD reconciliation at the end. Budget most of your effort for the unglamorous parts — idempotency, logging, and edge cases — because that is where real-world parcel operations live.

If you run a courier business and want to offer this level of integration to your merchants, or you are a merchant tired of stitching courier spreadsheets together, book a Drix demo and see the full order-to-settlement flow, or review pricing to see which plan fits your parcel volume.