NabuSms is not another SMS gateway. It is the layer in front of the panels you already own — Iran's domestic panels and the international carriers — routing each message by its destination, falling back when a panel is down, and answering which application spent what.
Operator panel The APISenders name a route — otp, campaign — never a vendor.
NabuSms reads the destination's country and walks that route's chain until a panel accepts:
Carried by the domestic panels first — sms.ir, FarazSMS, Kavenegar, ippanel — with the pre-approved patterns Iranian OTP traffic needs.
The regional carriers take it — iSmartSMS for Oman at regional rates — before anything priced as "international".
The global carriers behind them: Twilio, Vonage, Infobip, and the rest of the chain, in price order.
One panel's outage or empty credit moves the message to the next, and the log records every attempt and why.
Every product sends under its own key with its own rate limit and route permissions, so the usage log can answer "which app sent this?".
The same OTP pattern has a different id at every panel; senders name the route and NabuSms swaps in the right one.
Panels post inbound messages to one webhook and NabuSms relays them, normalised, to wherever the conversation lives.
curl -X POST https://sms.nabuxai.com/v1/messages \ -H "Authorization: Bearer <project key>" \ -H "Content-Type: application/json" \ -d '{ "to": ["+989121234567", "+96891234567"], "text": "Your code: 47291", "route": "otp" }' → { "sent": 2, "failed": 0, "messages": [ { "to": "989121234567", "status": "sent", "provider": "smsir" }, { "to": "96891234567", "status": "sent", "provider": "ismartsms" } ] }
Same request, two countries, two carriers — the sender never chose one.
GET /v1/usage answers what each application sent and what it cost.