> 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/enterprise-portal/verification-logs/discovery.md).

# Discovery logs

The Discovery logs view lists every Discovery check made by your project, newest first. Click any row to drill into a specific check.

For background on what Discovery is and how the silent-MSISDN-discovery-plus-user-confirmation flow works, see the [Discovery product page](/products/number-verification/discovery.md).

## What you see in the list

Each row represents a single check. The columns typically include:

| Column           | What it shows                            |
| ---------------- | ---------------------------------------- |
| **Check ID**     | The `check_id` returned at creation.     |
| **Date / Time**  | When the check was created.              |
| **Status**       | `COMPLETED`, `EXPIRED`, `ERROR`.         |
| **Network**      | Mobile network operator (MNO)            |
| **Reference ID** | The `reference_id` returned at creation. |

## Filters

* **Search by phone number** — finds every Discovery check where the discovered MSISDN matches. Useful when investigating a specific user.
* **Filter by status** — narrow to `COMPLETED`, `EXPIRED`, `ERROR`, or in-flight (`ACCEPTED`).
* **Filter by user outcome** — confirmed, declined, or no-response.
* **Filter by date range.**

## Drilling into a check

Clicking a row opens the check's detail view, which typically includes:

* **The original request** — the project that initiated it, `redirect_url`, `callback_url`, `reference_id` (if you supplied one).
* **State transitions** --  `COMPLETED` / `EXPIRED` / `ERROR`, with timestamps.
* **Network context** — the resolved MNO and country.
* **The `error_code`** if the check ended in `ERROR` or `EXPIRED`.

## Common investigations

**A user reports they never saw the masked-number confirmation.** Search the discovered MSISDN if you have it, or filter by date range around when the user attempted the flow. Inspect the redirect chain to see how far the verification got. If the chain didn't reach the confirmation step, the device likely lost cellular before the lookup completed.

**Confirmation-decline rate is higher than expected.** Filter to user-declined outcomes over the period in question. Common causes: the masked number doesn't visually match what the user expects (e.g. a corporate number presented at a personal flow), or the user is on an MVNO with an unexpected line number. Cross-reference with which MNOs are reporting the declines.

**Discovery isn't returning any MSISDN.** Look at checks where the discovered field is empty and the status is `ERROR`. Usually the device wasn't on a supported MNO or wasn't on cellular at the moment of the request. Pre-checking with [Eligibility by Mobile IP Address](/products/eligibility.md) avoids these calls.

## Early Access

Discovery is in **Early Access**. Per-field behaviour, retention, and the specific values in the user-outcome column may evolve as the product graduates. Confirm specifics with your IDlayr account team during onboarding.

## Retention

Production checks are retained for the period specified in your IDlayr Trust Center attestations — see [Compliance & Security](https://gitlab.com/4auth/product-documentation/-/blob/main/help/compliance-and-security.md). Sandbox `EXPIRED` and `ERROR` checks are **not persisted** and won't appear in this view.

## What's next

* [**Discovery product page**](/products/number-verification/discovery.md) — background and integration patterns.
* [**Discovery error codes**](/products/number-verification/discovery/error-codes.md) — what each `error_code` means.
* [**Verification logs hub**](/enterprise-portal/verification-logs.md) — links to logs for the other products.
* [**Analytics**](https://docs.idlayr.com/enterprise-portal/analytics) — monitor usage and performance across your projects


---

# 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/enterprise-portal/verification-logs/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.