Open-Gateway API V0

This API provides methods to obtain the capabilities of CAMARA project in mas-stack (capabilities based in V0).

This API allows to check the last time that the phone (device) - phone number association has changed

Introduction

The Device Swap API performs real-time checks on the last Device Swap event, providing real-time information about whether the SIM card associated with a user's phone number has been transferred to a different physical device.

Device Swap information can be invaluable for enhancing security, fraud detection, and ensuring compliance with regulatory requirements in various applications, apart from providing useful information of device upgrade trends in user segments.

This API is used by an application to get information about a mobile line's latest Device Swap date. It can be easily integrated and used through this secured API and allows SPs (Service Providers) to get this information in an easy and secured way. The API provides management of 2 endpoints answering 2 distinct questions:

When did the last Device Swap occur?
Has a Device Swap occurred during the last n hours?

Relevant terms and definitions

Device Swap: A Device Swap is a process in which the association between a user's mobile phone number (MSISDN) and a device (IMEI) is created for the first time or changes for any reasons.

API Functionality

The Device Swap API provides a programmable interface for developers and other users (capabilities consumers) to request the last date of a device swap performed on the mobile line, or, to check whether a device swap has been performed during a past period.

The API provides 2 operations:

POST retrieve-date: Provides timestamp of latest device swap for a given phone number. If no device swap has been performed, the API will return the first phone number usage in the device (the timestamp of the first time that the phone number was connected to the network, it is, the first time that the SIM is installed in the device) by default. It will return an empty string in case is not possible to retrieve the date (e.g. in case local regulations are preventing the safekeeping of the information for longer than the stated period, or in some edge error cases). In case no data is available in the operators records (e.g. no recorded event), API will return a 422 error.
POST check: Checks if device swap has been performed during a past period (defined in the request with 'maxAge' attribute) for a given phone number, the API will return boolean response (true/false), indicating that the device has been swapped or not in the specified period. In case the phone number has never been installed in a device, or no data is available in the operators records (e.g. database error), API will return a 422 error.

So, when consuming this operation, the following scenarios will exist:

The API is consumed in 3-legged:

If no phoneNumber is provided in the body, the API will return in the response the information of the phoneNumber that is associated to the access token.
If the phoneNumber is provided in the body, the API will return in the response the information of that phone number if it matches the one associated to the access token.
If the phoneNumber provided in the body does not match the one associated to the access token, the API will respond with HTTP 403 INVALID_TOKEN_CONTEXT.

The API is consumed in 2-legged:

If no phoneNumber is provided in the body, the API will respond with HTTP 400 INVALID_ARGUMENT.
If the phoneNumber is provided in the body, the API will return in the response the information of the phoneNumber provided in the body.

Resources and Operations overview

The API provides the following endpoints:

An operation to retrieve last date in which the device of the end-user was swapped.
An operation to check if the SIM of the end-user has been installed in a different device during a past period

Authorization and authentication

The "Camara Security and Interoperability Profile" provides details on how a client requests an access token. Please refer to Identify and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the Profile.

Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.

It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.

This API provides the customer with the ability to compare the information it (Service Provider, SP) has for a particular mobile phone user with that on file (and verified) by the mobile phone user's Operator in their own KYC records, in order for the SP to confirm the accuracy of the information and provide a specific service to the mobile phone user.

Relevant Definitions and concepts

KYC: stands for Know Your Customer and it is the process of a business verifying the identity of their clients and assessing their suitability, along with the potential risks of illegal intentions towards the business relationship.
Match Score: a numerical value that quantifies the similarity between two pieces of text based on the words they contain. This score is often used in various applications like text comparison, plagiarism detection, information retrieval, and natural language processing. The score typically reflects how well the words in one text match the words in another text. In the context of this API, this score will be used to determine how much does the input information looks like the information stored in the Operator's system. Unless otherwise captured in the specification, score will use the Jaro-Winkler distance algorithm for all countries. This parameter, as optional, will be returned depending on the capability of the Operator to calculate the scoring value. This means that not all Operators will implement this functionality or won't have the requested parameter available. It can happen that an Operator implements the score functionality but, for whatever reason, is not able to calculate it based on the client's input or the related stored information. For these cases, the score property related won't be returned in the response. The range of score values is between "0" and "100", where higher scores indicate a higher similarity between the two compared parameters.

API Functionality

This API allows API clients to verify the matching of a number of attributes related to a customer identity against the account data bound to their phone number. The API is intended to be used in the following scenarios, for example:

To verify the user personal data during the digital registration of an account to a 3rd party service.
To prevent fraud, wrong or imprecise information, and/or facilitate the onboarding of a mobile phone user to a 3rd party service.

The API supports a multi-level hierarchy of property validation. In addition to the initial verification of the phoneNumber, an additional idDocument validation may occur based on different Operator requirements. This means that, in those cases, if the value of idDocument is not provided or it does not match the one bound to the specific phone number in the Operator systems, the operation will return an error.

Resources and Operations overview

The API provides the following endpoint:

An endpoint to verify the matching of a number of attributes related to a mobile phone user identity against the account data bound to their phone number.

Authorization and authentication

Summary

This API provides the customer with the ability to check if the user of the line is older than a provided age, in order to provide API customer's age-restricted services, access to its age-restricted website etc..

API functionality

The API defines one service endpoint:

POST /verify

