Device Information

The device information capabilities give businesses access to details about the physical mobile devices being used by their subscribers, and about how those devices are connected. This information comes from the mobile network, where devices are identified by their International Mobile Equipment Identity (IMEI) and other network-level identifiers, and where the serving radio cell reveals the technology a device is attached to. These signals help businesses verify device authenticity, detect fraud, optimize content delivery, and support insurance and device management use cases.

All capabilities in this family follow the CAMARA standard and require the user’s explicit authorization before any device information is accessed.

Device Identifier

What it does: Returns details about the physical mobile device currently being used by a specified mobile subscriber, including device identifiers (IMEI, IMEI SV, TAC) and device attributes (manufacturer and model).

When a mobile device connects to the network, it signals its International Mobile Equipment Identity (IMEI) to the operator. The IMEI is a unique 15-digit identifier assigned by the device manufacturer. An extended version called IMEI SV (Software Version) includes the device’s software version as a 16th digit. The first 8 digits of the IMEI are known as the Type Allocation Code (TAC), which identifies the manufacturer and model of the device.

Device Identifier allows a service provider to ask the operator: “What device is currently being used by this phone number?” The operator responds with the device’s identifiers and, optionally, its manufacturer and model name based on the TAC.

Who benefits:

• Insurance companies that need to automatically identify a device a customer wants to insure, eliminating manual entry errors
• Fraud prevention systems that want to verify that a customer is not using a device they claim to have broken or lost
• Content delivery platforms that need to optimize content for a particular device type or OS
• Device management platforms that track which physical devices are associated with corporate or enterprise accounts
• E-commerce platforms verifying that a user’s device matches what they claim during high-value transactions

Why it matters:

Device identity is a strong fraud signal. If a user reports a device as lost or stolen but is still actively using it on the network, that is a clear indicator of fraud. Similarly, knowing the device type allows businesses to tailor their services — delivering appropriate content formats, blocking access from unsupported devices, or detecting anomalies when a user suddenly switches from a high-end smartphone to a basic feature phone.

Unlike app-reported device data (which can be spoofed), the IMEI comes from the network and is significantly harder to fake. This makes it a more reliable source of device identity for security-sensitive use cases.

What information is returned:

The Device Identifier capability provides two operations:

1. Retrieve Identifier: Returns full device details including IMEI, IMEI SV, TAC, manufacturer, and model. Use this when you need the complete device fingerprint.

2. Retrieve Type: Returns only the device type information (TAC, manufacturer, and model). Use this when you only need to know what kind of device is being used, without needing the unique device identifier.

Both operations return a lastChecked timestamp indicating when the information was last confirmed to be accurate by the operator.

Example response:

{
  "lastChecked": "2024-02-20T10:41:38.657Z",
  "imei": "490154203237518",
  "imeisv": "4901542032375180",
  "tac": "49015420",
  "model": "3110",
  "manufacturer": "Nokia"
}

Use case: Insurance verification

A user opens a mobile insurance app and wants to insure their current device. Instead of asking the user to manually enter their device model (which is error-prone and can lead to incorrect coverage), the app calls Device Identifier. The API returns “iPhone 15 Pro Max” and the app pre-fills the insurance form with the correct device, ensuring accurate coverage and eliminating user friction.

Use case: Fraud detection

A user reports their phone as stolen and files an insurance claim. Before processing the claim, the insurance company calls Device Identifier to check whether the device is still active on the network. If the IMEI associated with the user’s number is still connecting to the network, the claim is flagged for further investigation — indicating the device may not actually be stolen.

Use case: Content optimization

A video streaming service wants to deliver the optimal video quality for each user’s device. Instead of relying on user-agent strings (which can be spoofed or inaccurate), the service calls Device Identifier to determine the actual device type. If the user is on a high-end device with a large screen, the service delivers 4K content. If the user is on a basic device, it delivers a lower resolution to save bandwidth and ensure smooth playback.

Connected Network Type

What it does: Returns the mobile communication technology that a specified mobile subscriber’s device is currently connected to — 2G, 3G, 4G, 5G, or UNKNOWN when the technology cannot be determined — together with the time that status was last updated.

This is the same indicator the user sees in their device’s status bar, but sourced from the network rather than from the device. The operator can infer it from the radio cell serving the device, since each cell supports a single technology. The API never queries the device itself.

Because the answer describes a live radio condition rather than a fixed attribute, it changes as the user moves: a subscriber walking from a city centre into a rural area may go from 5G to 4G to 3G within minutes. Each response carries a lastStatusTime so the caller can judge how fresh the reading is. When that field is absent, the information may be outdated.

Who benefits:

• Video and audio streaming platforms that want to pick an initial bitrate before the first buffer, rather than discovering the connection quality by stalling
• Mobile applications that defer large downloads, backups or software updates until the device is on a faster technology
• Customer support teams diagnosing “the app is slow” complaints, who need to know whether the user is on a degraded connection before escalating
• Field service and IoT platforms that need to know which technology their deployed devices are actually attaching to across a territory
• Network operations teams validating coverage and the progress of a 5G rollout against real subscriber experience

Why it matters:

Applications routinely guess at connection quality, and they guess badly. On-device APIs report what the operating system believes, which can be stale, restricted by platform permissions, or unavailable on the web. Asking the network directly gives an authoritative answer that does not depend on the application having been granted device-level access.

Knowing the technology before committing to an action avoids a whole class of poor experiences: starting a 4K stream that immediately stalls, pushing a several-hundred-megabyte update to a device on 3G, or timing out a request that was always going to be slow.

What information is returned:

The capability provides a single operation, Retrieve, which takes a phone number and returns:

