> 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.md). # Verification logs Verification logs let you see every check your projects have made — when it ran, what input was provided, what the result was, and any errors along the way. Logs are scoped **per project** and grouped **per product**. From the Portal's left-hand navigation, the **Logs** entry expands into a list of products. Each product has its own logs view because the fields that matter differ: a Secure SNA check is identified by `check_id` and resolves to a `match`; a SIM Swap check resolves to `no_sim_change`; a Discovery check returns a discovered MSISDN plus a user-confirmation outcome. ## Per-product log pages
Secure SNA logsBrowse Secure SNA checks. Fields include check_id, claimed MSISDN, status, match, callback delivery state, and timing./pages/idRn81uAvtuQAd2HTuZ6
SIM Swap logsBrowse SIM Swap checks. Fields include check_id, MSISDN, status, no_sim_change, and any MNO-side error context./pages/iqv0yeoQ8h6ktqwt3JDz
Discovery logsBrowse Discovery checks. Fields include check_id, discovered MSISDN (where available), confirmation outcome, and any user-decline signal./pages/KXCOPzFQEEifKesqQHqp
## Common capabilities Across every per-product logs view: * **Search by phone number.** Find every check for a specific MSISDN — useful when investigating a user-reported issue. * **Filter by status.** Narrow to `COMPLETED`, `EXPIRED`, `ERROR`, or in-flight checks. * **Filter by date range.** Inspect a specific time window. * **Drill into a specific check.** Click any row to see the full request, the timeline of state transitions, the callback delivery history, and (for device APIs) the redirect chain. ## Sandbox vs production Logs are kept for both sandbox and production projects, but **sandbox checks that resolve to `EXPIRED` or `ERROR` are not persisted** — they won't appear in the logs view. Successful and `match: false` sandbox checks are persisted normally. See [Sandbox testing](/get-started/sandbox-testing.md) for the full sandbox behaviour. Production checks are persisted in full regardless of outcome. ## What logs are useful for * **Debugging** — when an integration isn't behaving as expected, pull the specific `check_id` and inspect the full history. * **Customer support** — when a user reports a failed verification, search their MSISDN to find the check and the cause. * **Compliance / audit** — surface activity for a given time window or a specific MSISDN. * **Smoke testing a rollout** — after deploying a change, watch the logs to confirm checks are completing as expected. ## What logs are NOT * **Not aggregate analytics.** Logs are per-check rows, not dashboards of volume and success rate. Deeper analytics is a separate workstream — not in the Portal today. * **Not real-time monitoring.** Logs are queried on demand, not pushed. For real-time signal on operational incidents, use the [Status page](https://gitlab.com/4auth/product-documentation/-/blob/main/help/status.md) and your own callback-receiver observability. ## What's next Click into the per-product page that matches the product you're integrating. --- # 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.md?ask=&goal= ``` `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.