Takes the network subscription identifier (e.g. the mobile phone number for a mobile network subscriber) and checks if the age of the subscriber is older than the age threshold in the request. Additionally, as optional function, provides (1) if age check is done against another form of official identification (Note) or not (verifiedStatus), (2) an overall score of how certain is the response using both information provided in the request and information that the Operator holds(identityMatchScore), (3) an indicator on whether the subscription has any kind of content lock (contentLock) and (4) an indicator on whether the subscription has any kind of parental control activated (parentalControl). Note: Depending on the country, credit-check or other mechanism can be used instead of official identification for Age Verification. For details, please contact API Provider.

Inputs

The endpoint request body is a JSON object with the following parameters:

phoneNumber: The network subscription identifier (i.e. the phone number of the subscriber). [Required only in case a 2-legged flow has been agreed between API Provider and API Consumer following CAMARA directives; otherwise, phoneNumber must not be included]
ageThreshold: The age threshold from which the age of the user must be compared. [Required]
any of idDocument, name, givenName, familyName, middleNames, familyNameAtBirth, birthdate, email; additional subscriber's information to be checked in order to confirm that the subscriber is the contract's owner [Optional]
includeContentLock and includeParentalControl: These two flags allow the API Client to indicate that the corresponding response properties contentLock and parentalControl should be returned. Its implementation is optional for the API Provider, so in such cases, these parameters will be ignored. [Optional]

Outputs

If successful, a JSON object is returned containing the following data:

ageCheck: Indicate 'true' when the age of the user is the same age or older than the age threshold (age >= age threshold), and 'false' if not (age < age threshold). Otherwise, 'not_available'.
verifiedStatus: true if the information provided was checked against another form of official identification (Note), otherwise false. Note: Depending on the country, credit-check or other mechanism can be used instead of official identification for Age Verification. For details, please contact API Provider.
identityMatchScore: The overall score of identity information available in the Operator, information either provided in the request body comparing it to the one that the MNO holds or directly using internal MNO's information. It is optional for the Operator to return the Identity match score.
contentLock: Indicates if the subscription associated with the phone number has any kind of content lock (i.e certain web content blocked).
parentalControl: Indicates if the subscription associated with the phone number has any kind of parental control activated.

Errors

If the authentication access token is not valid, a 401 UNAUTHENTICATED error is returned
If the API call contains a formatting or other any other syntactic error, a 400 INVALID_ARGUMENT error is returned.
If the network subscription cannot be identified from the provided parameters (e.g. the subscription identifier is not associated with any customer of the CSP), a 404 IDENTIFIER_NOT_FOUND error is returned.
If the API consumer has a valid access token that does not have the required scope to obtain Age Verification information for the specified network subscription, then a 403 PERMISSION_DENIED error is returned.

Additional CAMARA error responses

The list of error codes in this API specification is not exhaustive. Therefore the API specification may not document some non-mandatory error statuses as indicated in CAMARA API Design Guide. Please refer to the CAMARA_common.yaml of the Commonalities Release associated to this API version for a complete list of error responses. The applicable Commonalities Release can be identified in the API Readiness Checklist document associated to this API version. As a specific rule, error 501 - NOT_IMPLEMENTED can be only a possible error response if it is explicitly documented in the API.

Identifying the phone number from the access token

This API requires the API consumer to identify a phone number as the subject of the API as follows:

When the API is invoked using a two-legged access token, the subject will be identified from the optional phoneNumber field, which therefore MUST be provided.
When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.

This approach simplifies API usage for API consumers using a three-legged access token to invoke the API by relying on the information that is associated with the access token and was identified during the authentication process.

Error handling:

If the subject cannot be identified from the access token and the optional phoneNumber field is not included in the request, then the server will return an error with the 422 MISSING_IDENTIFIER error code.
If the subject can be identified from the access token and the optional phoneNumber field is also included in the request, then the server will return an error with the 422 UNNECESSARY_IDENTIFIER error code. This will be the case even if the same phone number is identified by these two methods, as the server is unable to make this comparison.

Authorization and authentication

