API Manager v1.14.0
| API Manager for GSMA's CAMARA project capabilities. This service acts as a gateway that receives requests conforming to the CAMARA standard and routes them to the appropriate microservices. The API Manager provides centralized handling of CAMARA-compliant requests, including validation, authentication, and proper routing to backend services. It ensures all interactions follow the standardized CAMARA specifications, enabling developers to access telco network capabilities through consistent interfaces regardless of the underlying implementation. Key features: - CAMARA standard compliance validation - Request routing to specialized microservices - API versioning support - Telco capability exposure management # Number Verification Number Verification API performs real-time checks to verify the phone number of the mobile device being used to access a service provider (SP) service, where the mobile device is accessing the *service provider* over a mobile network (WiFi connections are out of this API scope) either by getting the comparison result or receiving the phone number of the device that it is used, so they can verify it themselves. It uses direct mobile network connections to verify possession of a phone number in the background without requiring user interaction. There are neither OTPs (One-time passwords) received by SMS nor authenticator app downloads, so it is much simpler. It can be used at sign up, login, or transaction time to validate that a user's SIM (Subscriber Identity Module) is both actively connected to the mobile network and not spoofed or cloned. # SIM SWAP A SIM swap is a process in which a user's mobile phone number (MSISDN) is associated with a new SIM card (IMSI). This is typically done by contacting the user's mobile service provider and requesting a new SIM card for various reasons, such as a lost or damaged SIM card or upgrading to a new phone. SIM swap also happens during other actions like changing user's phone number, changing mobile service provider keeping user's mobile phone number or when activating a new SIM associated to the same phone number, known as multisim service. New subscription is considered as a SIM swap as well, the MSISDN which can be used by another person earlier, is associated with a SIM card it was not associated before. # DEVICE SWAP This API allows to check the last time that the phone (device) - phone number association has changed # KYC MATCH 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. # KYC AGE VERIFICATION 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.. # KYC Tenure 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. # Consent Information 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. # Quality of Service (QoS) Profiles The Quality-of-Service (QoS) Profiles API provides a set of predefined network performance characteristics, such as latency, throughput, and priority, identified by a unique name. These profiles allow application developers to specify the desired network behavior for their application's data traffic, ensuring optimal performance. By selecting an appropriate QoS profile, developers can request stable latency (reduced jitter) or throughput for specific data flows between client devices and application servers when used by the Quality-On-Demand APIs. # Quality on Demand (QoD) The Quality-On-Demand (QoD) API provides a programmable interface for developers and other users (API consumers) to request stable latency or throughput managed by networks without the necessity to have an in-depth knowledge of the underlying network complexity (e.g. the 4G/5G system in case of a mobile network). # Number Recycling 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. # Location Retrieval The Location Retrieval API provides the ability to retrieve the location of a device identified by a phone number. The location is returned as an area, including geographic coordinates and accuracy information. # Location Verification The Location Verification API provides the ability to verify the location of a device against a specified area. It returns a boolean result indicating whether the device is within the provided location area. # Device Identifier The Device Identifier API provides the ability to retrieve device information for a mobile subscriber, including IMEI (International Mobile Equipment Identity), IMEI SV (Software Version), TAC (Type Allocation Code), device model, and manufacturer details. This information can be used for device verification, fraud detection, and device management purposes. # AUTHN - AUTHNZ CAMARA User Authentication/Authorization follows the CAMARA Security and Interoperability Profile technical specification. This section describes the authorization flows that can be used to access CAMARA APIs: * Authorization code flow (Frontend flow) - Used to obtain a Three-Legged Access Token from the Authorization Server and initiated from the Consumption Device * CIBA flow (Backend flow) - Used to obtain a Three-Legged Access Token from the Authorization Server and initiated from the ASP's Application Backend * JWT Bearer flow - Used to obtain a Two-Legged Access Token from the Authorization Server by using a signed JWT as client assertion