The values map to what a device typically displays: 2G covers GSM, GPRS and EDGE (shown as “G” or “E”), 3G covers UMTS and HSPA (shown as “H” or “H+”), 4G covers LTE and LTE+, and 5G covers NR.

Network capabilities differ between technologies, and those differences are not part of this API. What a given technology means in terms of achievable throughput or latency must be agreed with the operator.

Example response:

{
  "lastStatusTime": "2024-02-20T10:41:38.657Z",
  "connectedNetworkType": "4G"
}

Use case: Adaptive streaming startup

A video platform is about to start playback on a mobile device. Rather than opening at the highest quality and stalling, it calls Connected Network Type. The response is 3G, so the player starts at a lower resolution and lets its adaptive bitrate logic climb from there. The user gets an immediate, uninterrupted start instead of several seconds of buffering.

Use case: Deferring a large download

A mobile application needs to push a substantial update to its users. Before starting, it checks the connected network type. For devices reporting 2G or 3G, it postpones the download and notifies the user that the update will be applied when a faster connection is available — avoiding a transfer that would consume the user’s data allowance slowly and likely fail.

Use case: Support diagnostics

A subscriber calls support to report that a service is unusably slow. The support tool queries Connected Network Type and sees 2G. The agent can immediately explain that the device has fallen back to a legacy technology in the user’s current location, resolving the call without opening a defect against the service itself.

Service availability: A connected network type cannot be provided for every identifier. If the phone number identifies a subscription for which the concept does not apply — a landline, for example — the API reports that the service is not applicable rather than returning a value.

Multi-SIM scenario handling

In scenarios where a main phone number is shared between multiple devices (such as connectivity plans that let you share your allowance with a smartwatch or eSIM-enabled tablet), the phone number passed to Device Identifier is treated as the secondary phone number. The API returns the identifier of the single device associated with that secondary phone number.

The primary device is usually allocated the same main and secondary phone numbers. Providing the main phone number to the API will return the identity of the primary device (typically the smartphone), not any associated devices.

Connected Network Type is subject to the same ambiguity: when several devices share a phone number, that number may not identify a single device to report a technology for. In that situation the API may return an error, a technology common to the multi-SIM group as a whole, or the technology of one device in the group, which may not be the intended one.

Two approaches resolve the ambiguity for either capability. Using the authorization code flow to obtain the access token identifies the intended device automatically. Alternatively, check with the SIM provider whether a unique secondary phone number is already associated with each device, and use that number to address the intended one.

Device Roaming Status

What it does: Returns whether a specified mobile subscriber’s device is currently roaming outside its home network and, when it is, the visited country information — the Mobile Country Code (MCC) and the corresponding ISO 3166 alpha-2 country codes.

A device enters a roaming situation when it connects to a network operated by a different carrier from the subscriber’s home operator. This typically happens when a user travels abroad, though domestic roaming exists in some markets as well. The roaming status is a live network observation: it changes as the user moves and the device associates with different networks.

Who benefits:

• Regulatory and compliance teams that must ensure transactions are performed within authorized jurisdictions or must block access from certain territories
• Fraud prevention systems that flag anomalies when a user’s claimed location does not match where their device is actually connected
• Financial services that impose restrictions on high-value or sensitive operations initiated from roaming sessions, to comply with local regulations or reduce fraud exposure
• Service delivery teams that need to warn users that accessing a particular service will incur roaming charges before they are committed

Why it matters:

Determining whether a device is roaming cannot be done reliably from the application side. VPNs, proxy services, and location spoofing make application-level location signals untrustworthy. The roaming status, sourced from the operator’s core network, reflects the device’s actual point of attachment to the mobile infrastructure and is significantly harder to falsify.

In regulated industries, knowing a user is roaming can be the difference between a compliant transaction and a legal violation. For fraud prevention, roaming is a strong signal: a card issued to a user registered in one country being used from a device roaming in another is a classic pattern for account takeover.

What information is returned:

Only roaming is guaranteed in every response. The optional fields are returned when the network is able to provide them.

Example response — device roaming in Germany:

{
  "roaming": true,
  "lastStatusTime": "2024-02-20T10:41:38.657Z",
  "countryCode": 262,
  "countryName": ["DE"]
}

Example response — device on home network:

{
  "roaming": false,
  "lastStatusTime": "2024-02-20T10:41:38.657Z"
}

Use case: Regulatory compliance check

A financial services application must confirm that a transaction is initiated from within a permitted jurisdiction. Before processing a sensitive operation, the application calls Device Roaming Status. If roaming: true, the system identifies the visited country and checks whether transactions from that territory are permitted. If not, the operation is blocked and the user is informed that the service is only available from their home network.

Use case: Fraud prevention signal

A user attempts to log in from a device roaming in a country that neither the user’s profile nor their recent activity suggests. The authentication system calls Device Roaming Status and, combined with other signals (new device, unusual time, large transaction), flags the session for additional verification or blocks it entirely.

Use case: Pre-transaction roaming charge warning

A content streaming service prepares to stream premium content to a subscriber. Before starting the stream, it queries Device Roaming Status. If roaming: true, the service displays a notification explaining that data charges from their home operator will apply and asks the user to confirm. This prevents unexpected roaming bills and reduces customer complaints.

Service availability: A roaming status cannot be provided for every identifier. Devices on fixed-line subscriptions, devices that have not recently registered with any network, or devices in situations where the network cannot determine their position do not have a roaming status. In those cases the API reports that the service is not applicable.

Privacy and data protection

Device identifiers are considered personal data under GDPR and similar regulations, as is the connection status of an identified subscriber. Both capabilities in this family require explicit user consent before returning any information. The operator ensures that only authorized service providers with valid user consent can access this data, and all access is logged for audit purposes.