A confirmation, a reminder, an alert, a one-time code — every industry sends the same handful of message types for different reasons. These pages describe what a given vertical typically sends, and which parts of the platform carry the load. The provider accounts, the pricing and the message credits stay yours.
A storefront runs on the messages customers actually read: the confirmation, the dispatch note, the delivery window, the code after a failed payment. Send all of them over the SMS, email and WhatsApp accounts your store already pays for.
Read more →In payments the message is often the product: a code that has to land before the session expires, an alert that proves a transaction happened, a reminder that keeps a subscription alive. Connect your own accounts, and the send path stops being the part you have to watch.
Read more →Most clinic messaging is administrative, and a missed administrative message costs a wasted appointment slot. Send a confirmation at booking and a timed reminder before, on the number the patient gave you — and keep clinical detail out of it.
Read more →A delivery operation lives on contact attempts: the customer who is not home, the gate code nobody has, the parcel heading back to the depot. Each of those is a message that either saves a second trip or causes one.
Read more →Your login codes, incident notices and renewal nudges sit on the critical path of someone else’s workday. Send them from your own service with a tenant API key, and read the outcome back through the same API.
Read more →Education messaging is about timing: a class that moved, a deadline that is close, an enrollment nobody confirmed. The failure mode is not a missing message — it is one that arrives after it mattered.
Read more →A marketplace messages two audiences about the same event for opposite reasons: the buyer wants it to arrive, the seller wants proof that it did. That makes the receipt the part worth getting right.
Read more →Travel messaging is shaped by the clock: a confirmation that has to arrive immediately, a reminder the evening before, a disruption notice that is worthless once the guest has left for the airport. Send each one from an account that is still accepting traffic.
Read more →Field service messaging is measured in minutes: a technician twenty minutes away, a job that moved, a customer who will not be in. Send the ETA when the event happens and it saves a trip; send it late and it is worse than silence.
Read more →One page per capability: what it does, what it changes about your sending, and which channel it ships on. Every capability is described at the depth you need to decide whether it carries the messages your product depends on.
Open →Each page takes one message your product sends repeatedly and lays out what it takes to send it well: who the provider is, what the message must carry, what should never be sent, and what the platform does versus what stays with you.
Open →These pages compare architectures, not vendors. Every page works from what is true of a given approach, and the trade-offs are the point: holding your own provider relationships on one side, handing them to a platform on the other, and where an orchestration layer sits between the two.
Open →