A2P API
One API. Every channel your product actually needs.
Send OTPs over SMS, receipts over email, and everything in between through a single endpoint with the same message ID, delivery states, and webhook events no matter which channel carries it.
Send contract
Pick the channel. Everything else stays the same.
One field channel decides where the message goes. The response shape, the message ID, and the webhook events that follow are identical either way.
{
"channel": "sms",
"to": "+233550001234",
"template": "login_otp"
}{
"message_id": "msg_9c41af",
"status": "queued",
"channel": "sms",
"created_at": "2026-07-22T09:14:02Z"
}Channel differences
Same API, different physics.
SMS and email aren't interchangeable. A unified API shouldn't pretend otherwise. Here's what actually differs underneath.
Built for A2P from day one
Not a general messaging SDK with A2P bolted on routing, retries, and status states are designed around OTPs and account notifications specifically.
One trust boundary
A single API key and signed webhook contract covers every channel, so adding email doesn't mean learning a second security model.
Go deeper
Explore each channel.
Send your first message in the next five minutes.
Create a workspace, generate an API key, and watch the delivery event come back in the dashboard.