> For the complete documentation index, see [llms.txt](https://docs.idlayr.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.idlayr.com/products/number-verification/reverse-sms/how-it-works.md).

# How it works

{% hint style="info" %}
**Backend API** · Early Access
{% endhint %}

Reverse SMS verifies a phone number by having the **user send** an SMS from their device, rather than the server sending one and the user typing back a code. The carrier records which number the SMS came from; IDlayr compares that to the claimed number. The user types nothing beyond tapping Send, and there's no OTP to phish.

The integration is **backend-driven**. There is no IDlayr SDK in the loop; your app simply opens the user's native SMS composer with a destination and body that your backend supplies.

## The flow

1. **Backend decides verification is needed** and has a claimed MSISDN.
2. **Backend mints an OAuth2 access token** scoped to Reverse SMS. See [Authentication](/get-started/authentication.md).
3. **Backend creates a check** by POSTing the claimed MSISDN to IDlayr. The response includes a `check_id` and the SMS routing details — a destination MSISDN and an opaque message body that lets IDlayr correlate the SMS to the check.
4. **Backend passes the routing details to the device** via your existing application API.
5. **App opens the native SMS composer** with the destination and body pre-filled, using a standard `sms:` URL scheme. **The user taps Send.**
6. **The carrier delivers the SMS to IDlayr's endpoint**, with the originating MSISDN attached as carrier metadata.
7. **IDlayr verifies** that the originating MSISDN matches the claimed MSISDN and updates the check.
8. **Backend learns the result** via callback (recommended) or polling.

## Why it doesn't need cellular data

Unlike Secure SNA, the trust anchor here is the SMS channel, not the active mobile data session. Wi-Fi-only devices still have SMS capability via the carrier signalling channel. Reverse SMS works as long as the device is connected to a carrier — it doesn't matter whether data is on cellular, Wi-Fi, or off.

## Why it doesn't need an SDK

The device-side action — opening the SMS composer with a destination and body — is something both iOS and Android expose natively via URL schemes (`sms:...`). There's no carrier-pinned transport to manage, no redirect chain to follow, no token to forward to a low-level network call. The result of the verification arrives on your backend, not on the device, so there's nothing for an SDK to surface client-side either.

## Why it isn't SMS OTP

SMS OTP sends a code from server to device, and asks the user to type it back. That model is exposed to:

* **Phishing** — a user can be tricked into typing the code into a malicious form.
* **SIM-swap fraud** — a fraudster with a new SIM receives the OTP without the user knowing.
* **Friction** — wait for the SMS, read it, switch context, type it back.

Reverse SMS inverts the direction: the device sends, the carrier attributes, IDlayr confirms. There's no code to phish, no SMS to intercept and read, and the user just taps Send on a pre-filled message.

## Roles, at a glance

| Party           | Does                                                                                  |
| --------------- | ------------------------------------------------------------------------------------- |
| Your backend    | Mints tokens, creates the check, receives the result                                  |
| Your app        | Opens the native SMS composer with the destination and body                           |
| User's device   | Sends the SMS once the user taps Send                                                 |
| Carrier         | Routes the SMS, attaches the source MSISDN                                            |
| IDlayr platform | Receives the SMS, verifies the source against the claimed number, surfaces the result |

## What's returned

The final ReverseSMSCheck resource carries `match`, `status` (`COMPLETED` / `EXPIRED` / `ERROR`), and an `error_code` where the check ended in an error or expiry. See [Endpoints](/products/number-verification/reverse-sms/endpoints.md) and [Error codes](/products/number-verification/reverse-sms/error-codes.md) for the full response shape.

## When Reverse SMS isn't available

* Devices that can't send SMS (e.g. data-only tablets, certain region-locked devices).
* Carriers that block app-originated SMS or have restrictive SMS pricing.
* Users who cancel the SMS composer (the check sits in `ACCEPTED` until TTL).

Use [Eligibility](/products/eligibility.md) to detect support before triggering Reverse SMS, and consider Secure SNA + Reverse SMS as a layered failover pair.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.idlayr.com/products/number-verification/reverse-sms/how-it-works.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.