> 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/discovery.md).

# Discovery

{% hint style="info" %}
**Device API** · NV 1.0 · Early Access
{% endhint %}

Discovery retrieves the mobile phone number currently associated with the device, without asking the user to type it in. The flow is the same as Secure SNA and runs on the same infrastructure. The difference is in the payload: Secure SNA takes a claimed `phone_number` on Create and verifies whether the device matches; Discovery takes no phone number and returns the discovered MSISDN in the response.

## What it does

* Returns the MSISDN associated with the device's active SIM.
* The trust anchor is the same as Secure SNA — the carrier's authoritative record, accessed over the active cellular data session.
* Returns a deterministic `phone_number` value on success.

## What it doesn't do

* Doesn't authenticate the person — same possession-factor caveat as Secure SNA. Use additional factors where person-trust matters.
* Doesn't work on Wi-Fi or without cellular data (NV 1.0 constraint).
* Doesn't include an IDlayr-side user-confirmation step (see below).

## When to use it

* **Streamlined onboarding** — replace "type number then verify" with "tap to continue" for first-time users.
* **Returning user re-identification** — find the device's number to look up an existing account.
* **Channel-attribution flows** — link a device to a prior interaction without ID typing.

## User consent and displaying the number

**The device never receives the MSISDN.** The SDK gets a `code` at the end of the redirect chain and hands it to your app. Your app passes the code to your backend; your backend submits the code to IDlayr and receives the discovered MSISDN in the response.

There is no IDlayr-side step where the user is shown the number, sees a masked version, or is asked to confirm. Whether and how to surface the number to the user, once your backend has it, is an integration-side decision.

Common patterns integrators adopt:

* **Show the discovered number in full and ask the user to confirm.** Backend hands the MSISDN back down to the app for display.
* **Show a masked version** (e.g. `+1 555 ••• 4567`) as a lighter-weight acknowledgement before proceeding.
* **Proceed silently** where the use case doesn't warrant a user-facing step (e.g. re-identifying a returning user on an existing account).

Any of these are supported. IDlayr always returns the full MSISDN to your backend.

## Privacy and consent

Discovery returns personally identifying data. Your integration must obtain appropriate user consent before invoking Discovery, and your data handling must comply with the applicable regulations in the region of use (e.g. GDPR in the EU, CCPA in California). The confirmation UX described above is an integration-side choice, not a substitute for consent.

## In this section

* [**How it works**](/products/number-verification/discovery/how-it-works.md) — the discovery flow, end to end.
* [**Prerequisites**](/products/number-verification/discovery/prerequisites.md) — what you need before integrating.
* [**Integration**](/products/number-verification/discovery/integration.md) — iOS, Android, and backend walkthroughs.
* [**Testing in sandbox**](/products/number-verification/discovery/testing.md) — sandbox mode is not currently available for Discovery; see the page for the interim testing approach and progress tracker.
* [**Endpoints**](/products/number-verification/discovery/endpoints.md) — REST endpoint summary; full reference in API Reference.
* [**Callbacks**](/products/number-verification/discovery/callbacks.md) — terminal-state callback payload, delivery, and retry.
* [**Error codes**](/products/number-verification/discovery/error-codes.md) — HTTP errors and terminal-state codes specific to Discovery.


---

# 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/discovery.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.