The "Camara Security and Interoperability Profile" provides details of how an API consumer requests an access token. Please refer to Identity and Consent Management (https://github.com/camaraproject/IdentityAndConsentManagement/) for the released version of the profile.

The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.

In cases where personal data is processed by the API and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of three-legged access tokens is mandatory. This ensures that the API remains in compliance with privacy regulations, upholding the principles of transparency and user-centric privacy-by-design.

Further info and support

(FAQs will be added in a later version of the documentation)

Summary

The CAMARA Know Your Customer (KYC) Tenure API allows for verification that a network subscriber has been a customer of the Communications Service Provider (CSP) for a specified minimum length of time so as to establish a level of trust for the associated network subscription identifier.

API functionality

The API defines one service endpoint:

POST /check-tenure

Takes the network subscription identifier (e.g. the mobile phone number for a mobile network subscriber) and the specified minimum tenure date to validate for the associated network subscription. This endpoint will respond with a confirmation of whether or not the network subscriber tenure is longer than the specified date timestamp, optionally supplemented with details of the subscription contract type.

To call this endpoint, the API consumer must first obtain a valid access token with the specified scope from the specified token endpoint, which is then passed to the endpoint via the Authorization header. For more details on access token processing, see below.

Inputs

The endpoint request body is a JSON object with the following parameters:

tenureDate: The date from which continuous tenure of the identified network subscriber is required to be confirmed. This field is always required.
phoneNumber: The network subscription identifier (i.e. the phone number of the subscriber). This field is only required if no network subscription identifier is associated with the access token.

Outputs

If successful, a JSON object is returned containing the following data:

tenureDateCheck: true when the identified network subscription has had valid tenure since tenureDate, otherwise false
contractType: The network subscription account type, if known

An example of a JSON response object is as follows:

{
    "tenureDateCheck": true,
    "contractType": "PAYM"
}

Errors

If the authentication token is missing, not a valid token, or is no longer valid, a 401 UNAUTHENTICATED error is returned

If the API call contain a formatting or other error, a 400 INVALID_ARGUMENT error is returned. This includes cases where:

The tenureDate is in the future (greater than the current date)
The date format is invalid or does not conform to RFC 3339 / ISO 8601 (YYYY-MM-DD)

If the network subscription cannot be identified from the provided parameters (e.g. the subscription identifier is not associated with any customer of the CSP), a 404 IDENTIFIER_NOT_FOUND error is returned.

If the API consumer has a valid access token that does not have the required scope to obtain tenure information for the specified network subscription, then a 403 PERMISSION_DENIED error is returned.

Additional CAMARA error responses

The list of error codes in this API specification is not exhaustive. Therefore the API specification may not document some non-mandatory error statuses as indicated in CAMARA API Design Guide.

Please refer to the CAMARA_common.yaml of the Commonalities Release associated to this API version for a complete list of error responses. The applicable Commonalities Release can be identified in the API Readiness Checklist document associated to this API version.

As a specific rule, error 501 - NOT_IMPLEMENTED can be only a possible error response if it is explicitly documented in the API.

Identifying the phone number from the access token

This API requires the API consumer to identify a phone number as the subject of the API as follows:

When the API is invoked using a two-legged access token, the subject will be identified from the optional phoneNumber field, which therefore MUST be provided.
When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.

Error handling:

If the subject cannot be identified from the access token and the optional phoneNumber field is not included in the request, then the server will return an error with the 422 MISSING_IDENTIFIER error code.
If the subject can be identified from the access token and the optional phoneNumber field is also included in the request, then the server will return an error with the 422 UNNECESSARY_IDENTIFIER error code. This will be the case even if the same phone number is identified by these two methods, as the server is unable to make this comparison.

Authorization and authentication

Further info and support

(FAQs will be added in a later version of the documentation)

The Consent Info API allows API Consumers to easily validate whether they have the necessary permissions to process User's personal data for a specific Purpose before using other CAMARA APIs. It provides a simple true/false response and, when applicable, a URL to direct the User to manage their Consent.

Introduction

This API facilitates compliance with privacy regulations and promotes transparency with Users by providing a standardized way to check whether, for example, the User has given their Consent or opted out of data processing. Key inputs include the specific scope(s) of access being requested (i.e. the CAMARA API(s) operations to which the data processing refers), the Purpose for data processing, and a User identifier (either explicitly provided or derived from a three-legged access token). The API responds with the validity status of the data processing, and, when applicable, can provide a capture URL for the API Consumer to manage it.

Relevant terms and definitions

Consent: An explicit opt-in action that the User takes to allow processing of personal data. Consent grants the API Consumer access to a set of scopes related to the User for a specific Purpose.
Purpose: The reason for which personal data will be processed by an API Consumer. CAMARA defines a standard set of Purposes which can be used by API Consumers to specify the reason for their intended personal data processing. CAMARA uses the W3C Data Privacy Vocabulary (DPV) to represent these purposes e.g. dpv:FraudPreventionAndDetection or dpv:RequestedServiceProvision.
Scope: A string representing the specific access rights or actions an API Consumer requests from the User for their data (e.g., "location-verification:verify"). A request can contain multiple scopes.

API Functionality

This API enables the API Consumer to determine whether their data processing is permitted for a given User, scope(s) and Purpose.

Specifically, the API:

Provides the data processing validity status: The API returns statusValidForProcessing, a boolean flag that indicates whether the requested data processing is currently permitted (true) or not (false).
Provides an explanation if invalid: If data processing is not permitted, the response includes a statusReason field to explain why.
Offers a Capture URL (if requested): If the status is not valid because user action is required, and the API Consumer sets requestCaptureUrl to true, the API will return a captureUrl field that can be presented to the User. This URL directs them to the API Provider's secure Consent capture channel, where they can provide or renew their Consent.

Importantly, this API does NOT delegate Consent capture to the API Consumer but rather empowers the API Consumer to present the API Provider's Consent capture URL at the most opportune time and place. The actual Consent capture occurs within the API Provider's secure environment, ensuring the User's authentication with the API Provider.

Authorization and authentication

The specific authorization flows to be used will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared Purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.

Identifying the phone number from the access token

This API requires the API consumer to identify a phone number as the subject of the API as follows:

When the API is invoked using a two-legged access token, the subject will be identified from the optional phoneNumber field, which therefore MUST be provided.
When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.

Error handling:

If the subject cannot be identified from the access token and the optional phoneNumber field is not included in the request, then the server will return an error with the 422 MISSING_IDENTIFIER error code.
If the subject can be identified from the access token and the optional phoneNumber field is also included in the request, then the server will return an error with the 422 UNNECESSARY_IDENTIFIER error code. This will be the case even if the same phone number is identified by these two methods, as the server is unable to make this comparison.

Additional CAMARA error responses

The list of error codes in this API specification is not exhaustive. Therefore the API specification may not document some non-mandatory error statuses as indicated in CAMARA API Design Guide.

As a specific rule, error 501 - NOT_IMPLEMENTED can be only a possible error response if it is explicitly documented in the API.

Further info and support

(FAQs will be added in a later version of the documentation)

The API can be used to check whether the subscriber of the phone number has changed. A common scenario is when Application service provider (ASP) wants to check whether there has been a change in the user associated with the phone number after the specified date. This allows the ASP to ensure that a phone number is correctly linked to a user and prevent the mis-delivery of SMS messages.

For example, below are potential scenarios:

Scenario 1
- Pre-conditions
  - User A signed a contract with MNO A for the phone number '+123456789' on October 9, 2023, and is still using it.
  - User A also signed contracts with ASP A on December 22, 2023 for its services.
  - ASP A holds the contract date (2023-12-22) and the phone number (+123456789) for User A.
  - Currently, on November 2, 2024, ASP A wishes to send a SMS message to User A.
- Potential operations
  - ASP A sends a request with specified date (2023-12-22) and phone number (+123456789) to the Number Recycling API.
  - The API response sets to 'false', indicating that there has not been a change in the user associated with the phone number.
- Post-conditions
  - ASP A decides to send the SMS message to User A.
- By following these steps, ASP A ensures that a phone number is linked to User A.

Note:

When API receives a request with specified date on which a user signed a contract with MNO, the API respond sets to 'false'(e.g., 2023-10-09 in the Scenario 1 of the figure above).
- Scenario 2
  - Pre-conditions
    - User A signed a contract with MNO A for the phone number '+123456789' on October 9, 2023, and canceled it on February 25, 2024. Subsequently, User B signed a contract with MNO A for the same phone number on September 21, 2024, and is still using it.
    - User A also signed contracts with ASP A on December 22, 2023 for its services.
    - ASP A holds the contract date (2023-12-22) and the phone number (+123456789) for User A.
    - Currently, on November 2, 2024, ASP A wishes to send a SMS message to User A.
  - Potential operations
    - ASP A sends a request with specified date (2023-12-22) and phone number (+123456789) to the Number Recycling API.
    - The API response sets to 'true', indicating that there has been a change in the user associated with the phone number.
  - Post-conditions
    - ASP A decides to stop sending the SMS message to User A and contacts User A by mail.
  - By following these steps, ASP A ensures that a phone number is not linked to User A and prevents the mis-delivery of the SMS message.

Note:

When the API receives a request with specified date during which there is no contract with MNO for the phone number, the API respond sets to 'true'(e.g., the period between 2024-02-25 and 2024-09-20 in the Scenario 2 of the figure above).

Authorization and authentication

Identifying the phone number from the access token

This API requires the API consumer to identify a phone number as the subject of the API as follows:

When the API is invoked using a two-legged access token, the subject will be identified from the optional phoneNumber field, which therefore MUST be provided.
When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.

Error handling:

If the subject cannot be identified from the access token and the optional phoneNumber field is not included in the request, then the server will return an error with the 422 MISSING_IDENTIFIER error code.
If the subject can be identified from the access token and the optional phoneNumber field is also included in the request, then the server will return an error with the 422 UNNECESSARY_IDENTIFIER error code. This will be the case even if the same phone number is identified by these two methods, as the server is unable to make this comparison.

Additional CAMARA error responses

This API provides the ability to retrieve a device location.

Introduction

With this API, API consumers can retrieve the area where a certain user device is localized. The area provided in the response could be described:

by a circle determined by coordinates (latitude and longitude) and a radius.
by a simple polygon delimited by segments connecting consecutively an array of coordinates (points). The last point connects to the first point to delimit a closed shape bounded with straight sides.

The retrieved shape depends on the network conditions at the device's location and any of the supported shapes could be received.

The requester could optionally ask for

a freshness of the localization information by providing a maxAge ("I want a location not older than 600 seconds").
an accuracy of the localization information by providing a maxSurface ("I want a location not larger than 1000000 square meters").

The result accuracy depends on the network's ability and accuracy to locate the device.

Additionally to location information, the answer will also provide indication about the location time.

Location retrieval API could be useful in scenarios such as:

Fraud protection to ensure a given user is located in the region, country or location authorized for financial transactions
Verify the GPS coordinates reported by the app on a device to ensure the GPS was not faked e.g. for content delivery with regional restrictions
Contextual-based advertising, to trigger advertising after verifying the device is in the area of interest
Smart Mobility (Vehicle/bikes renting): obtain the location of a vehicle/bike to guarantee they are rented correctly

Note: Location is in most jurisdictions considered to be sensitive data and thereby consent by device owner/user must be verified before providing it to the developer.

Relevant terms and definitions

Device: A device refers to any physical entity that can connect to a network and participate in network communication.
Area: It specifies the geographical surface where a device may be physically located.
Max Age: Maximum age of the location information which is accepted for the location retrieval (in seconds).
- Absence of maxAge means that "any age" is acceptable for the client. In other words, this is like maxAge=infinite. The system will return lastLocationTime in the response. If the system is not able to provide location, an error 422 with code LOCATION_RETRIEVAL.UNABLE_TO_LOCATE is sent back.
- maxAge=0 means that a fresh calculation is requested by the client. If the system is not able to provide the fresh location, an error 422 with code LOCATION_RETRIEVAL.UNABLE_TO_FULFILL_MAX_AGE is sent back.
Last Location Time : Last date and time when the device was localized.
Max Surface: Maximum surface in square meters which is accepted by the client for the location retrieval.
- absence of maxSurface means that "any surface size" is acceptable for the client.
- API implementation could specify the minimum acceptable maxSurface in the documentation (for example a minimum of 10000 square meters are allowed).
- If the system is not able to provide an area with a surface acceptable with the client request, an error 422 with code LOCATION_RETRIEVAL.UNABLE_TO_FULFILL_MAX_SURFACE is sent back.
- Note: if both maxAge and maxSurface requirements fail, the system can either send back one or the other error code.

API Functionality

The API exposes a single endpoint/operation:

/retrieve : Retrieve where the device is localized. The operation returns:
- a localization defined either as a circle, with the center specified by the latitude and longitude, and a radius for answer accuracy, or as polygon defined by the array of points delimiting its boundary.
- a timestamp with the location information freshness.

Authorization and authentication

Identifying the device from the access token

This API requires the API consumer to identify a device as the subject of the API as follows:

When the API is invoked using a two-legged access token, the subject will be identified from the optional device object, which therefore MUST be provided.
When a three-legged access token is used however, this optional identifier MUST NOT be provided, as the subject will be uniquely identified from the access token.

Error handling:

If the subject cannot be identified from the access token and the optional device object is not included in the request, then the server will return an error with the 422 MISSING_IDENTIFIER error code.
If the subject can be identified from the access token and the optional device object is also included in the request, then the server will return an error with the 422 UNNECESSARY_IDENTIFIER error code. This will be the case even if the same device is identified by these two methods, as the server is unable to make this comparison.

Multi-SIM scenario handling

In multi-SIM scenarios, where more than one mobile device is associated with the phone number given as input in the API call (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify the device whose location is to be verified. Check with the API provider what is the expected behaviour when a phone number belonging to a multi-SIM group is used as the device identifier, as the API may response with:

an error indicating that that phone number is not supported for this API, or
the location of a single device in the multi-SIM group, if one of the devices is considered linked to the main SIM and this concept is supported by the operator, or
a location value that combines the location of all the SIMs associated to the requested phone number.

Possible solutions to make the scenario more deterministic include:

Using preferably the authorisation code flow to obtain an access token, which will automatically identify the intended device.
Identifying the intended device from a unique identifier for that device, such as its source IP address and port.
Check with the API provider whether a unique "secondary" phone number is already associated with each device and use the secondary phone number to identify the intended device if available.

Additional CAMARA error responses

The list of error codes in this API specification is not exhaustive. Therefore the API specification may not document some non-mandatory error statuses as indicated in CAMARA API Design Guide.

As a specific rule, error 501 - NOT_IMPLEMENTED can be only a possible error response if it is explicitly documented in the API.

Further info and support

(FAQs will be added in a later version of the documentation)

This API returns details of the physical mobile device currently being used by a specified mobile subscriber.

Introduction

The following information can be returned:

A unique network identifier for the specific device itself (IMEI SV and IMEI)
A network identifier for the device make and model (IMEI Type Allocation Code)
Device manufacturer name and model

This information can be useful in a number of scenarios, such as the following:

For insurance purposes, to automatically identify a device that a customer wishes to insure
For security / fraud reasons, to establish that a customer is not using a device they claim to have broken or lost
For service delivery reasons, to optimise content for a particular device or OS type

Mobile devices are allocated a unique identifier by the manufacturer, known as the International Mobile Equipment Identity, or IMEI. The current software version (SV) of the device can be appended to this, in which case the identifier is known as the IMEI SV. This identifier is signalled to the mobile network when the device connects, both to confirm that the device is not blocked, and also allow device dependent network configurations to be implemented.

The IMEI is a 15 digit integer, and the IMEI SV is a 16 digit integer:

The first 8 digits are known as the Type Allocation Code (TAC), and identify the manufacturer and model of the device
The following 6 digits are the serial number of the device for that TAC
For IMEI, the remaining digit is a check digit
For IMEI SV, the remaining two digits are the software version

TACs are issued and managed by the GSMA, and can be queried using the GSMA IMEI database.

The mobile network associates this device identifier with the mobile subscription currently using the device. The mobile subscription is defined by the Subscriber Identity Module (SIM) currently active in the mobile device. This may be a removable SIM or an eSIM. In either case, it is possible for the association between the device identifier and subscription to change - for example, when a physical SIM is transferred to another mobile device.

Relevant terms and definitions

Identifier for the mobile subscription: the phone number (i.e. MSISDN) addressing the mobile subscription.
Identifier for the physical mobile device: the IMEI or IMEI SV of the physical mobile device.
Type Allocation Code (TAC): the first 8 digits of the IMEI, identifying the manufacturer and model of the device.
Last Checked: date and time that the information was last confirmed by the mobile operator to be correct.

API Functionality

The API provides 2 operations:

POST retrieve-identifier: get details about the specific device being used by a given mobile subscriber, including IMEI / IMEI SV and the type of device. The response always contains imei.
POST retrieve-type: get details only about the type (i.e. manufacturer and model) of device being used by a given mobile subscriber. The response always contains tac.

Both responses always contain a lastChecked field, indicating when the information provided was last confirmed to be correct. Other response parameters are implementation dependent, and thus optional.

An example of a JSON response object is as follows:

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

Error handling

Errors may be returned for the following reasons. Note that this list is not exhaustive.

400 INVALID_ARGUMENT:

The API request is not compliant with this OAS definition

401 UNAUTHENTICATED:

The access token is not a valid access token for the API provider
The access token was valid but has now expired

403 PERMISSION_DENIED:

The access token does not have the required scope for the endpoint being called
The end user has not consented to the API consumer getting access to the device identifier information

404 IDENTIFIER_NOT_FOUND:

The phone number in the request is not managed by the API provider

422 SERVICE_NOT_APPLICABLE:

A device identifier cannot be provided for the identified subscription. For example, the phone number might identify a landline.

Additional CAMARA error responses

The list of error codes in this API specification is not exhaustive. Therefore the API specification may not document some non-mandatory error statuses as indicated in CAMARA API Design Guide.

As a specific rule, error 501 - NOT_IMPLEMENTED can be only a possible error response if it is explicitly documented in the API.

Authorization and authentication

Multi-SIM scenario handling

In scenarios where a main phone number is shared between multiple devices, each of which has its own individual "secondary" phone number (e.g. connectivity plans that let you share your airtime and data allowances with a smartwatch or eSIM-enabled tablet), the phone number passed by the API consumer will be treated as the secondary phone number, and hence the identifier returned will be that of the single device associated with that phone number (e.g. smartphone, smartwatch, or eSIM-enabled tablet).

In such scenarios, the "primary" device is usually allocated the same main and secondary phone numbers, and hence providing the main phone number to the API will return the identity of the primary device (usually the smartphone) and not any associated devices.

Further info and support

(FAQs will be added in a later version of the documentation)

This API provides the customer with the ability to query to which Mobile Communication Technology it is connected to.

Introduction

Connected Network Type

The API consumer is able to query the device's connected network type. The API provider can determine this in various ways. For example, the network type can be inferred from the specific radio cell to which the device is connected, as radio cells only support a single technology. It is important to note that the API does not query the device directly.

Relevant terms and definitions

Identifier for the mobile subscription: the phone number (i.e. MSISDN) addressing the mobile subscription whose connected network type is queried. It is the only device identifier accepted by this API.
Connected Network Type : This Type identifies the mobile technology of the network that the device is connected to (e.g. 4G, 5G, etc). It is the same as what is displayed on the device (e.g. on mobile phones). When the device moves across different areas of the network, the technology may change. As each technology is different, network capabilities may differ and MUST be checked with the API provider.
- 2G, if device is connected to the 2G network technology (alternative indicators such as "G" or "E" may be displayed on the device)
- 3G, if device is connected to the 3G network technology (alternative indicators such as "H" or "H+" may be displayed on the device)
- 4G, if device is connected to the 4G network technology (alternative indicators such as "LTE" or "LTE+" may be displayed on the device)
- 5G, if device is connected to the 5G network technology
- UNKNOWN if connection [technology] can not be determined
LastStatusTime : This property specifies the time when the status was last updated. Its presence in the response indicates the freshness of the information, while its absence implies the information may be outdated or its freshness is uncertain.

API Functionality

The API exposes following capabilities:

Connected Network Type

The endpoint POST retrieve allows to get connected Network Type.

Error handling

Errors may be returned for the following reasons. Note that this list is not exhaustive.

400 INVALID_ARGUMENT:

The API request is not compliant with this OAS definition

401 UNAUTHENTICATED:

The access token is not a valid access token for the API provider
The access token was valid but has now expired

403 PERMISSION_DENIED:

The access token does not have the required scope for the endpoint being called

404 IDENTIFIER_NOT_FOUND:

The phone number in the request is not managed by the API provider

422 SERVICE_NOT_APPLICABLE:

A connected network type cannot be provided for the identified subscription. For example, the phone number might identify a landline.

Authorization and authentication

Multi-SIM scenario handling

In multi-SIM scenarios where more than one mobile device is associated with a phone number (e.g. a smartphone with an associated smartwatch), it might not be possible to uniquely identify from that phone number the device for which the connected network type should be returned. In such a scenario, the API may:

respond with an error, or
return a common connected network type for the multi-SIM group as a whole, or
return the connected network type for a single device in the multi-SIM group, which may not be the intended device.

Possible solutions in such a scenario include:

Using the authorisation code flow to obtain an access token, which will automatically identify the intended device
Check with the SIM provider whether a unique "secondary" phone number is already associated with each device, and use the secondary phone number to identify the intended device if available.

Further info and support

(FAQs will be added in a later version of the documentation)

Base URLs

production

staging

Authentication

LocationRetrievalopenId openIdConnect

Resources

Resource	Description
Device Swap	API operation of device API.
KycMatch	Operations to match a customer identity against the account data bound to their phone number.
Kyc Age Verification	Operations to verify the age of a user.
KycTenure	Check details about the length of tenure of the subscriber
Consent Info	API operation of Consent Info API
NumberRecycling	APIs to check whether there has been a change in the subscriber associated with the phone number after the specified date.
LocationRetrieval	Retrieve the location of a device
DeviceIdentifier	Retrieve details about the device being used by a mobile subscriber
ConnectedNetworkType	Operations to get the network type the device is connected to

Property	Type	Description
`code` *	string	code of the error
`title` *	string	title of the error
`ref` *	string	ref of the error
`details` *	string	details of the error

Property	Type	Description
`code` *	string	code of the error
`title` *	string	title of the error
`ref` *	string	ref of the error
`details` *	string	details of the error

Property	Type	Description
`code` *	string	code of the error
`title` *	string	title of the error
`ref` *	string	ref of the error
`details` *	string	details of the error

Property	Type	Description
`code` *	string	code of the error
`title` *	string	title of the error
`ref` *	string	ref of the error
`details` *	string	details of the error

Property	Type	Description
`code` *	string	code of the error
`title` *	string	title of the error
`ref` *	string	ref of the error
`details` *	string	details of the error

Property	Type	Description	Constraints	Default
`phoneNumber` *	string	A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.	pattern: ^\+[1-9][0-9]{4,14}$
`maxAge`	integer (int32)	Period in hours to be checked for device swap. Valid range: 1-2400 hours.		240

Property	Type	Description	Constraints
`phoneNumber`	string	A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.	pattern: ^\+[1-9][0-9]{4,14}$
`idDocument`	string	Id number associated to the official identity document in the country. It may contain alphanumeric characters.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`name`	string	Complete name of the customer, usually composed of first/given name and last/family/sur- name in a country. Depending on the country, the order of first/give name and last/family/sur- name varies, and middle name could be included. It can use givenName, middleNames, familyName and/or familyNameAtBirth. For example, in ESP, name+familyName; in NLD, it can be name+middleNames+familyName or name+middleNames+familyNameAtBirth, etc.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`givenName`	string	First/given name or compound first/given name of the customer.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`familyName`	string	Last name, family name, or surname of the customer.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`nameKanaHankaku`	string	Complete name of the customer in Hankaku-Kana format (reading of name) for Japan.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`nameKanaZenkaku`	string	Complete name of the customer in Zenkaku-Kana format (reading of name) for Japan.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`middleNames`	string	Middle name/s of the customer.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`familyNameAtBirth`	string	Last/family/sur- name at birth of the customer.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`address`	string	Complete billingAddress of the customer. For some countries, it is built following the usual concatenation of parameters in a country, but for other countries, this is not the case. For some countries, it can use streetName, streetNumber and/or houseNumberExtension. For example, in ESP, streetName+streetNumber; in NLD, it can be streetName+streetNumber or streetName+streetNumber+houseNumberExtension.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`streetName`	string	Name of the street of the customer's billingAddress. It should not include the type of the street.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`streetNumber`	string	The street number of the customer's billingAddress. Number identifying a specific property on the 'streetName'.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`postalCode`	string	Zip code or postal code	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`region`	string	Region/prefecture of the customer's billingAddress	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`locality`	string	Locality of the customer's billingAddress	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`country`	string	Country of the customer's billingAddress. Format ISO 3166-1 alpha-2	pattern: ^[A-Z]{2}$
`houseNumberExtension`	string	Specific identifier of the house needed depending on the property type. For example, number of apartment in an apartment building.	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`birthdate`	string (date)	The birthdate of the customer, in RFC 3339 / ISO 8601 calendar date format (YYYY-MM-DD).
`email`	string (email)	Email billingAddress of the customer in the RFC specified format (local-part@domain).	pattern: ^(?!.(;\|'\|"\|\\\|alert\(\|%\|prompt\(\|\.\./\|<\|>\|\[\|\]\|!\|#\|--)).$
`gender`	string () MALEFEMALEOTHER	Gender of the customer (Male/Female/Other).

Property	Type	Description	Constraints
`idDocumentMatch`	string () truefalsenot_available	Indicates whether Id number associated to the ID document of the customer matches with the one on the Operator's system.
`nameMatch`	string () truefalsenot_available	Indicates whether the complete name of the customer matches with the one on the Operator's system.
`nameMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`givenNameMatch`	string () truefalsenot_available	Indicates whether First name/given name of the customer matches with the one on the Operator's system.
`givenNameMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`familyNameMatch`	string () truefalsenot_available	Indicates whether last name/ family name/ surname of the customer matches with the one on the Operator's system.
`familyNameMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`nameKanaHankakuMatch`	string () truefalsenot_available	Indicates whether complete name of the customer in Hankaku-Kana format (reading of name) for Japan matches with the one on the Operator's system.
`nameKanaHankakuMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`nameKanaZenkakuMatch`	string () truefalsenot_available	Indicates whether complete name of the customer in Zenkaku-Kana format (reading of name) for Japan matches with the one on the Operator's system.
`nameKanaZenkakuMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`middleNamesMatch`	string () truefalsenot_available	Indicates whether the middle names of the customer matches with the one on the Operator's system.
`middleNamesMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`familyNameAtBirthMatch`	string () truefalsenot_available	Indicates whether the Family Name At Birth of the customer matches with the one on the Operator's system.
`familyNameAtBirthMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`addressMatch`	string () truefalsenot_available	Indicates whether complete billingAddress of the customer matches with the one on the Operator's system.
`addressMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`streetNameMatch`	string () truefalsenot_available	Indicates whether the street name of the customer matches with the one on the Operator's system.
`streetNameMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`streetNumberMatch`	string () truefalsenot_available	Indicates whether the street number of the customer matches with the one on the Operator's system.
`streetNumberMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`postalCodeMatch`	string () truefalsenot_available	Indicates whether the postal code / zip code of the customer matches with the one on the Operator's system.
`regionMatch`	string () truefalsenot_available	Indicates whether the region of the customer's billingAddress matches with the one on the Operator's system.
`regionMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`localityMatch`	string () truefalsenot_available	Indicates whether the locality of the customer's billingAddress matches with the one on the Operator's system.
`localityMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`countryMatch`	string () truefalsenot_available	Indicates whether the country of the customer's billingAddress matches with the one on the Operator's system.
`houseNumberExtensionMatch`	string () truefalsenot_available	Indicates whether the house number extension of the customer's billingAddress matches with the one on the Operator's system.
`birthdateMatch`	string () truefalsenot_available	Indicates whether the birthdate of the customer matches with the one on the Operator's system.
`emailMatch`	string () truefalsenot_available	Indicates whether the email billingAddress of the customer matches with the one on the Operator's system.
`emailMatchScore`	integer	Indicates the similarity score assigned to the input value when it does not exactly match the value stored in the operator's system. This property shall only be returned when the value of the corresponding match field is `false`.	min: 0 , max: 100
`genderMatch`	string () truefalsenot_available	Indicates whether the gender of the customer matches with the one on the Operator's system.

Property	Type	Description	Constraints	Default
`ageThreshold` *	integer	The age to be verified. The indicated range is a global definition of maximum and minimum values allowed to be requested. It is important to note that this range might be more restrictive in some implementations due to local regulations of a country i.e. A country does not allow to request for an age under 18. This limitation must be informed during the onboarding process.	min: 0 , max: 120
`phoneNumber` *	string	A public identifier addressing a telephone subscription. In mobile networks it corresponds to the MSISDN (Mobile Station International Subscriber Directory Number). In order to be globally unique it has to be formatted in international format, according to E.164 standard, prefixed with '+'.	pattern: ^\+[1-9][0-9]{4,14}$
`idDocument`	string	Id number associated to the official identity document in the country. It may contain alphanumeric characters.
`name`	string	Complete name of the customer, usually composed of first/given name and last/family/sur- name in a country. Depending on the country, the order of first/give name and last/family/sur- name varies, and middle name could be included. It can use givenName, middleNames, familyName and/or familyNameAtBirth. For example, in ESP, name+familyName; in NLD, it can be name+middleNames+familyName or name+middleNames+familyNameAtBirth, etc.
`givenName`	string	First/given name or compound first/given name of the customer.
`familyName`	string	Last name, family name, or surname of the customer.
`middleNames`	string	Middle name/s of the customer.
`familyNameAtBirth`	string	Last/family/sur- name at birth of the customer.
`birthdate`	string (date)	The birthdate of the customer, in RFC 3339 / ISO 8601 calendar date format (YYYY-MM-DD).
`email`	string (email)	Email address of the customer in the RFC specified format (local-part@domain).
`includeContentLock`	boolean	If this parameter is included in the request with value `true`, the response property `contentLock` will be returned. If it is not included or its value is `false`, the response property will not be returned.		false
`includeParentalControl`	boolean	If this parameter is included in the request with value `true`, the response property `parentalControl` will be returned. If it is not included or its value is `false`, the response property will not be returned.		false

Property	Type	Description	Constraints
`ageCheck` *	string () truefalsenot_available	Indicate `"true"` when the age of the user is the same age or older than the age threshold (age >= age threshold), and `"false"` if not (age < age threshold). If the API Provider doesn't have enough information to perform the validation, a `not_available` can be returned.
`verifiedStatus`	boolean	Indicate `true` if the information provided has been compared against information based on an identification document legally accepted as an age verification document (Note), otherwise indicate `false`. Note: Depending on the country, credit-check or other mechanism can be used instead of official identification for Age Verification. For details, please contact API Provider.
`identityMatchScore`	integer	The overall score of identity information available in the API Provider, information either provided in the request body comparing it to the one that the API Provider holds or directly using internal API Provider's information. It is optional for the API Provider to return the Identity match score.	min: 0 , max: 100
`contentLock`	string () truefalsenot_available	Indicate `"true"` if the subscription associated with the phone number has any kind of content lock (i.e certain web content blocked) and `"false"` if not. If the information is not available the value `not_available` can be returned.
`parentalControl`	string () truefalsenot_available	Indicate `"true"` if the subscription associated with the phone number has any kind of parental control activated and `"false"` if not. If the information is not available the value `not_available` can be returned.

Property	Type	Description	Constraints	Default
`tenureDateCheck` *	boolean	`true` when the identified mobile subscription has had valid tenure since `tenureDate`, otherwise `false`
`contractType`	string () PAYGPAYMBusiness	If exists, populated with: - `PAYG` - prepaid (pay-as-you-go) account - `PAYM` - contract account - `Business` - Business (enterprise) account This attribute may be omitted from the response set if the information is not available

Property	Type	Description
`lastChecked` *	string (date-time)	Date and time that the information was last confirmed by the mobile operator to be correct. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
`imei` *	string	IMEI of the device
`imeisv`	string	IMEI SV of the device
`tac`	string	IMEI TAC of the device
`model`	string	Model of the device
`manufacturer`	string	Manufacturer of the device

Property	Type	Description	Constraints	Default
`lastStatusTime`	string (date-time)	Last time that the associated connected Network Type was updated. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
`connectedNetworkType` *	string () 2G3G4G5GUNKNOWN	* UNKNOWN: Used when connection [technology] can not be determined * 2G: 2nd Generation Mobile Communication Technology * 3G: 3rd Generation Mobile Communication Technology * 4G: 4th Generation Mobile Communication Technology * 5G: 5th Generation Mobile Communication Technology

Resources

Resources

POST /orgs/{org_id}/device-swap/retrieve-date

Parameters

Request body * Required

Responses

Response Headers

Snippet

POST /orgs/{org_id}/device-swap/check

Parameters