You are viewing v3.0.0 of the docs. The latest is v3.1.2.
Docs/Mobile SDK/Concepts

Data collection

In short

This page lists the data the SDK handles, so you can complete Apple's App Store privacy details and Google Play's Data safety form. The SDK uses no data for advertising or tracking. With proofUploadUrl unset (the default) and the default direct transport mode, the SDK sends no coordinates to Octet. Country and state lookups send coordinates to the operating system's geocoder or, in a gateway mode, to the gateway. See Location lookups.

What the SDK handles

Data Leaves the device Purpose Linked to identity Tracking
Precise location To Octet: only if you set proofUploadUrl or use a gateway mode. See Uploaded proofs and Location lookups. App functionality (location proofs) No¹ No
Coarse location To Octet: yes, as region codes in the usage counters, and in uploaded proofs if you set proofUploadUrl. See Usage counters. App functionality (country-level proofs), Analytics (region codes in the usage reports) No¹ No
Device ID (device fingerprint) Yes: license activation and usage reports, and bound into proofs App functionality, anti-fraud No¹ No
Product interaction (usage counters) Yes, unless telemetryEnabled = false Analytics: usage counters and per-proof events, no coordinates No No
Product interaction (daily usage record) Yes, always: one record per device per day Billing (active-device count), no location No No

¹ The device fingerprint is a pseudonymous one-way hash, not an account identity, and the SDK does not link this data to a user identity. On iOS the SDK keeps it in the Keychain, so it survives an app reinstall. On Android it changes when the app is reinstalled. If your app associates proofs with a user account, classify the data accordingly on your own form.

The daily usage record is new in 3.0 and cannot be turned off. See Metrics and usage reporting for what each report contains.

Uploaded proofs

With proofUploadUrl set, the SDK uploads each proof it generates.

Location lookups

To check a country or US state, the SDK turns the device's coordinates into a country or state code. Where that lookup runs depends on the transport mode (see Gateway routing).

  • Direct mode (the default). The SDK calls the operating system's geocoder: CLGeocoder on iOS, Geocoder on Android. Apple or Google receives the coordinates. The SDK sends no coordinates to Octet.
  • Gateway modes. The SDK sends the coordinates to {gateway}/ext/geo/reverse instead of the operating system's geocoder. With your own gateway (integratorGateway on iOS, INTEGRATOR_GATEWAY on Android), your gateway receives them and forwards the request to Octet. In octetGateway (OCTET_GATEWAY) mode, Octet's gateway receives them. The request carries the full-precision latitude and longitude and the SDK's activation credential, so the receiver can link the lookup to the activated device.

Two other requests carry no location:

  • IP-based country hint (iOS only). In direct mode, the iOS SDK requests the device's country from ipwho.is. The service sees the device's IP address and the standard User-Agent header that iOS adds to every request, which names your app, its build number and the iOS version. In a gateway mode the request goes to {gateway}/ext/ipgeo/ instead. Set TransportPolicy.thirdParty = .disable to skip the lookup. Octet can also switch the lookup off through remote configuration. The Android SDK makes no IP lookup.
  • Border-map updates. The SDK downloads updated border maps from /ext/geo/borders/ on the host it already uses. These requests carry no location and no device data.

Usage counters

The usage counters carry no coordinates. Octet also turns on additional usage reporting through remote configuration, without an app release, and it is on for all licenses. The usage reports also include:

  • The ISO 3166 country or subdivision code of each region your app checks (for example US or US-NY), with the verdict.
  • The country or subdivision code the device was resolved to by a background proof, whether or not your app asked about that region.
  • How the location was found, for example GPS or the cell network.
  • The proof's confidence and the time it took to produce, each reported as a range.
  • The app's location-permission state: granted, denied, not determined or restricted.
  • The category of an internal SDK error and where in the SDK it occurred.
  • Which remote-configuration variant the device received, with a pseudonymous device key.

None of these reports carries coordinates.

Set telemetryEnabled = false to stop all usage counters and the additional reporting. To keep the basic usage counters but not the additional reporting, set flagsEnabled = false, which stops the SDK from receiving remote configuration. These requests continue with telemetryEnabled = false:

  • License heartbeat. Renews the SDK's activation in the background.
  • Remote-configuration fetch. Sends the SDK version, platform, OS version, your app ID and a pseudonymous device key.
  • Daily usage record. See Metrics and usage reporting.

iOS: privacy manifest

The xcframework bundles a PrivacyInfo.xcprivacy privacy manifest. Xcode adds it to your app's privacy report at build time, so no action is needed beyond reviewing it alongside your own disclosures. It declares:

  • Collected data types. Precise location, coarse location and device ID, each for App Functionality. Coarse location should also be declared for Analytics, because of the region codes in the usage reports. The manifest in SDK 3.0.0 leaves that out, and a later release adds it, so add Analytics for coarse location in your App Store privacy details yourself. Product interaction, for Analytics (the usage counters) and Other (the daily usage record, used for billing). Every type is declared as not linked to the user and not used for tracking.
  • Tracking. None, and no tracking domains.
  • Required-reason APIs. System boot time, for the SDK's anchored license clock, and UserDefaults, for a one-time device-ID migration.

When you upgrade from 2.x, re-check your App Store privacy details so they include product interaction for the Other purpose.

Android: Data safety form

Android has no privacy manifest inside the library, so the table above is the statement to use for your app's Play Console Data safety form. The SDK's permissions merge into your manifest automatically. See Prerequisites for the permission list.

Where to go next

TermsPrivacy© 2026 Understone, Inc. d/b/a Octet