What happens when your callback is down
Terminal outcomes are pushed to a URL you control, with a small bounded retry. Your handler has to tolerate a repeat, and it should not expect a call for every message.
Read the guide →Messaging for marketplaces and platforms
A marketplace sends to two audiences who care about the same event for opposite reasons: the buyer wants it to arrive, the seller wants proof that it did. That makes receipts and auditability the interesting part of the problem.
Two audiences, one event
- Order placed, confirmed and shipped — to both sides
- Dispute, refund and chargeback status changes
- Payout and settlement notices to sellers
- Review and rating prompts after completion
- Account and verification notices
Receipts are the audit trail
When a seller disputes whether they were told something, the answer has to be a record rather than a recollection. The platform logs each send, and on the SMS channel normalises provider delivery receipts into one status and can push those events to your own endpoint — so the record lives in your system too.
Where responsibility divides
Your platform decides who is notified and what the notification says. On the SMS channel the messaging layer decides how it leaves the building — which connected account carries it, at what pace, and what receipt comes back.
Questions this usually raises
- Can we tell whether a specific seller was notified?
- Sends and their statuses are logged, and receipts can be pushed to an endpoint you control. Note that a receipt means the destination network accepted the message, not that it was read.
- Is there a callback retry policy?
- Callback delivery is deliberately not treated as fire-and-forget; the reliability model and its limits are set out in the callback guide.
- Can different sellers use their own provider accounts?
- Connections are held per tenant. Whether each seller is a separate tenant, and therefore has their own connections and API keys, is a design decision on your side.
Keep reading
A timeout is not a failure
Sending is accepted asynchronously and there is no de-duplication key. Retrying a request you are unsure about sends a second message and bills for it.
Read the guide →E-commerce & retail
A storefront is mostly a messaging operation that happens to have a checkout. The confirmation, the dispatch note, the delivery window, the code for a failed payment — these are the messages customers actually read, and they run on the same few send paths every day.
Open →Fintech & payments
In payments, the message is often the product: a code that must arrive before a session expires, an alert that proves a transaction happened, a reminder that keeps a subscription alive. Latency and duplicates matter here more than anywhere else.
Open →Healthcare & clinics
Most healthcare messaging is administrative, and administrative is exactly where a missed message costs a wasted appointment slot. The discipline is to say just enough to be useful and nothing that belongs in a clinical record.
Open →Logistics & delivery
A delivery operation lives on contact attempts: the customer who is not home, the gate code nobody has, the parcel going back to the depot. Each of those is a message that either saves a second attempt or causes one.
Open →SaaS & online services
For a SaaS product, messaging is infrastructure with a product surface: the login code, the incident notice, the trial-expiry nudge. These messages sit on the critical path of someone else’s workday, which sets a higher bar than marketing ever has.
Open →Education & training
Education messaging is overwhelmingly about timing: a class that moved, a deadline that is close, an enrolment that has not been confirmed. The failure mode is not a missing message, it is a message that arrives after it matters.
Open →Travel & hospitality
Travel messaging is time-zone-shaped: a confirmation that must arrive immediately, a reminder that should arrive the evening before, and a disruption notice that is worthless if it arrives after the guest has left for the airport.
Open →On-demand & field services
Field service messaging is measured in minutes: a technician is twenty minutes away, a job has moved, a customer will not be in. Every one of these messages exists to avoid a wasted trip.
Open →Scope. Whaleal Messaging is an orchestration layer over the CPaaS or BSP accounts you already hold. Your contracts, your rates and your sender identities stay yours, and nothing in the middle reprices them. Sector-specific rules — consent, records retention, industry obligations — stay with you and your provider.