> ## Documentation Index
> Fetch the complete documentation index at: https://www.vobiz.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# What Is OTP SMS? How Mobile Verification Works

> OTP SMS is a single-use code texted to prove control of a phone number. Learn how mobile verification works, India's DLT rules, the risks, and channel choices.

*November 3, 2026 · By [Piyush Sahoo](https://www.linkedin.com/in/piyush-s713/)*

An OTP SMS is a text message carrying a one-time password: a short random code that works once and expires within minutes. Mobile verification uses that code to show that someone controls a phone number right now. It proves access to the number, not who the person is.

This guide follows one code from your server to a handset, works out how many digits and tries you can safely allow, and explains why OTPs fail on Indian routes. It ends with a decision map for choosing a channel and a checklist for choosing an OTP SMS service.

> [!NOTE]
>
> **Key takeaways**
>
> * An OTP SMS shows **control of a number at one moment**. It does not establish identity, so don't treat it as KYC.
> * **Your server makes the security decisions when you run verification yourself.** It generates the code, limits the tries, and judges the answer, while the network only carries the text.
> * **In India, an OTP can fail well before the handset.** Template drift, the wrong header category, or an unlisted URL can each stop a message.
> * **TRAI has reclassified login OTPs.** Its September 2026 amendment moves app login, password reset, and two-factor OTPs from transactional to service messages.
> * **SMS is the reach option, not the strongest one.** Keep it for coverage, and offer a passkey or authenticator app where the risk justifies the enrolment.

## What does OTP mean in an SMS?

OTP stands for one-time password, also written as one-time passcode. TRAI's regulations define it as an [automatically generated random number](https://www.trai.gov.in/sites/default/files/2026-05/CA_21052026.pdf) that authenticates a user's action for one transaction or session. In practice, the SMS reads something like this:

> Your Acme login code is 123456. It expires in 10 minutes. Do not share it with anyone.

The word "password" misleads. You never choose this code or memorise it, and it has no value once used.

### Not every OTP is made the same way

The name covers three different mechanisms, and many explainers blur them. HOTP and TOTP are the two standard algorithms, and a texted code usually works differently from both. [NIST treats a texted code](https://pages.nist.gov/800-63-4/sp800-63b.html) as an out-of-band secret rather than an OTP authenticator, and the distinction changes your threat model.

| Type | Where the code comes from | Shared in advance | Travels over the network |
| - | - | - | - |
| SMS OTP | Your server draws a random value for this one request | Only the phone number | Yes, in the SMS |
| [HOTP (RFC 4226)](https://www.rfc-editor.org/rfc/rfc4226.txt) | Secret key plus a moving counter | A secret key | No |
| [TOTP (RFC 6238)](https://www.rfc-editor.org/rfc/rfc6238.txt) | Secret key plus the current time, with a default 30-second step | A secret key | No |

So the 30-second countdown belongs to authenticator apps. An SMS code lives as long as your server allows.

## What does mobile verification actually prove?

Mobile verification proves that whoever typed the code could read a message sent to that number within your time limit. That is useful, and it is narrower than people assume. It says nothing about the person's legal name, and a number can move to a new SIM or a new owner.

Match the check to the question you are really asking:

| Your question | Is SMS OTP enough? | What to add |
| - | - | - |
| Is this a working number the user can reach? | Usually yes | Format it in [E.164](https://www.vobiz.ai/docs/blogs/what-is-e164-phone-number-formatting.md) first |
| Is this the same person who owns the account? | Only for lower-risk accounts | A password, passkey, or device check |
| Did the customer approve this payment? | One factor at most | A second factor, as RBI's rules require |
| Is this person who they claim to be? | No | A KYC process with identity evidence |

For Indian businesses, there is also a government route for the first question. The 2025 telecom cyber security amendment created a [Mobile Number Validation platform](https://www.azbpartners.com/bank/telecommunications-telecom-cyber-security-amendment-rules-2025-notified/) that checks an identifier against operator subscriber records. Entities may be directed to use it or may seek permission. [MediaNama reports](https://www.medianama.com/2025/10/223-dot-telecom-cybersecurity-rules/) that the final rules left fees to DoT's portal. We could not confirm a public launch date, so treat it as something to watch.

## How does one OTP travel from request to approval?

Eight steps cross three parties. The two highlighted steps are where you win or lose on security.

![Sequence of one SMS OTP across the person, your server, and the provider and operators: request, code generation with a stored hash, templated send, delivery, delivery receipt, code entry, hash check, and approval.](https://mintcdn.com/vobizai/O7qj4DettrLZsu3Z/images/blog/what-is-otp-sms/otp-lifecycle-light.svg?fit=max\&auto=format\&n=O7qj4DettrLZsu3Z\&q=85\&s=d84f19762666fbc5ece3c052d5fbe471)

**At step 2, generate and store carefully.** Draw the code from a cryptographically secure random generator. Don't keep codes in plaintext. Store a keyed hash with the expiry and try count. Use a server-side secret as the key, because a plain hash of six digits falls to anyone who tries all million values.

**At step 4, expect store and forward.** The [SMS specification](https://www.etsi.org/deliver/etsi_ts/123000_123099/123040/17.03.00_60/ts_123040v170300p.pdf) describes a service centre that holds a message and forwards it, keeping it for a validity period. A phone that was switched off can therefore receive your code long after it stopped working. The person then sees a correct-looking code that fails.

**At step 5, read the receipt for what it is.** It tells you the message arrived, which helps with fallback decisions. It tells you nothing about who read it.

**At step 7, burn the code.** A code must work once only. [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) is written for US federal systems, yet it is the most useful public benchmark here:

* Accept a secret only once during its validity period.
* Treat the authentication as invalid unless it completes within 10 minutes.
* Use at least six decimal digits from an approved random generator.
* Rate-limit failures on the account, and allow no more than 100 consecutive failures.
* Don't reset the failure count when you issue a new code.

That last rule is the one teams miss. If a resend wipes the counter, an attacker simply requests new codes and keeps guessing.

## How many digits and tries should you allow?

[Tata Communications](https://www.tatacommunications.com/knowledge-base/cpaas/sms-otp-verification) describes codes of four to six digits as usual. The gap between those two lengths is larger than it looks, because attackers rarely target one account. They try a guess or two across many numbers.

![Log-scale bar chart of expected successful blind guesses per 100,000 numbers. With 3, 5, 10 and 100 tries, 4-digit codes give 30, 50, 100 and 1,000 successes, and 6-digit codes give 0.3, 0.5, 1 and 10.](https://mintcdn.com/vobizai/O7qj4DettrLZsu3Z/images/blog/what-is-otp-sms/otp-guess-odds-light.svg?fit=max\&auto=format\&n=O7qj4DettrLZsu3Z\&q=85\&s=8527502e3f62d67917813dda3157fce3)

The arithmetic is simple. Expected successes equal numbers attacked, multiplied by tries allowed, divided by the possible codes. At five tries across 100,000 numbers, a 4-digit code gives about 50 breached accounts and a 6-digit code gives about 0.5.

NIST's 100-failure ceiling is an upper bound for a whole account, not a target. For an SMS flow, three to five tries per code is a sensible starting point, as long as the running count survives a resend. Limits per number alone won't catch this pattern, so also limit by IP address, device, and session.

## Why does OTP SMS fail on Indian routes?

India adds a registration layer that most global explainers skip. TRAI requires [commercial SMS to be traceable](https://www.vobiz.ai/docs/sms/compliance/india-dlt.md) to a registered sender and template, and operators check each message against that record. An OTP that is perfect in your code can still stop here.

![Five stages an OTP SMS passes in India, from your app through the Vobiz Messaging API, the operator DLT check and the service centre to the handset, with what can stop the code at each stage and a delivery report returning to your server.](https://mintcdn.com/vobizai/O7qj4DettrLZsu3Z/images/blog/what-is-otp-sms/otp-path-india-light.svg?fit=max\&auto=format\&n=O7qj4DettrLZsu3Z\&q=85\&s=589919eb6ea7cfbbc5ad54bc57add27f)

### Which DLT category does an OTP belong to?

The answer has just changed. TRAI's [Third Amendment of 18 September 2026](https://www.trai.gov.in/sites/default/files/2026-09/Regulation_18092026.pdf) says "OTPs for apps login" were inadvertently placed under transactional messages. It deletes those words from that definition and adds authentication OTPs to the service definition.

| OTP purpose | [Consolidated text, May 2026](https://www.trai.gov.in/sites/default/files/2026-05/CA_21052026.pdf) | Third Amendment | Header suffix after the change |
| - | - | - | - |
| Bank or e-commerce OTP for a transaction the customer started | Transactional, if sent within 30 minutes | Stays transactional | `-T` |
| App login | Transactional | Service | `-S` |
| Password reset or two-factor | Not named | Service | `-S` |
| Confirming a number at signup | Not named | Not named | Ask your DLT operator |

The [header suffixes](https://trai.gov.in/sites/default/files/2025-02/PR_No.11of2025.pdf) let recipients see the category at a glance. The definitions covering these OTPs say they don't need explicit consent.

The amendment's definition changes start 30 days after Gazette publication, and we could not confirm that date. TRAI dated the notification 18 September 2026, so they may already apply. Before you move anything, ask your DLT operator whether your login templates and headers need to change.

### The checks that stop a compliant-looking message

**The template must match.** [Vobiz's India DLT guide](https://www.vobiz.ai/docs/sms/compliance/india-dlt.md) explains that a template fixes the wording and marks variable positions with `{#var#}`. Operators reject text that doesn't match a template under the header you used. Build the message from the same string you registered, so the two can't drift apart.

**Links and callback numbers must be listed.** TRAI's [August 2024 direction](https://www.trai.gov.in/sites/default/files/2024-09/Direction_20082024.pdf) told operators to refuse traffic with URLs, APKs, OTT links, or callback numbers that are not whitelisted. It also set rejection for messages with an undefined telemarketer chain. The simplest OTP template has no link at all.

**The wording must fit your business.** The same direction notes misuse of words like "OTP" in templates unrelated to a sender's business. Keep your entity name, header, and template recognisably connected.

**A new SIM may not receive SMS yet.** [TelecomTalk reported in November 2022](https://telecomtalk.info/jio-vi-airtel-bsnl-ordered-to-stop/623029/) that DoT told operators to stop SMS on a swapped or replaced SIM for 24 hours. We could not read the order itself, so confirm the current rule. Either way, a real customer who just replaced a SIM may need another channel, and that same moment deserves more suspicion.

## What should happen when the code doesn't arrive?

Users tap resend quickly, and each tap costs money and adds risk. Decide in advance how you'll respond to each signal. The timer below is our suggested starting point, so tune it against your own delivery data.

| Signal | What it means | What to do |
| - | - | - |
| Send returns `502` or `503` | No message was created, or a temporary fault | Retry with the **same** idempotency key |
| Status `failed` | The network refused or lost it | Read the error, and offer another channel |
| No receipt after about 30 seconds | Slow or lost | Enable the resend button |
| The user taps resend | A new send, not a retry | Use a **new** key, and keep the failure count |
| A second send fails | This route isn't working for this person | Offer a voice call or WhatsApp |

Resends raise one design choice. You can issue a new code and cancel the old one. This limits the number of valid values. The catch is that a delayed first message then fails when typed. You can instead resend the same code with its original expiry, which forgives out-of-order delivery. We'd rotate codes on login and payment flows, and tell the user that only the latest code works.

Keep the text short and in a predictable alphabet. Per the [Vobiz SMS guide](https://www.vobiz.ai/docs/sms/channels/sms.md), one GSM-7 segment holds 160 characters, while any character outside that alphabet switches the whole text to UCS-2 at 70. Our sample above has 86 characters. A Hindi template of that length takes two segments, so it costs more and has more parts to reassemble.

You can also remove typing altogether:

* **Android:** the [SMS Retriever API](https://developers.google.com/identity/sms-retriever/overview) reads the code automatically when the message contains your app hash.
* **Web forms:** the `one-time-code` value of the [autocomplete attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete) tells browsers what the field expects.
* **Origin-bound codes:** the [WebOTP draft](https://wicg.github.io/web-otp/) ends a message with your domain and code, so the browser can tie the code to your site. [MDN marks the API](https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API) as experimental and not widely available, so treat it as an enhancement.

## How secure is OTP SMS?

It is secure enough for many jobs and not for all of them. The honest picture is that each attack targets a different step, so each needs a different control.

| Attack | How it works | What reduces it |
| - | - | - |
| SIM swap | An attacker [convinces the operator](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) to move the number to a new SIM | Watch for number changes, and require a stronger factor for sensitive changes |
| Real-time phishing | A [reverse-proxy site](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) asks for the code and replays it on the real one | State the service and action in the text, and offer passkeys |
| Network interception | SMS is [not encrypted](https://www.cisa.gov/sites/default/files/2024-12/guidance-mobile-communications-best-practices.pdf), so someone inside a telecom network can read it | Avoid SMS for your most-targeted accounts |
| Guessing | Automated tries across many numbers | Six or more digits, and limits that survive a resend |
| SMS pumping | Fraudsters trigger codes to number ranges that earn them a revenue share | Rate limits, country allowlists, and spend alerts |

The sign to monitor is a spike to adjacent numbers with no completed verifications. Compare codes sent against codes verified, by country and number range. Spending thresholds also help on costly routes.

### What regulators actually say

These three positions are often flattened into "SMS OTP is banned" or "SMS OTP is fine". Neither is accurate.

* **RBI (India):** its [authentication directions](https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898), with compliance due by 1 April 2026, require two distinct factors for domestic digital payments unless exempted. They list SMS-based OTP among the possible factors and open the way to alternatives. Outside card-present payments, one factor must be unique to the transaction. If non-compliance causes a loss, the issuer compensates the customer in full.
* **NIST (US):** [SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) restricts phone-network delivery rather than prohibiting it. An organisation that accepts phone-network delivery must assess the risk, offer an unrestricted alternative, tell users about the risks, and plan a migration.
* **CISA (US):** its [December 2024 guidance](https://www.cisa.gov/sites/default/files/2024-12/guidance-mobile-communications-best-practices.pdf) tells highly targeted individuals not to use SMS as a second factor. CISA says the guidance applies to all audiences, though it is aimed at that group.

You may read that India is phasing out SMS authentication entirely. The RBI text doesn't say that. It sets principles and lets issuers offer a choice of factors.

## Which channel should you use for verification?

Start from what the moment needs, not from what is cheapest to send.

![Decision map with three questions. Proving a number works leads to SMS OTP with voice fallback. A person who can enrol a device leads to a passkey or authenticator app. A high-value action leads to SMS OTP plus an independent factor. Routine actions use SMS OTP with WhatsApp, RCS or voice as alternatives.](https://mintcdn.com/vobizai/O7qj4DettrLZsu3Z/images/blog/what-is-otp-sms/otp-channel-map-light.svg?fit=max\&auto=format\&n=O7qj4DettrLZsu3Z\&q=85\&s=5f7cf2c471fe392ff83891a411d35fda)

| Channel | Works best when | Limits to plan around |
| - | - | - |
| SMS OTP | You need [coverage with no app or data connection](https://www.tatacommunications.com/knowledge-base/cpaas/sms-otp-verification) | The risks above, plus DLT work in India |
| Voice OTP | SMS failed, or the person prefers to listen | Codes are heard rather than copied, and call rules apply |
| WhatsApp | Your users already live in the app | Needs an [authentication template](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/authentication-templates/authentication-templates/) with preset text |
| RCS | Recipients have RCS enabled | Check reachability first, and set an SMS fallback |
| Authenticator app (TOTP) | Returning users who will enrol | Setup effort, and [still phishable](https://www.cisa.gov/sites/default/files/2024-12/guidance-mobile-communications-best-practices.pdf) |
| Passkey or FIDO key | High-value accounts | Enrolment and recovery design |

India adds one more reason to review app-based channels. DoT's [November 2025 directions](https://www.dot.gov.in/static/uploads/2025/12/4599a9925468a2648d43e3ff724e7f0c.pdf) told major messaging apps to keep accounts continuously linked to the active SIM. The release describes this as already standard in banking and UPI systems. The original window was 90 days, and the [minister's April 2026 reply to Parliament](https://www.etvbharat.com/en/bharat/communication-apps-need-to-comply-with-sim-binding-rules-by-december-31-mos-telecom-enn26040205271) set the compliance date as 31 December 2026.

## What should you look for in an OTP SMS service?

Compare providers on how they behave when a code is in trouble, not on the happy path. Ask these questions before you commit:

1. **DLT handling:** can you pass your entity, header, and template IDs on every message, and who enables your header?
2. **Delivery truth:** do you get separate statuses for accepted, delivered, and failed, with an error reason?
3. **Safe retries:** can a retry reuse an idempotency key, so a timeout doesn't send and bill twice?
4. **Signed webhooks (callbacks):** can you verify that a receipt really came from the provider?
5. **Cost visibility:** can you see segments and price before sending a new template?
6. **Fallback channels:** can you reach the same person by voice, WhatsApp, or RCS through one account?
7. **Your own measurements:** test each route with real handsets on each operator you care about. Published delivery claims can't tell you about your traffic.
8. **Who owns the logic:** does the provider verify codes for you, or does your server? Each model works. Make sure you know where the limits and audit trail live.

## How Vobiz handles OTP delivery

Vobiz is the delivery layer in this design, across several channels. Your server generates, stores, and checks the code, and Vobiz carries the message and reports what happened.

**SMS.** You send through the [Vobiz Messaging API](https://www.vobiz.ai/docs/sms/overview.md) using [Send a message](https://www.vobiz.ai/docs/sms/api/messages/send-message.md). For Indian numbers, you pass `dltEntityId`, `dltHeaderId`, and `dltTemplateId`, and your registered header is the `from` value. [Indian traffic uses DLT sender IDs](https://www.vobiz.ai/docs/sms/compliance/india-dlt.md) rather than long codes, and support enables your header on your account. Registration itself happens on a [DLT portal](https://www.vobiz.ai/docs/best-practices/dlt-registration.md).

**Retries.** An `idempotencyKey` returns the original message instead of sending again, [whatever the first attempt's outcome](https://www.vobiz.ai/docs/sms/errors.md). That is why a user-requested resend needs a new key. A `tag` such as `otp` lets you filter this traffic later.

**Delivery status.** `sent` means the network accepted the message, and `delivered` means a delivery receipt came back. [Webhooks (callbacks)](https://www.vobiz.ai/docs/sms/webhooks.md) fire `message.delivered` and `message.failed`, signed with `X-Webhook-Signature`, so your fallback logic doesn't need to poll.

**Cost before sending.** [Cost preview](https://www.vobiz.ai/docs/sms/api/messages/cost-preview.md) returns the segment count and price for a text without sending it. For current rates, see the [Vobiz pricing page](https://www.vobiz.ai/pricing/).

**Opt-outs.** A number that replied STOP is on your [opt-out list](https://www.vobiz.ai/docs/sms/opt-outs.md), and sends to it return `422`. Handle this in your login flow, because that person may still need a code. Offer another channel, and confirm consent before you remove an entry.

**Other channels.** [RCS](https://www.vobiz.ai/docs/sms/channels/rcs.md) has a reachability check and `failoverToSms`. [WhatsApp templates](https://www.vobiz.ai/docs/whatsapp/api/templates.md) include an `AUTHENTICATION` category for codes. The [OTP call example](https://www.vobiz.ai/docs/examples/vobiz-otp-call-xml-python.md) uses VobizXML to read a code aloud digit by digit, and the [Vobiz DLT guide](https://www.vobiz.ai/docs/best-practices/dlt-registration.md) lists the 160 series for OTP calls in India.

> [!WARNING]
>
> Every send texts or calls a real person and is billed. Run examples only with your own Auth ID and Auth Token, against numbers you have permission to contact, and after you confirm the destination.

## Frequently asked questions

> [accordion] What does OTP mean in an SMS?
>
> OTP stands for one-time password. In an SMS, it is a short numeric code that a service generates for one action and texts to your phone. You type it back to continue. It stops working after one use or when its time limit passes.

> [accordion] How long is an OTP valid?
>
> The sender sets the limit, so it varies by service. Many use a few minutes. NIST's digital identity guidelines treat out-of-band authentication as invalid unless it completes within 10 minutes, which makes 10 minutes a sensible ceiling. Payment and account-recovery flows usually justify something shorter.

> [accordion] Why am I not receiving my OTP SMS?
>
> As a user, check signal, a recent SIM replacement, and your spam filter, then request one new code. As a sender in India, check the DLT template match, header category, and any URL in the text. Your delivery report usually tells you which stage failed.

> [accordion] Is OTP SMS safe?
>
> It adds real protection over a password alone, and it is weaker than a passkey. SMS is not encrypted, and a code can be phished or redirected through a SIM swap. Use it for reach, then offer stronger methods for accounts and actions worth attacking.

> [accordion] Is OTP SMS transactional or service under DLT?
>
> It depends on purpose. TRAI's September 2026 amendment moves OTPs for app login, password reset, and two-factor authentication into service messages, while OTPs tied to customer-initiated transactions remain transactional. Those changes start after Gazette publication, so confirm the current position with your DLT operator before changing headers.

> [accordion] What is the difference between OTP and two-factor authentication?
>
> Two-factor authentication is the requirement: two separate kinds of proof. An OTP is one possible proof, showing you hold a device or number. An SMS OTP used alone is one factor. It becomes two-factor only when paired with something else, such as a password or fingerprint.

## Further reading on Vobiz

* [Sending SMS with Vobiz](https://www.vobiz.ai/docs/sms/channels/sms.md): segments, idempotency, and statuses.
* [India DLT for SMS](https://www.vobiz.ai/docs/sms/compliance/india-dlt.md): the three identifiers and how to pass them.
* [UCC and NDNC compliance](https://www.vobiz.ai/docs/compliance/india/ucc.md): India's rules on commercial communication.
* [India calling regulations](https://www.vobiz.ai/docs/compliance/india/calling-regulations.md): what applies if you add voice OTP.
* [What is number masking?](https://www.vobiz.ai/docs/blogs/what-is-number-masking.md): why a phone number works like a credential.

## Sources

**Indian regulators and government**

* TRAI, [Telecom Commercial Communications Customer Preference (Third Amendment) Regulations, 2026](https://www.trai.gov.in/sites/default/files/2026-09/Regulation_18092026.pdf), 18 September 2026.
* TRAI, [Consolidated TCCCPR 2018 text](https://www.trai.gov.in/sites/default/files/2026-05/CA_21052026.pdf), May 2026.
* TRAI, [Press release 11/2025 on the TCCCPR amendments](https://trai.gov.in/sites/default/files/2025-02/PR_No.11of2025.pdf), February 2025.
* TRAI, [Direction on misuse of headers and content templates](https://www.trai.gov.in/sites/default/files/2024-09/Direction_20082024.pdf), 20 August 2024.
* RBI, [Authentication mechanisms for digital payment transactions Directions, 2025](https://www.rbi.org.in/Scripts/NotificationUser.aspx?Id=12898), 25 September 2025.
* DoT via PIB, [Directions for SIM binding](https://www.dot.gov.in/static/uploads/2025/12/4599a9925468a2648d43e3ff724e7f0c.pdf), 1 December 2025.

**Standards and security guidance**

* NIST, [SP 800-63B-4: Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html).
* CISA, [Mobile Communications Best Practice Guidance](https://www.cisa.gov/sites/default/files/2024-12/guidance-mobile-communications-best-practices.pdf), December 2024.
* OWASP, [Multifactor Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html).
* IETF, [RFC 4226: HOTP](https://www.rfc-editor.org/rfc/rfc4226.txt), December 2005.
* IETF, [RFC 6238: TOTP](https://www.rfc-editor.org/rfc/rfc6238.txt), May 2011.
* ETSI, [TS 123 040: Technical realization of the Short Message Service](https://www.etsi.org/deliver/etsi_ts/123000_123099/123040/17.03.00_60/ts_123040v170300p.pdf), V17.3.0, July 2023.
* WICG, [WebOTP API draft](https://wicg.github.io/web-otp/), April 2021.

**Platform documentation**

* Google, [SMS Retriever API overview](https://developers.google.com/identity/sms-retriever/overview).
* MDN, [WebOTP API](https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API) and [HTML autocomplete attribute](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete).
* Meta, [WhatsApp authentication templates](https://developers.facebook.com/documentation/business-messaging/whatsapp/templates/authentication-templates/authentication-templates/).

**Industry and press**

* AZB & Partners, [Telecom Cyber Security Amendment Rules, 2025](https://www.azbpartners.com/bank/telecommunications-telecom-cyber-security-amendment-rules-2025-notified/), November 2025.
* MediaNama, [DoT telecom cybersecurity rules](https://www.medianama.com/2025/10/223-dot-telecom-cybersecurity-rules/), October 2025.
* ETV Bharat, [Communication apps need to comply with SIM binding rules by Dec 31](https://www.etvbharat.com/en/bharat/communication-apps-need-to-comply-with-sim-binding-rules-by-december-31-mos-telecom-enn26040205271), April 2026.
* TelecomTalk, [Telcos ordered to stop SMS on new SIMs for one day](https://telecomtalk.info/jio-vi-airtel-bsnl-ordered-to-stop/623029/), November 2022.
* Tata Communications, [SMS OTP verification](https://www.tatacommunications.com/knowledge-base/cpaas/sms-otp-verification), November 2025.

> [card] [Send your first SMS with Vobiz](https://www.vobiz.ai/docs/sms/quickstart.md)
>
> Get your credentials and send a test message to your own number.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.