API docs
Sender & message
Every verification is sent from a single pre-cleared sender, with a single fixed message template. There is no sender to register, no sender to choose, and no message to write - which is exactly what lets you start sending with nothing to set up.
The sender
Every message OTPRelay sends comes from one shared alphanumeric sender, literally OTPRelay. It is the name your users see as the "from" on the SMS. You don't choose a sender, and you don't register one - there are no per-customer or branded sender IDs, and nothing to set on the API to pick one.
This single sender is pre-cleared with operators across our live markets. OTPRelay did the telecom and compliance work once, for everyone, so you register nothing: no sender-ID filing, no per-country paperwork, no waiting on operator approval. You get an API key and start sending. The work we abstract away is detailed on the GCC compliance & coveragepage - we handle the telecom side so you don't have to.
When you send a verification, the response confirms the sender used. It is always the same value:
The message
The SMS body is a fixed template - it is not overridable. There is no message parameter to set and no template object to manage. Every message reads exactly:
{COMPANY NAME} is your company name, configured once on your OTPRelay account - it is not a request field and not something you change per message. The six-digit value shown above stands in for the code, which is generated by OTPRelay (its length is controlled by code_length, 4-8 digits, default 6). Beyond your company name, the wording is identical for every customer.
This same template applies to both modes: with the Send API, the code you generate is injected into the identical pre-cleared template.
Why it's fixed
A single vetted sender and a single vetted template are precisely what make "nothing to register" possible. Because the sender and message are pre-cleared with operators, there's no per-customer review, no content approval cycle, and no risk of an unregistered sender being silently dropped. It also keeps delivery compliant and fast: known, transactional traffic from a trusted sender is exactly what carriers route most reliably.
If you need to observe how a specific message was delivered - including automatic SMS retries across alternate routes and operators - look at the attempts[] array on the verification object, or read Delivery & failover.
On the roadmap