Connecting your courier or delivery partner
There is no courier connector. There is something better in most cases, and one gap worth knowing about before you promise anything.
There is no direct courier integration, and for most stores there does not need to be — the tracking details arrive with your store's fulfilment. When you mark an order as fulfilled and enter the tracking information, that information becomes available to a flow.
Understanding where it comes 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 |
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. 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 your courier does have an API
Some do, 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?
Not directly. Tracking details reach flows 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. That means 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
No courier connector, and usually none needed — tracking reaches your flows through your store's fulfilment. Enter the tracking details when you fulfil, guard every message that uses them, and do not promise delivery notifications unless you have confirmed those events actually arrive for your carrier.
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.