Use Case
Delivery updates sent by your system
Dispatched, out for delivery, ready for pickup. Your own system calls the API when the order changes, and one message goes to one customer.
- One API call per status change
- Signed delivery webhooks back to you
- Project-scoped API keys
Sent by
Your order system
Hi Ana, order [ORDER NUMBER] is out for delivery today from [YOUR STORE]. Track it here: [LINK]
One order, one message per change
The order moves
Dispatched, out for delivery, ready for pickup: your system records it.Your system calls the API
One request, one customer, no list and no send button.The message arrives
One line telling the customer where the order actually is.The webhook comes back
Delivery events posted to your own endpoint, signed.
Where the order is, on the screen already in their hand
A delivery update is read once and acted on, or it is not worth sending. It has to arrive without an app, an account or a login.
A first order comes with no app
Nothing installed, nothing to sign in to, no tab where a notice waits to be found. The update lands on the same phone the order was placed from.
One fact, and what to do about it
Dispatched, out for delivery today, ready for pickup, delivery failed. Shorten the tracking link and the clicks are counted. These are the same notices a carrier sends. See logistics and delivery.
This is the transactional route
One message to one customer, sent by your system as the status changes. Related announcements, such as a depot closure or a cutoff before a holiday, go out as a scheduled campaign. Both spend the same organization balance.
An integration, not a campaign wizard
Four steps between an order status changing in your system and a customer who knows about it.
Create a key for the project
Keys are created, listed and revoked from the app, each scoped to one project and, if you want, restricted to an IP allowlist. Start at the developer API, then read keys and access.
Call send when the status changes
Your system posts the recipient, the sender and the text to the transactional endpoint. Each message is normalized, segment-counted and priced against its destination country before anything is dispatched.
Point a webhook at your endpoint
A key carries its own webhook URL and secret, and delivery events come back signed and safe to receive twice. The order record learns what became of the message without anyone opening the app.
Read the same report as a campaign
Messages sent through the API appear in the app like any other, so whoever answers the customer can see what was received. Delivery, failures and the per-recipient log all sit in reporting.
The audience is the order
There is no segment to keep current here and no list to import the night before. The recipient is not chosen at all: it is whoever placed the order the message is about, and your system already knows which number that is.
So the field that decides whether this works sits upstream of Messalogy: a phone number taken at checkout in international format, kept with the order and the record of what the customer agreed to when they gave it. Get that one field right and the audience takes care of itself, order after order.
