openapi: 3.0.3
info:
  title: Open-Gateway API V0
  description: >-
    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


    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.



    # 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.


    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)


    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](https://w3c.github.io/dpv/2.0/dpv/) (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 "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.


    # 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.


    # 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.


    # 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.

    <img width="4000" alt="Number_Recycling_scenario_1"
    src="https://raw.githubusercontent.com/camaraproject/NumberRecycling/r1.1/documentation/API_documentation/assets/Number_Recycling_scenario_1.png">


    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.

    <img width="4000" alt="Number_Recycling_scenario_2"
    src="https://raw.githubusercontent.com/camaraproject/NumberRecycling/r1.1/documentation/API_documentation/assets/Number_Recycling_scenario_2.png">


    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


    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.


    # 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.


    ### 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.


    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


    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.


    # 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.


    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
    `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`.

      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.

    # Further info and support


    (FAQs will be added in a later version of the documentation)
  version: 0.6.0
servers:
  - url: 'https://opengateway.masstack.com/v0/'
    description: production
  - url: 'https://opengateway.sta.masstack.com/v0/'
    description: staging
tags:
  - name: Device Swap
    description: API operation of device API.
  - name: KycMatch
    description: >-
      Operations to match a customer identity against the account data bound to
      their phone number.
  - name: Kyc Age Verification
    description: Operations to verify the age of a user.
  - name: KycTenure
    description: Check details about the length of tenure of the subscriber
  - name: Consent Info
    description: API operation of Consent Info API
  - name: NumberRecycling
    description: >-
      APIs to check whether there has been a change in the subscriber associated
      with the phone number after the specified date.
  - name: LocationRetrieval
    description: Retrieve the location of a device
paths:
  '/orgs/{org_id}/device-swap/retrieve-date':
    post:
      tags:
        - Device Swap
      description: >-
        Get timestamp of last device swap for a mobile user account provided
        with phone number.
      operationId: retrieveDeviceSwapDate
      parameters:
        - name: org_id
          in: path
          required: true
          schema:
            type: string
            example: masmovil
      requestBody:
        description: Create a device swap date request for a phone number.
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/DeviceSwapCreateDeviceSwapDate'
        required: true
      responses:
        '200':
          description: Contains information about Device swap change
          headers:
            x-correlator:
              description: Correlation id for the different services
              schema:
                type: string
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/DeviceSwapDeviceSwapInfo'
        '400':
          $ref: '#/components/responses/DeviceSwapGeneric400'
        '401':
          $ref: '#/components/responses/DeviceSwapGeneric401'
        '403':
          $ref: '#/components/responses/DeviceSwapGeneric403'
        '404':
          $ref: '#/components/responses/DeviceSwapGeneric404'
        '422':
          $ref: '#/components/responses/DeviceSwapGeneric422'
        '500':
          $ref: '#/components/responses/DeviceSwapGeneric500'
        '503':
          $ref: '#/components/responses/DeviceSwapGeneric503'
        '504':
          $ref: '#/components/responses/DeviceSwapGeneric504'
  '/orgs/{org_id}/device-swap/check':
    post:
      tags:
        - Device Swap
      description: Check if device swap has been performed during a past period
      operationId: checkDeviceSwap
      parameters:
        - name: org_id
          in: path
          required: true
          schema:
            type: string
            example: masmovil
      requestBody:
        description: |
          Create a check device swap request for a phone number.
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/DeviceSwapCreateCheckDeviceSwap'
        required: true
      responses:
        '200':
          description: >-
            Returns whether a device swap has been performed during a past
            period
          headers:
            x-correlator:
              description: Correlation id for the different services
              schema:
                type: string
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/DeviceSwapCheckDeviceSwapInfo'
        '400':
          $ref: '#/components/responses/DeviceSwapGeneric400'
        '401':
          $ref: '#/components/responses/DeviceSwapGeneric401'
        '403':
          $ref: '#/components/responses/DeviceSwapGeneric403'
        '404':
          $ref: '#/components/responses/DeviceSwapGeneric404'
        '422':
          $ref: '#/components/responses/DeviceSwapGeneric422'
        '500':
          $ref: '#/components/responses/DeviceSwapGeneric500'
        '503':
          $ref: '#/components/responses/DeviceSwapGeneric503'
        '504':
          $ref: '#/components/responses/DeviceSwapGeneric504'
  '/orgs/{org_id}/kyc-match/match':
    post:
      tags:
        - KycMatch
      summary: >-
        Matching a customer identity by checking a set of attributes related
        against the account data bound to their phone number.
      description: >-
        Verify matching of a number of attributes related to a customer identity
        against the verified data bound to their phone number in the Operator
        systems. Regardless of whether the `phoneNumber` is explicitly stated in
        the request body, at least one of the other fields must be provided,
        otherwise a `HTTP 400 - KNOW_YOUR_CUSTOMER.INVALID_PARAM_COMBINATION`
        error will be returned. The API will return the result of the matching
        process for each requested attribute. This means that the response will
        **only** contain the attributes for which validation has been requested.
        Possible values are: - **true**: the attribute provided matches with the
        one in the Operator systems. - **false**: the attribute provided does
        not match with the one in the Operator systems. - **not_available**: the
        attribute is not available to validate. 
      operationId: match
      parameters:
        - name: org_id
          in: path
          required: true
          schema:
            type: string
            example: masmovil
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/KycMatchKYC_MatchRequestBody'
            examples:
              Two-Legged and Three-leg Access Token Example:
                value:
                  phoneNumber: '+34629255833'
                  idDocument: 66666666q
                  name: Federica Sanchez Arjona
                  givenName: Federica
                  familyName: Sanchez Arjona
                  nameKanaHankaku: federica
                  nameKanaZenkaku: Ｆｅｄｅｒｉｃａ
                  middleNames: Sanchez
                  familyNameAtBirth: YYYY
                  address: Tokyo-to Chiyoda-ku Iidabashi 3-10-10
                  streetName: Nicolas Salmeron
                  streetNumber: 4
                  postalCode: 1028460
                  region: Tokyo
                  locality: ZZZZ
                  country: JP
                  houseNumberExtension: VVVV
                  birthdate: '1978-08-22'
                  email: abc@example.com
                  gender: MALE
      responses:
        '200':
          description: OK
          headers:
            x-correlator:
              description: Correlation id for the different services
              schema:
                type: string
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/KycMatchKYC_MatchResponse'
              examples:
                KYC_Match200Example:
                  value:
                    idDocumentMatch: 'true'
                    nameMatch: 'true'
                    givenNameMatch: not_available
                    familyNameMatch: not_available
                    nameKanaHankakuMatch: 'true'
                    nameKanaZenkakuMatch: 'false'
                    middleNamesMatch: 'true'
                    familyNameAtBirthMatch: 'false'
                    familyNameAtBirthMatchScore: 90
                    addressMatch: 'true'
                    streetNameMatch: 'true'
                    streetNumberMatch: 'true'
                    postalCodeMatch: 'true'
                    regionMatch: 'true'
                    localityMatch: not_available
                    countryMatch: 'true'
                    houseNumberExtensionMatch: not_available
                    birthdateMatch: 'false'
                    emailMatch: 'false'
                    emailMatchScore: 87
                    genderMatch: 'false'
        '400':
          $ref: '#/components/responses/KycMatchGeneric400'
        '401':
          $ref: '#/components/responses/KycMatchGeneric401'
        '403':
          $ref: '#/components/responses/KycMatchGeneric403'
        '404':
          $ref: '#/components/responses/KycMatchGeneric404'
        '500':
          $ref: '#/components/responses/KycMatchGeneric500'
        '503':
          $ref: '#/components/responses/KycMatchGeneric503'
        '504':
          $ref: '#/components/responses/KycMatchGeneric504'
  '/orgs/{org_id}/kyc-age-verification/verify':
    post:
      tags:
        - Kyc Age Verification
      summary: Verify Age Threshold
      description: >
        Verify that the age of the subscriber associated with a phone number is
        equal to or greater than the specified age threshold value.


        As it is possible that the person holding the contract and the end-user
        of the subscription may not be the same, the endpoint also admits a list
        of optional properties to be included in the request to improve the
        identification. The response may optionally include the
        `identityMatchScore` property with a value that indicates how certain it
        is that the information returned relates to the person that the API
        Client is requesting. To increase the reliability of the information
        returned, the API Provider may include in the response the
        `verifiedStatus` property, indicating whether the identity information
        in its possession has been verified against an identification document
        legally accepted as an age verification document (Note). 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.


        If the API Client indicates request properties `includeContentLock` or
        `includeParentalControl` with value `true` and the API Provider
        implements this functionality, then the response will also include
        `contentLock` and `parentalControl` properties to indicate if the
        subscription has any kind of content filtering enabled. On the other
        hand, if the request properties are not included or the API Client
        specifies value `false`, then the response properties will not be
        returned. If the API Provider doesn't implement this functionality,
        request properties will be ignored and response properties won't be
        returned in any case.
      operationId: verifyAge
      parameters:
        - name: org_id
          in: path
          required: true
          schema:
            type: string
            example: masmovil
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/KycAgeVerificationVerifyRequestBody'
            example:
              ageThreshold: 18
              phoneNumber: '+34629255833'
              idDocument: 66666666q
              name: Federica Sanchez Arjona
              givenName: Federica
              familyName: Sanchez Arjona
              middleNames: Sanchez
              familyNameAtBirth: YYYY
              birthdate: '1978-08-22'
              email: federicaSanchez.Arjona@example.com
              includeContentLock: true
              includeParentalControl: true
      responses:
        '200':
          description: OK
          headers:
            x-correlator:
              description: Correlation id for the different services
              schema:
                type: string
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/KycAgeVerificationVerifyResponseBody'
              examples:
                KYC_200Example:
                  value:
                    ageCheck: 'true'
                    verifiedStatus: true
                    identityMatchScore: 90
                    contentLock: 'false'
                    parentalControl: 'true'
        '400':
          $ref: '#/components/responses/KycAgeVerificationGeneric400'
        '401':
          $ref: '#/components/responses/KycAgeVerificationGeneric401'
        '403':
          $ref: '#/components/responses/KycAgeVerificationGeneric403'
        '404':
          $ref: '#/components/responses/KycAgeVerificationGeneric404'
        '422':
          $ref: '#/components/responses/KycAgeVerificationGeneric422'
        '500':
          $ref: '#/components/responses/KycAgeVerificationGeneric500'
        '503':
          $ref: '#/components/responses/KycAgeVerificationGeneric503'
        '504':
          $ref: '#/components/responses/KycAgeVerificationGeneric504'
  '/orgs/{org_id}/kyc-tenure/check-tenure':
    post:
      tags:
        - KycTenure
      summary: The KYC Tenure service API
      description: >
        Verifies a specified length of tenure, based on a provided date, for a
        network subscriber to establish a level of trust for the network
        subscription identifier.
      operationId: checkTenure
      parameters:
        - name: org_id
          in: path
          required: true
          schema:
            type: string
            example: masmovil
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/KycTenureTenure'
      responses:
        '200':
          description: Respond with tenure information
          headers:
            x-correlator:
              description: Correlation id for the different services
              schema:
                type: string
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/KycTenureTenureInfo'
        '400':
          $ref: '#/components/responses/KycTenureGeneric400'
        '401':
          $ref: '#/components/responses/KycTenureGeneric401'
        '403':
          $ref: '#/components/responses/KycTenureGeneric403'
        '404':
          $ref: '#/components/responses/KycTenureGeneric404'
        '422':
          $ref: '#/components/responses/KycTenureGeneric422'
  '/orgs/{org_id}/consent-info/retrieve':
    post:
      summary: Create a request to retrieve the validity status of the data processing
      description: >
        Create a request to retrieve the validity status of the API Consumer
        data processing for a given User, scope(s) and Purpose. The API Consumer
        is identified by the `client_id` parameter deduced from the access
        token.
      operationId: retrieveStatus
      tags:
        - Consent Info
      parameters:
        - name: org_id
          in: path
          required: true
          schema:
            type: string
            example: masmovil
      requestBody:
        required: true
        description: Retrieve status request
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/ConsentInfoRetrieveStatusRequestBody'
            examples:
              ONE_SCOPE_ONE_API:
                summary: One scope
                description: |
                  Request with one scope corresponding to one API
                value:
                  phoneNumber: '+123456789'
                  clientId: api-consumer
                  scopes:
                    - 'location-verification:verify'
                  purpose: 'dpv:FraudPreventionAndDetection'
                  requestCaptureUrl: true
              MULTIPLE_SCOPES_ONE_API:
                summary: Multiple scopes for one API
                description: |
                  Request with multiple scopes corresponding to one API
                value:
                  phoneNumber: '+123456789'
                  clientId: api-consumer
                  scopes:
                    - 'quality-on-demand:sessions:create'
                    - 'quality-on-demand:sessions:read'
                    - 'quality-on-demand:sessions:update'
                    - 'quality-on-demand:sessions:delete'
                    - 'quality-on-demand:sessions:retrieve-by-device'
                  purpose: 'dpv:RequestedServiceProvision'
                  requestCaptureUrl: true
              MULTIPLE_SCOPES_MULTIPLE_APIS:
                summary: Multiple scopes for multiple APIs
                description: |
                  Request with multiple scopes corresponding to multiple APIs
                value:
                  phoneNumber: '+123456789'
                  clientId: api-consumer
                  scopes:
                    - 'location-verification:verify'
                    - 'device-roaming-status:read'
                  purpose: 'dpv:FraudPreventionAndDetection'
                  requestCaptureUrl: true
      responses:
        '200':
          description: OK
          headers:
            x-correlator:
              $ref: '#/components/headers/ConsentInfox-correlator'
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ConsentInfoRetrieveStatusResponseBody'
              examples:
                READY_FOR_PROCESSING:
                  summary: Ready for processing
                  description: >
                    Data processing is allowed for the requested scope(s) and
                    Purpose.
                  value:
                    statusInfo:
                      - scopes:
                          - 'number-verification:verify'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: true
                CONSENT_REQUIRED:
                  summary: Consent is required
                  description: |
                    Consent is required for the requested scope(s) and Purpose
                  value:
                    statusInfo:
                      - scopes:
                          - 'location-verification:verify'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: false
                        statusReason: REQUESTED
                CONSENT_REQUIRED_CAPTURE_URL:
                  summary: Consent is required and capture URL is provided
                  description: >
                    Consent is required for the requested scope(s) and Purpose
                    but it is expired. The API Provider provides a Consent
                    capture URL.
                  value:
                    statusInfo:
                      - scopes:
                          - 'location-verification:verify'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: false
                        statusReason: EXPIRED
                        expirationDate: '2023-07-03T14:27:08.312+02:00'
                    captureUrl: 'https://example.org/consent-capture-url'
                CONSENT_REVOKED:
                  summary: Consent is revoked
                  description: |
                    Consent is revoked for the requested scope(s) and Purpose.
                  value:
                    statusInfo:
                      - scopes:
                          - 'location-verification:verify'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: false
                        statusReason: REVOKED
                DATA_PROCESSING_OPT_OUT:
                  summary: Data processing opt-out
                  description: >
                    The User has opted out of the data processing for the
                    requested scope(s) and Purpose.
                  value:
                    statusInfo:
                      - scopes:
                          - 'number-verification:verify'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: false
                        statusReason: OBJECTED
                MULTIPLE_SCOPES_ONE_API:
                  summary: Multiple scopes for one API
                  description: |
                    Request with multiple scopes corresponding to one API.
                  value:
                    statusInfo:
                      - scopes:
                          - 'quality-on-demand:sessions:create'
                          - 'quality-on-demand:sessions:read'
                          - 'quality-on-demand:sessions:update'
                          - 'quality-on-demand:sessions:delete'
                          - 'quality-on-demand:sessions:retrieve-by-device'
                        purpose: 'dpv:RequestedServiceProvision'
                        statusValidForProcessing: true
                MULTIPLE_SCOPES_MULTIPLE_APIS:
                  summary: Multiple scopes for multiple APIs
                  description: |
                    Request with multiple scopes corresponding to multiple APIs.
                  value:
                    statusInfo:
                      - scopes:
                          - 'location-verification:verify'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: false
                        statusReason: PENDING
                      - scopes:
                          - 'device-roaming-status:read'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: false
                        statusReason: PENDING
                    captureUrl: 'https://example.org/consent-capture-url'
                MULTIPLES_SCOPES_ONE_API_DIFFERENT_STATUS:
                  summary: Multiple scopes for one API with different status
                  description: >
                    Request with multiple scopes corresponding to one API.
                    Different status for each scope.
                  value:
                    statusInfo:
                      - scopes:
                          - 'sim-swap:check'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: true
                      - scopes:
                          - 'sim-swap:retrieve-date'
                        purpose: 'dpv:FraudPreventionAndDetection'
                        statusValidForProcessing: false
                        statusReason: OBJECTED
        '400':
          $ref: '#/components/responses/ConsentInfoGeneric400'
        '401':
          $ref: '#/components/responses/ConsentInfoGeneric401'
        '403':
          $ref: '#/components/responses/ConsentInfoGeneric403'
        '422':
          $ref: '#/components/responses/ConsentInfoGeneric422'
        '500':
          $ref: '#/components/responses/ConsentInfoGeneric500'
        '503':
          $ref: '#/components/responses/ConsentInfoGeneric503'
        '504':
          $ref: '#/components/responses/ConsentInfoGeneric504'
  '/orgs/{org_id}/number-recycling/check':
    post:
      tags:
        - NumberRecycling
      summary: Check whether the subscriber of the phone number has changed.
      description: Check whether the subscriber of the phone number has changed.
      operationId: checkNumberRecycling
      parameters:
        - name: org_id
          in: path
          required: true
          schema:
            type: string
            example: masmovil
      requestBody:
        description: |
          Check whether the subscriber of the phone number has changed.
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/NumberRecyclingCreateCheck'
        required: true
      responses:
        '200':
          $ref: '#/components/responses/NumberRecyclingGeneric200'
        '400':
          $ref: '#/components/responses/NumberRecyclingGeneric400'
        '401':
          $ref: '#/components/responses/NumberRecyclingGeneric401'
        '403':
          $ref: '#/components/responses/NumberRecyclingGeneric403'
        '404':
          $ref: '#/components/responses/NumberRecyclingGeneric404'
        '422':
          $ref: '#/components/responses/NumberRecyclingGeneric422'
        '500':
          $ref: '#/components/responses/NumberRecyclingGeneric500'
  '/orgs/{org_id}/location-retrieval/retrieve':
    post:
      tags:
        - LocationRetrieval
      summary: Execute location retrieval for a user device
      description: Retrieve the area where a certain user device is localized.
      operationId: retrieveLocation
      parameters:
        - name: org_id
          in: path
          required: true
          schema:
            type: string
            example: masmovil
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/LocationRetrievalRetrievalRequest'
            examples:
              INPUT_PHONE_NUMBER_MAX_AGE:
                summary: Phone number and maxAge
                description: >-
                  Retrieve location for a device identified by a phone number,
                  providing a maxAge
                value:
                  device:
                    phoneNumber: '+123456789'
                  maxAge: 120
              INPUT_PHONE_NUMBER_MAX_AGE_AND_SURFACE:
                summary: 'Phone number, maxAge and maxSurface'
                description: >-
                  Retrieve location for a device identified by a phone number,
                  providing a maxAge and maxSurface
                value:
                  device:
                    phoneNumber: '+123456789'
                  maxAge: 120
                  maxSurface: 1000000
              INPUT_IP_ADDRESS_V4:
                summary: IPv4 address without maxAge
                description: >-
                  Retrieve location for a device identified by an IPv4 address,
                  without an indication for maxAge
                value:
                  device:
                    ipv4Address:
                      publicAddress: 123.234.1.2
                      publicPort: 1234
              INPUT_NO_DEVICE_AND_MAX_AGE:
                summary: 'Device not provided, only maxAge'
                description: The device has to be deducted from token
                value:
                  maxAge: 120
              INPUT_PHONE_NUMBER_IP_ADDRESS_V4:
                summary: 'Both phone number and IPv4 address, without maxAge'
                description: >-
                  Retrieve location for a device identified both by a phone
                  number and an IPv4 address, without an indication for maxAge
                value:
                  device:
                    phoneNumber: '+123456789'
                    ipv4Address:
                      publicAddress: 123.234.1.2
                      publicPort: 1234
      responses:
        '200':
          description: Location retrieval result
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/LocationRetrievalLocation'
              examples:
                LOCATION_CIRCLE:
                  $ref: '#/components/examples/LocationRetrievalRETRIEVAL_CIRCLE'
                LOCATION_POLYGON:
                  $ref: '#/components/examples/LocationRetrievalRETRIEVAL_POLYGON'
                LOCATION_CIRCLE_WITH_DEVICE:
                  $ref: >-
                    #/components/examples/LocationRetrievalLOCATION_CIRCLE_WITH_DEVICE
        '400':
          $ref: '#/components/responses/LocationRetrievalGeneric400'
        '401':
          $ref: '#/components/responses/LocationRetrievalGeneric401'
        '403':
          $ref: '#/components/responses/LocationRetrievalGeneric403'
        '404':
          $ref: '#/components/responses/LocationRetrievalGeneric404'
        '422':
          $ref: '#/components/responses/LocationRetrievalGeneric422'
components:
  schemas:
    DeviceSwapDeviceSwapInfo:
      type: object
      required:
        - latestDeviceChange
      properties:
        latestDeviceChange:
          type: string
          format: date-time
          description: >-
            Timestamp of latest device swap performed. It must follow [RFC
            3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and
            must have time zone. Recommended format is
            yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows
            2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
          nullable: true
          example: '2023-07-03T14:27:08.312+02:00'
    DeviceSwapCreateDeviceSwapDate:
      type: object
      required:
        - phoneNumber
      properties:
        phoneNumber:
          $ref: '#/components/schemas/DeviceSwapPhoneNumber'
    DeviceSwapCreateCheckDeviceSwap:
      type: object
      required:
        - phoneNumber
      properties:
        phoneNumber:
          $ref: '#/components/schemas/DeviceSwapPhoneNumber'
        maxAge:
          type: integer
          example: 240
          description: |
            Period in hours to be checked for device swap.
            Valid range: 1-2400 hours.
          format: int32
          default: 240
    DeviceSwapPhoneNumber:
      type: string
      pattern: '^\+[1-9][0-9]{4,14}$'
      example: '+34666111333'
      description: >-
        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 '+'.
    DeviceSwapCheckDeviceSwapInfo:
      type: object
      required:
        - swapped
      properties:
        swapped:
          type: boolean
          description: >-
            Indicates whether the device has been swapped during the period
            within the provided age.
    DeviceSwapApiError:
      required:
        - code
        - details
        - ref
        - title
      type: object
      properties:
        code:
          type: string
          description: code of the error
        title:
          type: string
          description: title of the error
        ref:
          type: string
          description: ref of the error
        details:
          type: string
          description: details of the error
    KycMatchSafeString:
      type: string
      pattern: '^(?!.*(;|''|"|\\|alert\(|%|prompt\(|\.\./|<|>|\[|\]|!|#|--)).*$'
    KycMatchKYC_MatchRequestBody:
      type: object
      description: >
        Payload to validate the customer data.

        - required: phoneNumber idDocument name givenName familyName
        nameKanaHankaku nameKanaZenkaku
            middleNames familyNameAtBirth billingAddress streetName streetNumber postalCode region locality
            country houseNumberExtension birthdate email gender
      properties:
        phoneNumber:
          type: string
          description: >-
            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}$'
          example: '+123456789'
        idDocument:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: >-
            Id number associated to the official identity document in the
            country. It may contain alphanumeric characters.
        name:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: >-
            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:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: First/given name or compound first/given name of the customer.
        familyName:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: 'Last name, family name, or surname of the customer.'
        nameKanaHankaku:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: >-
            Complete name of the customer in Hankaku-Kana format (reading of
            name) for Japan.
        nameKanaZenkaku:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: >-
            Complete name of the customer in Zenkaku-Kana format (reading of
            name) for Japan.
        middleNames:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: Middle name/s of the customer.
        familyNameAtBirth:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: Last/family/sur- name at birth of the customer.
        address:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: >-
            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.
        streetName:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: >-
            Name of the street of the customer's billingAddress. It should not
            include the type of the street.
        streetNumber:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: >-
            The street number of the customer's billingAddress.  Number
            identifying a specific property on the 'streetName'.
        postalCode:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: Zip code or postal code
        region:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: Region/prefecture of the customer's billingAddress
        locality:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: Locality of the customer's billingAddress
        country:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: Country of the customer's billingAddress. Format ISO 3166-1 alpha-2
          pattern: '^[A-Z]{2}$'
          example: ES
        houseNumberExtension:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          description: >-
            Specific identifier of the house needed depending on the property
            type. For example, number of apartment in an apartment building.
        birthdate:
          type: string
          format: date
          description: >-
            The birthdate of the customer, in RFC 3339 / ISO 8601 calendar date
            format (YYYY-MM-DD).
        email:
          allOf:
            - $ref: '#/components/schemas/KycMatchSafeString'
          format: email
          description: >-
            Email billingAddress of the customer in the RFC specified format
            (local-part@domain).
        gender:
          type: string
          description: Gender of the customer (Male/Female/Other).
          enum:
            - MALE
            - FEMALE
            - OTHER
    KycMatchMatchResult:
      type: string
      enum:
        - 'true'
        - 'false'
        - not_available
    KycMatchMatchScoreResult:
      type: integer
      description: >-
        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`.
      minimum: 0
      maximum: 100
    KycMatchKYC_MatchResponse:
      type: object
      properties:
        idDocumentMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether Id number associated to the ID document of the
            customer matches with the one on the Operator's system.
        nameMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the complete name of the customer matches with the
            one on the Operator's system.
        nameMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        givenNameMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether First name/given name of the customer matches with
            the one on the Operator's system.
        givenNameMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        familyNameMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether last name/ family name/ surname of the customer
            matches with the one on the Operator's system.
        familyNameMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        nameKanaHankakuMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            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:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        nameKanaZenkakuMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            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:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        middleNamesMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the middle names of the customer matches with the
            one on the Operator's system.
        middleNamesMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        familyNameAtBirthMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the Family Name At Birth of the customer matches
            with the one on the Operator's system.
        familyNameAtBirthMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        addressMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether complete billingAddress of the customer matches
            with the one on the Operator's system.
        addressMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        streetNameMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the street name of the customer matches with the
            one on the Operator's system.
        streetNameMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        streetNumberMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the street number of the customer matches with the
            one on the Operator's system.
        streetNumberMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        postalCodeMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the postal code / zip code of the customer matches
            with the one on the Operator's system.
        regionMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the region of the customer's billingAddress
            matches with the one on the Operator's system.
        regionMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        localityMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the locality of the customer's billingAddress
            matches with the one on the Operator's system.
        localityMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        countryMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the country of the customer's billingAddress
            matches with the one on the Operator's system.
        houseNumberExtensionMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the house number extension of the customer's
            billingAddress matches with the one on the Operator's system.
        birthdateMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the birthdate of the customer matches with the one
            on the Operator's system.
        emailMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the email billingAddress of the customer matches
            with the one on the Operator's system.
        emailMatchScore:
          $ref: '#/components/schemas/KycMatchMatchScoreResult'
        genderMatch:
          allOf:
            - $ref: '#/components/schemas/KycMatchMatchResult'
          description: >-
            Indicates whether the gender of the customer matches with the one on
            the Operator's system.
    KycMatchApiError:
      required:
        - code
        - details
        - ref
        - title
      type: object
      properties:
        code:
          type: string
          description: code of the error
        title:
          type: string
          description: title of the error
        ref:
          type: string
          description: ref of the error
        details:
          type: string
          description: details of the error
    KycAgeVerificationVerifyRequestBody:
      type: object
      description: Request to verify the age threshold provided.
      required:
        - ageThreshold
        - phoneNumber
      properties:
        ageThreshold:
          $ref: '#/components/schemas/KycAgeVerificationAgeThreshold'
        phoneNumber:
          $ref: '#/components/schemas/KycAgeVerificationPhoneNumber'
        idDocument:
          $ref: '#/components/schemas/KycAgeVerificationIdDocument'
        name:
          $ref: '#/components/schemas/KycAgeVerificationName'
        givenName:
          $ref: '#/components/schemas/KycAgeVerificationGivenName'
        familyName:
          $ref: '#/components/schemas/KycAgeVerificationFamilyName'
        middleNames:
          $ref: '#/components/schemas/KycAgeVerificationMiddleNames'
        familyNameAtBirth:
          $ref: '#/components/schemas/KycAgeVerificationFamilyNameAtBirth'
        birthdate:
          $ref: '#/components/schemas/KycAgeVerificationBirthdate'
        email:
          $ref: '#/components/schemas/KycAgeVerificationEmail'
        includeContentLock:
          $ref: '#/components/schemas/KycAgeVerificationIncludeContentLock'
        includeParentalControl:
          $ref: '#/components/schemas/KycAgeVerificationIncludeParentalControl'
    KycAgeVerificationAgeThreshold:
      type: integer
      minimum: 0
      maximum: 120
      description: >-
        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.
    KycAgeVerificationPhoneNumber:
      description: >-
        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 '+'.
      type: string
      pattern: '^\+[1-9][0-9]{4,14}$'
      example: '+123456789'
    KycAgeVerificationIdDocument:
      type: string
      description: >-
        Id number associated to the official identity document in the country.
        It may contain alphanumeric characters.
    KycAgeVerificationName:
      type: string
      description: >-
        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.
    KycAgeVerificationGivenName:
      type: string
      description: First/given name or compound first/given name of the customer.
    KycAgeVerificationFamilyName:
      type: string
      description: 'Last name, family name, or surname of the customer.'
    KycAgeVerificationMiddleNames:
      type: string
      description: Middle name/s of the customer.
    KycAgeVerificationFamilyNameAtBirth:
      type: string
      description: Last/family/sur- name at birth of the customer.
    KycAgeVerificationBirthdate:
      type: string
      format: date
      description: >-
        The birthdate of the customer, in RFC 3339 / ISO 8601 calendar date
        format (YYYY-MM-DD).
    KycAgeVerificationEmail:
      type: string
      format: email
      description: >-
        Email address of the customer in the RFC specified format
        (local-part@domain).
    KycAgeVerificationIncludeContentLock:
      type: boolean
      default: false
      description: >-
        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.
    KycAgeVerificationIncludeParentalControl:
      type: boolean
      default: false
      description: >-
        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.
    KycAgeVerificationVerifyResponseBody:
      type: object
      description: Response to an age verification request
      required:
        - ageCheck
      properties:
        ageCheck:
          $ref: '#/components/schemas/KycAgeVerificationAgeCheck'
        verifiedStatus:
          $ref: '#/components/schemas/KycAgeVerificationVerifiedStatus'
        identityMatchScore:
          $ref: '#/components/schemas/KycAgeVerificationIdentityMatchScore'
        contentLock:
          $ref: '#/components/schemas/KycAgeVerificationContentLock'
        parentalControl:
          $ref: '#/components/schemas/KycAgeVerificationParentalControl'
    KycAgeVerificationAgeCheck:
      type: string
      description: >-
        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.
      enum:
        - 'true'
        - 'false'
        - not_available
    KycAgeVerificationVerifiedStatus:
      type: boolean
      description: >
        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.
    KycAgeVerificationIdentityMatchScore:
      type: integer
      minimum: 0
      maximum: 100
      description: >-
        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.
    KycAgeVerificationContentLock:
      type: string
      description: >-
        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.
      enum:
        - 'true'
        - 'false'
        - not_available
    KycAgeVerificationParentalControl:
      type: string
      description: >-
        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.
      enum:
        - 'true'
        - 'false'
        - not_available
    KycAgeVerificationApiError:
      required:
        - code
        - details
        - ref
        - title
      type: object
      properties:
        code:
          type: string
          description: code of the error
        title:
          type: string
          description: title of the error
        ref:
          type: string
          description: ref of the error
        details:
          type: string
          description: details of the error
    KycTenureApiError:
      required:
        - code
        - details
        - ref
        - title
      type: object
      properties:
        code:
          type: string
          description: code of the error
        title:
          type: string
          description: title of the error
        ref:
          type: string
          description: ref of the error
        details:
          type: string
          description: details of the error
    KycTenureTenure:
      description: >-
        Specifies date from which continuous tenure of the identified mobile
        subscriber is required to be confirmed
      type: object
      properties:
        phoneNumber:
          $ref: '#/components/schemas/KycTenurePhoneNumber'
        tenureDate:
          type: string
          description: >-
            The date, in RFC 3339 / ISO 8601 compliant format "YYYY-MM-DD", from
            which continuous tenure of the identified network subscriber is
            required to be confirmed. The date must not be in the future (i.e.,
            it must be less than or equal to the current date). If a future date
            is provided, a `400 INVALID_ARGUMENT` error will be returned.
          format: date
          example: '2023-07-03'
      required:
        - tenureDate
        - phoneNumber
    KycTenurePhoneNumber:
      description: >-
        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 '+'.
      type: string
      pattern: '^\+[1-9][0-9]{4,14}$'
      example: '+123456789'
    KycTenureTenureInfo:
      properties:
        tenureDateCheck:
          description: >
            `true` when the identified mobile subscription has had valid tenure
            since `tenureDate`, otherwise `false`
          example: true
          type: boolean
        contractType:
          description: >
            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
          example: PAYM
          type: string
          enum:
            - PAYG
            - PAYM
            - Business
      required:
        - tenureDateCheck
    ConsentInfoXCorrelator:
      description: Value for the x-correlator
      type: string
      pattern: '^[a-zA-Z0-9-_:;.\/<>{}]{0,256}$'
      example: b4333c46-49c0-4f62-80d7-f0ef930f1c46
    ConsentInfoPhoneNumber:
      type: string
      description: >-
        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}$'
      example: '+123456789'
    ConsentInfoRetrieveStatusRequestBody:
      type: object
      description: >
        The request body for the retrieve status request. It contains the
        requested scope(s), the Purpose for which the API Consumer intends to
        process the User's personal data, a flag indicating whether the API
        Consumer requests a Consent capture URL and optionally the phone number
        of the User. The phone number is required when the API is invoked using
        a two-legged access token, but MUST NOT be provided when a three-legged
        access token is used, as the subject will be uniquely identified from
        the access token.
      required:
        - phoneNumber
        - clientId
        - scopes
        - purpose
        - requestCaptureUrl
      properties:
        phoneNumber:
          $ref: '#/components/schemas/ConsentInfoPhoneNumber'
        clientId:
          type: string
          description: >-
            The client identifier of the API Consumer, as registered with the
            API Provider.
          example: api-consumer
        scopes:
          $ref: '#/components/schemas/ConsentInfoScopes'
        purpose:
          $ref: '#/components/schemas/ConsentInfoPurpose'
        requestCaptureUrl:
          type: boolean
          description: >
            A boolean flag indicating whether the API Consumer requests API
            Provider to return a Consent capture URL.

            * `true` - If set to `true` the API will include a `captureUrl` in
            the response body if applicable.

            * `false` - The API will omit the Consent capture URL from the
            response.
          example: true
    ConsentInfoScopes:
      type: array
      minItems: 1
      items:
        type: string
      description: >
        List of requested scopes. The scope is a string that represents the
        access rights that the API Consumer is requesting from the User.
      example:
        - 'location-verification:verify'
    ConsentInfoPurpose:
      type: string
      pattern: '^dpv:[a-zA-Z0-9]+$'
      description: >
        The reason for which personal data will be processed by the 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](https://w3c.github.io/dpv/2.0/dpv/) (DPV) to represent these
        purposes e.g. `dpv:FraudPreventionAndDetection` or
        `dpv:RequestedServiceProvision`.
      example: 'dpv:FraudPreventionAndDetection'
    ConsentInfoRetrieveStatusResponseBody:
      type: object
      required:
        - statusInfo
      properties:
        statusInfo:
          $ref: '#/components/schemas/ConsentInfostatusInfo'
        captureUrl:
          type: string
          format: url
          description: >
            URL where the User can provide the necessary Consent. This field is
            only present in the API response if the API Consumer requests it and
            if the following conditions are met:


            - `statusInfo[*].statusValidForProcessing` is `false`, and

            - `statusInfo[*].statusReason` is `PENDING`, `REQUESTED` or
            `EXPIRED`.


            Please note that this field is only applicable when the User Consent
            is required to enable valid data processing. A unique URL is
            provided to authorise all items in the statusInfo list that require
            user action.
          example: 'https://example.org/consent-capture-url'
    ConsentInfostatusInfo:
      type: array
      description: >
        Provides information about the validity status of the requested data
        processing for the specified scope(s) and Purpose. It contains details
        of whether the processing of the data is currently valid and, if not,
        the reason why. The expiration date of the validity may be also provided
        if applicable.


        More than one array item may be required for the requested scope(s) and
        Purpose, e.g. when the requested scopes relate to multiple APIs.
      items:
        $ref: '#/components/schemas/ConsentInfostatusInfoObject'
      minItems: 1
    ConsentInfostatusInfoObject:
      type: object
      required:
        - scopes
        - purpose
        - statusValidForProcessing
      properties:
        scopes:
          $ref: '#/components/schemas/ConsentInfoScopes'
        purpose:
          $ref: '#/components/schemas/ConsentInfoPurpose'
        statusValidForProcessing:
          type: boolean
          description: >
            Boolean flag that shows the validity status of the requested data
            processing for the specified scope(s) and Purpose.

            * `true` - indicates that the current status is valid and permits
            the requested data processing.

            * `false` - indicates that the requested data processing is not
            permitted. The reason for this is provided in the `statusReason`
            field.
        statusReason:
          type: string
          enum:
            - PENDING
            - REQUESTED
            - REVOKED
            - EXPIRED
            - OBJECTED
          description: >
            This field must be present if `statusValidForProcessing` is `false`.
            It indicates the reason why the requested data processing is not
            permitted for the specified scope(s) and Purpose. It provides API
            Consumers with additional context on the current validity status,
            helping them to understand its applicability and the next steps they
            may need to take.


            It is particularly useful for determining whether the API Consumer
            should prompt the User to take action, such as providing Consent or
            renewing an existing Consent.


            Possible values are:


            - `PENDING`: The requested data processing has not yet been
            established or fully validated under the applicable privacy
            regulations.
                        For example, the User has not yet provided Consent when it is required.
            - `REQUESTED`: The permission for the requested data processing has
            been submitted but has not yet been granted or confirmed.
                        This is common when the API Consumer has initiated a request for Consent capture, but the User has not yet completed the process. For example, this occurs when a notice prompting the User to provide Consent has been displayed, but they have not yet made a decision.
            - `REVOKED`: The User has actively withdrawn their permission for
            the requested data processing after previously opting in.
                        For example, the User revokes their Consent for the data processing.
            - `OBJECTED`: The user has opted out of the requested data
            processing, despite a previous explicit opt-in not being required.
                        This is common when the User has exercised their right to object to data processing under the applicable privacy regulations.
            - `EXPIRED`: When applicable, the validity of the data processing
            has ceased due to the passage of time or a pre-defined condition.
                        This is common for time-limited Consents.
        expirationDate:
          type: string
          format: date-time
          description: >
            The date and time at which the validity of the data processing is
            set to expire or has expired.

            It applies mainly to time-limited Consents, or other cases where a
            specific duration of validity is defined for the data processing.
            This field is only applicable:


            - if `statusValidForProcessing` is `true` (indicating a future
            expiration), or

            - if `statusValidForProcessing` is `false` and `statusReason` is
            `EXPIRED` (indicating the past expiration date).


            It must follow [RFC
            3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and
            must have time zone. Recommended format is
            yyyy-MM-dd'T'HH:mm:ss.SSSZ (i.e. which allows
            2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z).
          example: '2023-07-03T14:27:08.312+02:00'
    ConsentInfoApiError:
      required:
        - code
        - details
        - ref
        - title
      type: object
      properties:
        code:
          type: string
          description: code of the error
        title:
          type: string
          description: title of the error
        ref:
          type: string
          description: ref of the error
        details:
          type: string
          description: details of the error
    NumberRecyclingXCorrelator:
      type: string
      example: b4333c46-49c0-4f62-80d7-f0ef930f1c46
    NumberRecyclingCreateCheck:
      type: object
      required:
        - specifiedDate
        - phoneNumber
      properties:
        phoneNumber:
          $ref: '#/components/schemas/NumberRecyclingPhoneNumber'
        specifiedDate:
          type: string
          format: date
          description: >-
            Specified date to check whether there has been a change in the
            subscriber associated with the specific phone number, in RFC 3339
            calendar date format (YYYY-MM-DD).
          example: '2024-10-31'
    NumberRecyclingPhoneNumber:
      description: >-
        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 '+'.
      type: string
      pattern: '^\+[1-9][0-9]{4,14}$'
      example: '+123456789'
    NumberRecyclingCheckInfo:
      type: object
      required:
        - phoneNumberRecycled
      properties:
        phoneNumberRecycled:
          type: boolean
          description: >
            Set to true (Boolean, not string) when there has been a change in
            the subscriber associated with the specific phone number after
            “specifiedDate”.
    NumberRecyclingApiError:
      required:
        - code
        - details
        - ref
        - title
      type: object
      properties:
        code:
          type: string
          description: code of the error
        title:
          type: string
          description: title of the error
        ref:
          type: string
          description: ref of the error
        details:
          type: string
          description: details of the error
    LocationRetrievalRetrievalRequest:
      description: >-
        Request to retrieve the location of a device. Device is not required
        when using a 3-legged access token, following the rules in the
        description.
      type: object
      required:
        - phoneNumber
      properties:
        phoneNumber:
          $ref: '#/components/schemas/LocationRetrievalPhoneNumber'
        device:
          $ref: '#/components/schemas/LocationRetrievalDevice'
        maxAge:
          type: integer
          description: >-
            Maximum age of the location information which is accepted for the
            location retrieval (in seconds). Absence of maxAge means "any age"
            and maxAge=0 means a fresh calculation.
        maxSurface:
          type: integer
          minimum: 1
          description: >-
            Maximum surface in square meters which is accepted by the client for
            the location retrieval. Absence of maxSurface means "any surface
            size".
          example: 1000000
    LocationRetrievalDevice:
      description: >
        End-user device able to connect to a mobile network. Examples of devices
        include smartphones or IoT sensors/actuators.


        The developer can choose to provide the below specified device
        identifiers:


        * `ipv4Address`

        * `ipv6Address`

        * `phoneNumber`

        * `networkAccessIdentifier`

        NOTE1: the network operator might support only a subset of these
        options. The API invoker can provide multiple identifiers to be
        compatible across different network operators. In this case the
        identifiers MUST belong to the same device. Where more than one device
        identifier is provided, only one identifier will be selected by the
        implementation and this choice indicated to the API consumer in the
        response.

        NOTE2: as for this Commonalities release, we are enforcing that the
        networkAccessIdentifier is only part of the schema for future-proofing,
        and CAMARA does not currently allow its use. After the CAMARA
        meta-release work is concluded and the relevant issues are resolved, its
        use will need to be explicitly documented in the guidelines.
      type: object
      properties:
        phoneNumber:
          $ref: '#/components/schemas/LocationRetrievalPhoneNumber'
        networkAccessIdentifier:
          $ref: '#/components/schemas/LocationRetrievalNetworkAccessIdentifier'
        ipv4Address:
          $ref: '#/components/schemas/LocationRetrievalDeviceIpv4Addr'
        ipv6Address:
          $ref: '#/components/schemas/LocationRetrievalDeviceIpv6Address'
    LocationRetrievalPhoneNumber:
      description: >-
        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 '+'.
      type: string
      pattern: '^\+[1-9][0-9]{4,14}$'
      example: '+123456789'
    LocationRetrievalNetworkAccessIdentifier:
      description: >-
        A public identifier addressing a subscription in a mobile network. In
        3GPP terminology, it corresponds to the GPSI formatted with the External
        Identifier ({Local Identifier}@{Domain Identifier}). Unlike the
        telephone number, the network access identifier is not subjected to
        portability ruling in force, and is individually managed by each
        operator.
      type: string
      example: 123456789@domain.com
    LocationRetrievalDeviceIpv4Addr:
      type: object
      description: >
        The device should be identified by either the public (observed) IP
        address and port as seen by the application server, or the private
        (local) and any public (observed) IP addresses in use by the device
        (this information can be obtained by various means, for example from
        some DNS servers).


        If the allocated and observed IP addresses are the same (i.e. NAT is not
        in use) then  the same address should be specified for both
        publicAddress and privateAddress.


        If NAT64 is in use, the device should be identified by its publicAddress
        and publicPort, or separately by its allocated IPv6 address (field
        ipv6Address of the Device object)


        In all cases, publicAddress must be specified, along with at least one
        of either privateAddress or publicPort, dependent upon which is known.
        In general, mobile devices cannot be identified by their public IPv4
        address alone.
      properties:
        publicAddress:
          $ref: '#/components/schemas/LocationRetrievalSingleIpv4Addr'
        privateAddress:
          $ref: '#/components/schemas/LocationRetrievalSingleIpv4Addr'
        publicPort:
          $ref: '#/components/schemas/LocationRetrievalPort'
      anyOf:
        - required:
            - publicAddress
            - privateAddress
        - required:
            - publicAddress
            - publicPort
      example:
        publicAddress: 84.125.93.10
        publicPort: 59765
    LocationRetrievalSingleIpv4Addr:
      description: A single IPv4 address with no subnet mask
      type: string
      format: ipv4
      example: 84.125.93.10
    LocationRetrievalPort:
      description: TCP or UDP port number
      type: integer
      minimum: 0
      maximum: 65535
    LocationRetrievalDeviceIpv6Address:
      description: >
        The device should be identified by the observed IPv6 address, or by any
        single IPv6 address from within the subnet allocated to the device (e.g.
        adding ::0 to the /64 prefix).
      type: string
      format: ipv6
      example: '2001:db8:85a3:8d3:1319:8a2e:370:7344'
    LocationRetrievalDeviceResponse:
      description: >
        An identifier for the end-user equipment able to connect to the network
        that the response refers to. This parameter is only returned when the
        API consumer includes the `device` parameter in their request (i.e. they
        are using a two-legged access token), and is relevant when more than one
        device identifier is specified, as only one of those device identifiers
        is allowed in the response.

        If the API consumer provides more than one device identifier in their
        request, the API provider must return a single identifier which is the
        one they are using to fulfil the request, even if the identifiers do not
        match the same device. API provider does not perform any logic to
        validate/correlate that the indicated device identifiers match the same
        device. No error should be returned if the identifiers are otherwise
        valid to prevent API consumers correlating different identifiers with a
        given end user.
      allOf:
        - $ref: '#/components/schemas/LocationRetrievalDevice'
        - maxProperties: 1
    LocationRetrievalLocation:
      type: object
      description: Device location
      required:
        - lastLocationTime
        - area
      properties:
        lastLocationTime:
          $ref: '#/components/schemas/LocationRetrievalLastLocationTime'
        area:
          $ref: '#/components/schemas/LocationRetrievalArea'
        device:
          $ref: '#/components/schemas/LocationRetrievalDeviceResponse'
    LocationRetrievalArea:
      type: object
      required:
        - areaType
      properties:
        areaType:
          type: string
      discriminator:
        propertyName: areaType
        mapping:
          CIRCLE: '#/components/schemas/LocationRetrievalCircle'
          POLYGON: '#/components/schemas/LocationRetrievalPolygon'
      oneOf:
        - $ref: '#/components/schemas/LocationRetrievalCircle'
        - $ref: '#/components/schemas/LocationRetrievalPolygon'
    LocationRetrievalCircle:
      description: Circular area
      type: object
      required:
        - center
        - radius
        - areaType
      properties:
        areaType:
          type: string
          enum:
            - CIRCLE
          default: CIRCLE
        center:
          $ref: '#/components/schemas/LocationRetrievalPoint'
        radius:
          type: number
          description: Distance from the center in meters
          minimum: 1
    LocationRetrievalPolygon:
      description: Polygonal area
      type: object
      required:
        - boundary
        - areaType
      properties:
        areaType:
          type: string
          enum:
            - POLYGON
          default: POLYGON
        boundary:
          $ref: '#/components/schemas/LocationRetrievalPointList'
    LocationRetrievalPointList:
      description: List of points defining a polygon
      type: array
      items:
        $ref: '#/components/schemas/LocationRetrievalPoint'
      minItems: 3
      maxItems: 15
    LocationRetrievalPoint:
      type: object
      description: 'Coordinates (latitude, longitude) defining a location in a map'
      required:
        - latitude
        - longitude
      properties:
        latitude:
          $ref: '#/components/schemas/LocationRetrievalLatitude'
        longitude:
          $ref: '#/components/schemas/LocationRetrievalLongitude'
      example:
        latitude: 50.735851
        longitude: 7.10066
    LocationRetrievalLastLocationTime:
      description: >-
        Last date and time when the device was localized. It must follow [RFC
        3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and
        must have time zone.
      format: date-time
      type: string
      example: '2023-09-07T10:40:52Z'
    LocationRetrievalLatitude:
      description: Latitude component of a location
      type: number
      format: double
      minimum: -90
      maximum: 90
    LocationRetrievalLongitude:
      description: Longitude component of location
      type: number
      format: double
      minimum: -180
      maximum: 180
    LocationRetrievalErrorInfo:
      description: Common schema for errors
      type: object
      required:
        - status
        - code
        - message
      properties:
        status:
          type: integer
          description: HTTP response status code
        code:
          type: string
          description: A human-readable code to describe the error
        message:
          type: string
          description: A human-readable description of what the event represents
    LocationRetrievalApiError:
      required:
        - code
        - details
        - ref
        - title
      type: object
      properties:
        code:
          type: string
          description: code of the error
        title:
          type: string
          description: title of the error
        ref:
          type: string
          description: ref of the error
        details:
          type: string
          description: details of the error
  responses:
    DeviceSwapGeneric400:
      description: 'Bad Request '
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/DeviceSwapApiError'
    DeviceSwapGeneric401:
      description: Unauthorized
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/DeviceSwapApiError'
    DeviceSwapGeneric403:
      description: Forbidden
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/DeviceSwapApiError'
    DeviceSwapGeneric404:
      description: Not found
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/DeviceSwapApiError'
    DeviceSwapGeneric422:
      description: Unprocessable Content
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/DeviceSwapApiError'
    DeviceSwapGeneric500:
      description: Internal Server Error
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/DeviceSwapApiError'
    DeviceSwapGeneric503:
      description: Service Unavailable
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/DeviceSwapApiError'
    DeviceSwapGeneric504:
      description: Gateway Timeout
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/DeviceSwapApiError'
    KycMatchGeneric400:
      description: Problem with the client request.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycMatchApiError'
    KycMatchGeneric401:
      description: >-
        Authentication problem with the client request. Unauthorized error. 
        Access Token related errors.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycMatchApiError'
    KycMatchGeneric403:
      description: |
        Client does not have sufficient permission.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycMatchApiError'
    KycMatchGeneric404:
      description: |
        Not Found error. Error if URL is wrong / user is not found.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycMatchApiError'
    KycMatchGeneric500:
      description: >-
        Server error.  Problem with MNO's server side.  Some processing error
        within MNO's servers.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycMatchApiError'
    KycMatchGeneric503:
      description: >-
        Service unavailable. Typically the server is down.  Problem with MNO's
        server side.  Any unexpected error within MNO's servers.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycMatchApiError'
    KycMatchGeneric504:
      description: >-
        Request time exceeded. If it happens repeatedly, consider reducing the
        request complexity
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycMatchApiError'
    KycAgeVerificationGeneric400:
      description: Problem with the client request.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycAgeVerificationApiError'
    KycAgeVerificationGeneric401:
      description: >-
        Authentication problem with the client request. Unauthorized error. 
        Access Token related errors.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycAgeVerificationApiError'
    KycAgeVerificationGeneric403:
      description: |
        Client does not have sufficient permission.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycAgeVerificationApiError'
    KycAgeVerificationGeneric404:
      description: |
        Not Found error. Error if URL is wrong / user is not found.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycAgeVerificationApiError'
    KycAgeVerificationGeneric422:
      description: >
        Unprocessable entity.  The server understands the content type of the
        request entity and the syntax of the request entity is correct, but it
        was unable to process the contained instructions.  For example, this
        error can be returned when the subject of the API cannot be identified
        from the provided parameters or when there is a mismatch between the
        subject identified from the access token and the one provided in the
        request.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycAgeVerificationApiError'
    KycAgeVerificationGeneric500:
      description: >-
        Server error.  Problem with MNO's server side.  Some processing error
        within MNO's servers.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycAgeVerificationApiError'
    KycAgeVerificationGeneric503:
      description: >-
        Service unavailable. Typically the server is down.  Problem with MNO's
        server side.  Any unexpected error within MNO's servers.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycAgeVerificationApiError'
    KycAgeVerificationGeneric504:
      description: >-
        Request time exceeded. If it happens repeatedly, consider reducing the
        request complexity
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycAgeVerificationApiError'
    KycTenureGeneric400:
      description: Problem with the client request.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycTenureApiError'
    KycTenureGeneric401:
      description: >-
        Authentication problem with the client request. Unauthorized error. 
        Access Token related errors.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycTenureApiError'
    KycTenureGeneric403:
      description: |
        Client does not have sufficient permission.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycTenureApiError'
    KycTenureGeneric404:
      description: |
        Not Found error. Error if URL is wrong / user is not found.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycTenureApiError'
    KycTenureGeneric422:
      description: >
        Unprocessable entity.  The server understands the content type of the
        request entity and the syntax of the request entity is correct, but it
        was unable to process the contained instructions.  For example, this
        error can be returned when the subject of the API cannot be identified
        from the provided parameters or when there is a mismatch between the
        subject identified from the access token and the one provided in the
        request.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/KycTenureApiError'
    ConsentInfoGeneric400:
      description: Problem with the client request
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ConsentInfoApiError'
    ConsentInfoGeneric401:
      description: Unauthorized
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ConsentInfoApiError'
    ConsentInfoGeneric403:
      description: |
        Client does not have sufficient permission.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ConsentInfoApiError'
    ConsentInfoGeneric422:
      description: Unprocessable Content
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ConsentInfoApiError'
    ConsentInfoGeneric500:
      description: Server error
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ConsentInfoApiError'
    ConsentInfoGeneric503:
      description: Service unavailable. Typically the server is down.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ConsentInfoApiError'
    ConsentInfoGeneric504:
      description: >-
        Request time exceeded. If it happens repeatedly, consider reducing the
        request complexity
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ConsentInfoApiError'
    NumberRecyclingGeneric200:
      description: OK
      headers:
        x-correlator:
          description: Correlation id for the different services
          schema:
            type: string
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/NumberRecyclingCheckInfo'
    NumberRecyclingGeneric400:
      description: Problem with the client request.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/NumberRecyclingApiError'
    NumberRecyclingGeneric401:
      description: >-
        Authentication problem with the client request. Unauthorized error. 
        Access Token related errors.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/NumberRecyclingApiError'
    NumberRecyclingGeneric403:
      description: |
        Client does not have sufficient permission.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/NumberRecyclingApiError'
    NumberRecyclingGeneric404:
      description: |
        Not Found error. Error if URL is wrong / user is not found.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/NumberRecyclingApiError'
    NumberRecyclingGeneric422:
      description: |
        Unprocessable Entity.  Problem with the client request.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/NumberRecyclingApiError'
    NumberRecyclingGeneric500:
      description: >-
        Server error.  Problem with MNO's server side.  Some processing error
        within MNO's servers.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/NumberRecyclingApiError'
    LocationRetrievalGeneric400:
      description: Bad Request
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/LocationRetrievalApiError'
    LocationRetrievalGeneric401:
      description: Unauthorized
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/LocationRetrievalApiError'
    LocationRetrievalGeneric403:
      description: Forbidden
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/LocationRetrievalApiError'
    LocationRetrievalGeneric404:
      description: Not found
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/LocationRetrievalApiError'
    LocationRetrievalGeneric422:
      description: Unprocessable Content
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/LocationRetrievalApiError'
  headers:
    ConsentInfox-correlator:
      description: Correlation id for the different services
      schema:
        type: string
    NumberRecyclingx-correlator:
      description: Correlation id for the different services
      schema:
        $ref: '#/components/schemas/NumberRecyclingXCorrelator'
  parameters:
    NumberRecyclingx-correlator:
      name: x-correlator
      in: header
      description: Correlation id for the different services
      schema:
        $ref: '#/components/schemas/NumberRecyclingXCorrelator'
  examples:
    LocationRetrievalRETRIEVAL_CIRCLE:
      summary: circle-based device location retrieval
      description: >-
        The device is localized within a circle with a center at the specified
        coordinates and a radius of 800 meters.
      value:
        lastLocationTime: '2023-10-17T13:18:23.682Z'
        area:
          areaType: CIRCLE
          center:
            latitude: 45.754114
            longitude: 4.860374
          radius: 800
    LocationRetrievalRETRIEVAL_POLYGON:
      summary: polygon-based device location retrieval
      description: >-
        The device is localized within a polygon delimited by the provided
        coordinates.
      value:
        lastLocationTime: '2023-10-17T13:18:23.682Z'
        area:
          areaType: POLYGON
          boundary:
            - latitude: 45.754114
              longitude: 4.860374
            - latitude: 45.753845
              longitude: 4.863185
            - latitude: 45.75249
              longitude: 4.861876
            - latitude: 45.751224
              longitude: 4.861125
            - latitude: 45.751442
              longitude: 4.859827
    LocationRetrievalLOCATION_CIRCLE_WITH_DEVICE:
      summary: >-
        circle-based device location retrieval, returning the device identifier
        used by the implementation
      description: >-
        The device is localized within a circle with a center at the specified
        coordinates and a radius of 800 meters. Response when the request used a
        2-legged access token with multiple device identifiers, or possibly only
        a single device identifier.
      value:
        lastLocationTime: '2023-10-17T13:18:23.682Z'
        area:
          areaType: CIRCLE
          center:
            latitude: 45.754114
            longitude: 4.860374
          radius: 800
        device:
          phoneNumber: '+123456789'
  securitySchemes:
    openId:
      description: OpenID Connect authentication
      type: openIdConnect
      openIdConnectUrl: 'https://example.com/.well-known/openid-configuration'
