Real-Time Parcel Status Updates: Webhooks & Notifications Explained

“Bhai, parcel ta kothay?” If you run a courier company in Bangladesh, some version of that question fills your phone lines all day. And if you are a merchant, you are the one asking it — usually on behalf of a customer who asked you first. Real-time parcel status updates exist to end this relay of phone calls: the moment a rider marks a parcel picked up, at hub, out for delivery, or delivered, everyone who cares finds out automatically.

This guide explains how automatic parcel status updates actually work — webhooks, SMS, and push notifications — in language a merchant or courier owner can follow, with just enough technical detail to brief a developer confidently.

The problem: status exists, but nobody hears it

Most courier systems already know where every parcel is. The rider taps “delivered” on a cheap Android phone in Jatrabari, and the system records it within seconds. The gap is distribution: the merchant is refreshing a portal, the customer is calling the merchant, and the merchant is calling your support line — all to learn something your system already knew an hour ago.

There are three ways status information reaches people, and they stack:

1. Pull: someone checks a tracking page or portal. Works, but requires the anxious party to keep checking.
2. Push notifications and SMS: the system proactively messages the customer or merchant when status changes.
3. Webhooks: the system automatically notifies the merchant’s own software — their online store, their order sheet, their CRM — machine to machine.

Most couriers stop at pull. The operational payoff — fewer calls, happier merchants — comes from the other two.

What a webhook is, in plain language

A webhook is a phone call between two computer systems. When something happens in the courier system — a parcel status changes — the courier system immediately sends a small message to a web address the merchant’s system provided in advance. No one refreshes anything; the news arrives on its own.

Compare it to the alternative, called polling: the merchant’s software asking “any update? any update? any update?” every few minutes for every parcel. Polling wastes effort on both sides and still delivers stale news. Webhooks invert it: silence until something happens, then instant notification. If webhooks are the doorbell, polling is walking to the door every five minutes to check whether anyone is standing there.

For a merchant, the practical effect: when the rider marks a COD parcel delivered, the merchant’s WooCommerce or Shopify order can flip to “completed” automatically, the customer can receive an SMS, and the merchant’s payout ledger can update — all within seconds, with no human involved.

The parcel status updates worth broadcasting

A typical parcel lifecycle produces a handful of events that matter to different audiences:

Notice that customers only need two or three messages — flooding them with every internal scan trains them to ignore all of it. Merchants and their systems, meanwhile, want everything, especially failed-attempt reasons, which let them call their customer and rescue the sale before the parcel becomes a return.

What a webhook message looks like

When the event fires, the courier system sends a small structured message — usually JSON — to the merchant’s endpoint URL. An illustrative example of a delivery event:

{
  "event": "parcel.delivered",
  "tracking_id": "DRX-2026-104582",
  "merchant_order_id": "SHOP-8841",
  "status": "delivered",
  "cod_amount": 1450,
  "delivered_at": "2026-08-12T16:42:10+06:00",
  "receiver": "confirmed_by_otp"
}

The merchant’s system reads this and acts: mark the order complete, log the collected COD amount against the expected payout, trigger a thank-you SMS. A failed-delivery event would carry a reason code instead — customer unreachable, address issue, COD refused — which is often the most commercially valuable webhook of all.

Note: this payload is illustrative only, to show the shape of the idea. Field names, event types, signing, and setup steps vary by platform — always consult the official API documentation of the courier software you use (for Drix, the current API docs) rather than building against a blog example.

Reliability: the part your developer will ask about

Webhooks travel over the public internet, and merchant servers in Bangladesh go down, restart, and time out. Three concepts make the system trustworthy, and they are worth knowing even if you never write code:

• Retries. If the merchant’s endpoint does not answer, a good webhook sender waits and tries again, several times, with growing gaps. News is delayed, not lost.
• Idempotency. Because of retries, the same event may arrive twice. The receiving system should recognize a repeated event (by its ID) and ignore the duplicate — otherwise one delivery could be counted twice in the payout ledger.
• Signatures. Each message carries a cryptographic stamp proving it genuinely came from the courier system, so nobody can forge a “delivered” event to a merchant’s endpoint.

When evaluating any courier platform’s webhooks, those are the three questions to ask. If the answers are vague, expect missing updates during exactly the high-volume moments — Eid rush, flash sales — when you need them most.

Notifications for the end customer

Webhooks serve machines; customers need messages. In Bangladesh that means SMS first — it works on every handset, needs no app, and gets read. A sensible, minimal customer sequence:

1. Out for delivery: “Your parcel from [Shop] is out for delivery today. Rider: [name], [phone].” Including the rider’s number cuts failed attempts, because customers call the rider instead of missing them.
2. Delivered: a short confirmation with the COD amount collected — this doubles as fraud protection, since a customer who paid 1,450 taka will notice if the SMS says something else.
3. Failed attempt: what happened and what happens next.

Bangla-language templates, short links to the tracking page, and restraint — two or three messages per parcel — outperform any elaborate scheme. Every automatic message is one fewer inbound call, and inbound calls are the hidden cost center of courier operations.

What this looks like in practice

In Drix, status flows in one unbroken chain: the rider’s tap on a budget Android phone updates parcel tracking instantly, the customer’s SMS fires, and the merchant sees the change in their merchant panel — or receives it straight into their own store via webhook, so their Shopify or WooCommerce orders update themselves. Merchants who integrate stop calling to ask about parcels, because their own system already knows. For the broader picture of how merchants connect to courier APIs — booking parcels programmatically, not just receiving updates — see our primer on courier API basics for merchants.

A getting-started checklist

For courier owners evaluating or enabling webhooks:

• Confirm your platform can send webhooks for at least: picked up, at hub, out for delivery, delivered, failed (with reason), returned.
• Ask about retries, duplicate handling, and signatures — the reliability trio above.
• Set up customer SMS for out-for-delivery and delivered events first; measure the drop in inbound calls.
• Offer webhook integration to your five biggest merchants before announcing it broadly — they generate the most status-check traffic and will surface practical issues early.

For merchants: ask your courier for their API documentation and hand it to your developer, or start with the concepts in how courier tracking systems work so you know what to expect end to end.

Stop being the messenger between your own systems

Every “parcel ta kothay?” call is a status update your system already had but never delivered. Webhooks and notifications close that gap: machines tell machines, customers hear automatically, and your team’s phone time goes to genuine exceptions instead of relaying facts.

Drix ships with real-time tracking, customer notifications, and merchant-facing webhooks as standard parts of the platform, built for the way parcels actually move in Bangladesh. See parcel tracking and the merchant panel in action — book a demo and we will trace one parcel from booking to delivered, with every update arriving on its own.