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.
We connect to the provider accounts you already pay for, and we never sell you message credits. That one decision sets your rate, your switching cost, and who owns the relationship — everything below follows from it.
Read more →We chose to sit above the provider APIs rather than hold carrier relationships — because that is the arrangement that keeps your rates, your registrations and your sender identity in your own name. Here is what that choice puts in your hands.
Read more →A single account is a single point of failure you cannot see breaking until customers tell you. Connecting a second turns that into failover you configure once — which is why routing belongs in the layer rather than bolted on later.
Read more →Calling a provider API takes an afternoon. Making messaging dependable is a list of unglamorous problems that only show up in production — and that list is what we maintain so your team does not have to.
Read more →Sending direct is the fastest way to send the first message. The layer is what keeps messaging dependable once a second provider, a second team or a second failure arrives — and it adds nothing you have to migrate away from.
Read more →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.
Open →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 →