Connecting your courier or delivery partner
Three Pakistani couriers connect directly and report delivered and returning parcels. For the rest, tracking comes from your fulfilment.
A courier reaches your WhatsApp flows in one of two ways: connected directly, or through your store's fulfilment. Leopards Courier, PostEx and M&P connect directly — ConvoFly reads each parcel's status from the courier and can start a flow when it changes. Every other courier works through the fulfilment: when you mark an order as fulfilled and enter the tracking information, that information becomes available to a flow.
| Courier | How it connects |
|---|---|
| Leopards Courier, PostEx, M&P | Directly — statuses read from the courier once a day |
| TCS | Directly, in beta — with the Client ID and Client Secret TCS issues |
| Trax | Direct connection coming soon; through the fulfilment for now |
| Any other courier | Through your store's fulfilment |
Both routes start the same way — a tracking number on the fulfilment — so everything below about entering it applies to both. The direct connection is covered first; the rest of this guide is about what the fulfilment gives you on its own.
Leopards, PostEx and M&P: connected directly
Connect one of these in Settings → Courier integrations with the API keys from your courier's merchant portal. From then on, every day at 5am, ConvoFly asks the courier for the status of parcels shipped in the last 15 days (up to 300 per run — both numbers can be changed in the Scheduler). When a parcel's status changes, a Courier status changed event starts your flow, carrying the courier's own wording, the tracking number and the COD amount.
That closes the delivery gap described below for these three couriers: you learn that a parcel was delivered, or that delivery failed and it is on its way back, without relying on the store to be told. The ready-made flow asks delivered customers for a score and offers customers whose parcel is returning a choice to have it sent again or cancel.
Two limits to know. ConvoFly only reads statuses — it never books, cancels or edits a shipment, so booking stays in your courier's portal or courier app. And because the check runs once a day, it suits "delivered" and "coming back", not a real-time "out for delivery" alert. The full setup, statuses and message wording are in WhatsApp tracking updates for Leopards, PostEx and M&P.
Through your store's fulfilment
For every other courier, understanding where the tracking details come from explains both why shipping messages usually work and why they sometimes arrive with a blank where the tracking number should be.
What arrives, and from where
| Detail | Comes from | Reliable? |
|---|---|---|
| Tracking number | What you entered on the fulfilment | Only if you entered it |
| Tracking link | The same | Only if you entered it |
| Courier name | The carrier recorded on the fulfilment | Usually |
| "Shipped" happening at all | The fulfilment itself | Yes |
| "Delivered" happening | Whether your carrier reports it back | Not guaranteed (unless the courier is connected directly) |
Read the first two rows carefully, because they are the cause of nearly every broken shipping message. Nothing looks the tracking number up for you — it is the value somebody typed, and a fulfilment created in a hurry with no tracking details produces a message with nothing to say.
The delivery gap
The bottom row is the one to know before you promise anybody a delivery notification. For a courier that is not connected directly, whether a "delivered" event ever happens depends on your carrier reporting the delivery back to your store, and plenty of carriers in plenty of markets do not.
So a flow built on delivery — a review request, a "how did it go" follow-up — may simply never run, and it will look broken when it is actually waiting for something that will not arrive.
Two honest workarounds:
- Time it from dispatch instead. Wait a number of days after shipping that reflects your usual delivery time, then send. Less precise and it always runs.
- Have your own system tell us. If you know when things are delivered — from a courier portal, a driver app, a spreadsheet somebody updates — that knowledge can start a flow.
Most stores should start with the first. It is one delay block and it works everywhere.
Build the message so an empty field cannot ruin it
The single most useful habit here. Before any message that includes a tracking number, add a condition that stops the flow when the value is missing.
Without it, a customer receives "Your order has shipped — track it here:" with nothing after the colon, which is worse than receiving nothing. With it, the run stops and your team can handle that order by hand.
A better version sends two different messages: one with tracking details, and a plainer one for fulfilments that have none. The full flow is in shipping and tracking updates on WhatsApp.
Saving the courier name
Worth doing even if you never message it. Recording which courier carried an order onto the customer's record means your team can answer "who delivered it?" without opening the store, and it lets you notice that one carrier generates most of your complaints.
That is a contact field rather than a tag, because it is a value rather than a group — the distinction is in tagging and segmenting customers automatically.
If another courier has an API
Some couriers that are not connected directly still have an API, and then two things become possible that are not otherwise.
Their system can start a flow. When a parcel is delivered, or a delivery attempt fails, their event can trigger a WhatsApp message. This is the proper fix for the delivery gap above, and it needs one small piece of work by whoever handles that connection.
A flow can ask them something. Mid-conversation, a flow can call their tracking endpoint and tell the customer where the parcel is right now, rather than sending them to a website. That is the "where is my order" answer customers actually want.
Neither is a connector you switch on; both are the general mechanism described in connecting a CRM or ERP.
Failed deliveries are the expensive case
A parcel that could not be delivered is a cost you have already paid and are about to pay again. Catching it early — while the customer still remembers ordering, and while the parcel is still nearby — is worth more than any tracking message.
If your carrier reports failed attempts, that is the event to build on. If it does not, a check a few days after dispatch asking whether the parcel arrived does much the same job. The flow is in failed delivery recovery.
What none of this changes
A shipping notification reaches a customer who has not messaged you recently, so it is a template under Meta's template documentation — and it needs to exist and be approved before the flow is useful. Approval is the slow part; the flow is the fast part.
Once the customer replies to it, you are inside the 24-hour customer service window from Meta's sending messages documentation, and everything after that is free.
Frequently asked
Do you integrate with my courier?
Leopards Courier, PostEx and M&P connect directly, TCS connects in beta, and Trax is coming. Every other courier works through your store's fulfilment, which covers most needs.
Why did my shipping message not send?
Most often an empty tracking field on a manually created fulfilment. The automation's activity view names the step that stopped.
Can I message customers when a parcel is out for delivery?
Only if something tells you it is, when it happens. The direct courier connection checks once a day, which suits delivered and returning parcels rather than out-for-delivery alerts; for those you need a carrier that reports it, or your own system posting the event.
Should I send a tracking link or the number?
Both, when you have them. The link is what most customers tap; the number is what they need if they ring the courier.
The fulfilment habit that fixes most of this
Almost every broken shipping message traces back to one moment: an order marked fulfilled without the tracking details entered. Nothing downstream can invent them.
So the highest-value change is usually not in the flow at all — it is agreeing with whoever packs orders that a fulfilment is not finished until the carrier and tracking number are in it. Five seconds per order, and it makes every shipping message afterwards work.
| If the fulfilment has | The customer gets |
|---|---|
| Carrier and tracking number | The full message, with a link to tap |
| Carrier only | A plainer "it is on its way with X" — worth having |
| Neither | Nothing, if you guarded it. A broken message, if you did not |
What to promise customers
- Promise dispatch, not delivery. You control one and not the other.
- Give a range, not a date, unless your carrier genuinely commits to one.
- Say who is carrying it. Customers behave differently depending on the courier, and they appreciate knowing.
- Do not promise a delivery notification unless you have confirmed those events actually arrive for your carrier.
The fourth is the one that quietly creates complaints. A customer told they will be notified on delivery, who then is not, has been let down by a message you sent.
A realistic shipping setup
- A shipping template, approved, with the courier and tracking number as variables.
- A guard in front of it, so a fulfilment with no tracking never sends a broken message.
- A second, plainer message for those fulfilments, so the customer still hears something.
- The courier name saved to the customer's record.
- A timed check-in a few days later, rather than a delivery notification you cannot rely on.
Five steps, and only the first needs Meta's approval. The rest is an afternoon in the flow builder.
Watching the volume
Shipping notifications are templates, and a busy dispatch day can send a lot of them. They count against your messaging limit, which starts at 250 unique recipients per rolling 24 hours on the ladder 250 → 2,000 → 10,000 → 100,000 → unlimited in Meta's messaging limits documentation.
That matters most at peak season, when dispatch volume and campaign volume collide in the same pool. A campaign that consumes the day's allowance leaves parcels going out with nobody told about them, which is the wrong trade.
The short version
Leopards, PostEx and M&P connect directly and tell your flows when a parcel is delivered or coming back. For every other courier, tracking reaches your flows through your store's fulfilment. Either way, enter the tracking details when you fulfil and guard every message that uses them — and for a courier that is not connected, do not promise delivery notifications unless you have confirmed those events actually arrive.
Common questions
Can the customer track the parcel inside the chat?
Only if your courier exposes a way to ask, and something in the flow asks it. Otherwise you are sending them a tracking link, which is what most stores do.
Why do some orders get a shipping message and others do not?
Almost always the tracking details. A fulfilment created without them produces a run that stops at the guard, which is the correct behaviour.
Can I use a different courier per region?
Yes — the courier is whatever was recorded on the fulfilment, so the message reflects reality without you configuring anything per region.
Should I message on every status change?
No. Dispatched, and then one check-in if it goes quiet. Messaging on every scan is how a useful notification becomes something people mute.