/Delivery & failover

API docs

Delivery & failover

Every OTPRelay code is delivered by SMS from the OTPRelay sender over multiple delivery routes. If a route goes quiet, OTPRelay automatically retries the same code on another route or operator - so verifications still complete.

OTPRelay does one thing: it sends a one-time passcode by SMS and verifies it. There is nothing to choose and no delivery parameters at all - you call Send a verification with the destination number, and OTPRelay handles the routing, the redundancy and the re-sends for you.

How delivery works

Each verification is delivered as an SMS from the single, pre-cleared alphanumeric sender OTPRelay, carrying the fixed message body for your account. OTPRelay did the telecom and compliance work once, for everyone, so you register nothing - see Sender & message for the sender and message details.

Messages travel over multiple delivery routes with built-in redundancy. Delivery is live starting in the Gulf - Saudi Arabia today, with the rest of the GCC next and more regions following demand - and the routing is the same everywhere: a high-quality path to the destination operator, with healthy alternates kept warm behind it.

Both the Send and Verify APIs ride this same delivery layer - the same routes and the same automatic operator failover, whichever mode you use.

Automatic failover

Failover is fully automatic and entirely SMS - there are no parameters to set. OTPRelay scores route health continuously, and if a route returns no delivery receipt within its window, OTPRelay retries the same code over an alternate route or operator. The recipient never receives two different codes for one verification.

Recovery is applied innermost first, exhausting the cheaper, less disruptive path before escalating:

LayerWhat happens
Route failoverWhen a route stops returning delivery receipts, OTPRelay re-sends the same code over a healthier route to the same destination operator - same SMS, same sender.
Operator failoverIf the destination operator's routes are all degraded, OTPRelay retries over an alternate in-country operator that can reach the number, still by SMS.

Reading attempts

Every send - the first attempt and every automatic retry - is recorded as an entry in the verification's attempts[] array, so you can see exactly what ran and where it landed. Each attempt carries its own status, the delivering carrier and the timestamp at when it was sent:

  • status - one of sent, delivered, undelivered or failed for that individual attempt.
  • carrier - the operator that handled the attempt (for example stc, mobily or du).
  • at - the timestamp the attempt was dispatched.

In the response below the first attempt failed on stc, so OTPRelay automatically retried the same code over mobily, which delivered. See the full shape on The verification object.

Verification with failover
{  "id": "ver_01HZX9Q2K3M7B8N4P5R6S7T8U9",  "object": "verification",  "status": "pending",  "to": "+966512345678",  "country": "SA",  "sender": "OTPRelay",  "code_length": 6,  "verified": false,  "attempts": [    {      "id": "att_01HZX9Q2K3M7B8N4P5R6S7T8UA",      "status": "failed",      "carrier": "stc",      "at": "2026-06-16T10:00:00Z"    },    {      "id": "att_01HZX9Q2K3M7B8N4P5R6S7T8UB",      "status": "delivered",      "carrier": "mobily",      "at": "2026-06-16T10:00:31Z"    }  ],  "metadata": { "user_id": "u_8842" },  "created_at": "2026-06-16T10:00:00Z",  "expires_at": "2026-06-16T10:10:00Z"}

Failover windows are being finalized

The exact route and operator failover windows - and how route health is scored and exposed - are still being finalized.