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

# Mobile

> Understanding native mobile device data in Verisoul fraud prevention

Sessions collected through the native Verisoul iOS or Android SDK include a `mobile` object with device facts read directly from the operating system — values that are more precise than what a browser or WebView can report.

The `mobile` object is returned in the `session` block of `POST /session/authenticate`, `POST /session/unauthenticated`, and `GET /session/{session_id}`.

## Mobile Data

### Example Mobile Data

```json theme={null}
{
  "mobile": {
    "brand": "Apple",
    "model": "iPhone",
    "system_memory_gb": 8,
    "boot_count": null,
    "system_uptime_days": 2.0,
    "battery_level": 0.82,
    "languages": ["en-US"],
    "oem_app_integrity": "unavailable",
    "oem_device_integrity": "unavailable"
  }
}
```

Sessions that did not come from the native mobile SDK (web and WebView-only sessions) return an empty object:

```json theme={null}
{
  "mobile": {}
}
```

### Fields

| Field                  | Description                                                                                                                                                    |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `brand`                | Device brand as reported by the operating system (e.g. `Apple`, `samsung`, `google`)                                                                           |
| `model`                | Device model as reported by the operating system (e.g. `SM-S921B`, `Pixel 6a`). iOS reports the generic device family (`iPhone`, `iPad`)                       |
| `system_memory_gb`     | Total device RAM in GB                                                                                                                                         |
| `boot_count`           | Number of times the device has been booted. Very low boot counts can indicate factory-reset devices common in device farms                                     |
| `system_uptime_days`   | Days since the device last booted                                                                                                                              |
| `battery_level`        | Battery charge level between 0 and 1                                                                                                                           |
| `languages`            | Device language preferences (e.g. `["en-US"]`)                                                                                                                 |
| `oem_app_integrity`    | Verdict from the platform's app attestation (Play Integrity app recognition and licensing on Android; App Attest on iOS): `passed`, `failed`, or `unavailable` |
| `oem_device_integrity` | Verdict from the platform's device attestation (Play Integrity device recognition on Android; DeviceCheck on iOS): `passed`, `failed`, or `unavailable`        |

### Platform availability

Not every field is collected on every platform. Fields the platform does not provide are `null`:

| Field                                               | iOS                         | Android |
| --------------------------------------------------- | --------------------------- | ------- |
| `brand`, `model`, `system_uptime_days`, `languages` | ✓                           | ✓       |
| `system_memory_gb`                                  | ✓                           | `null`  |
| `battery_level`                                     | ✓                           | `null`  |
| `boot_count`                                        | `null` (not exposed by iOS) | ✓       |

`oem_app_integrity` and `oem_device_integrity` return `unavailable` when the platform attestation was not performed or could not be validated for the session — for example, when the app has not integrated App Attest or the project has no DeviceCheck configuration on iOS. iOS sessions commonly read `unavailable` for both verdicts today; Android sessions carry Play Integrity verdicts on nearly all traffic.

## How mobile data relates to risk

The `mobile` object contains device facts only — the same way the `browser` and `device` objects report facts. All mobile risk interpretation (emulators, rooted or jailbroken devices, factory-reset boot profiles, integrity failures) is emitted through the `device` array of [Risk Signal Details](/signals-scores/risk-signals), so there is exactly one catalog of named risk signals.

Native sessions also improve existing `device` fields: `device.os` is sourced from native readings on both platforms, and on iOS `device.gpu`, `device.cpu_cores`, and `device.memory` are as well — fixing values the WebView masks, clamps, or misreports (Android GPU, core count, and memory follow once the SDK collects them; WebView values remain the fallback).