Introduction

The CAMARA KYC Tenure API provides a standardized mechanism to customer with the ability to compare the information it (Service Provider, SP) has for a particular user with that on file (and verified) by the 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 user

API Authentication

HTTPS requests to the REST API are protected with 2-Legged OAuth. To learn more about how Orange Developer handles authentication, please refer to our documentation.

In short, you will use your Orange Developer Authorization header as authorization_header for the Basic authentication with Orange Developer.

You get the Authorization header credentials when you register your application on the Orange Developer Console (https://developer.orange.com/myapps).

curl -X POST \
-H "Authorization: {{ authorization_header }}" \
-d "grant_type=client_credentials" \
https://api.orange.com/openidconnect/playground/v1.0/token

In response, you will get an access_token.

{
  "token_type": "Bearer",
  "access_token": "66AeYJF8eJQ...2SjkFg9LB1LePC",
  "expires_in": 3600
}

Step 3: Access protected resources using OAuth access token

In order to call our API, the access_token is mandatory.

Specific documentation about match resource is provided below.

API Description

Summary of resources

This API has one resource check-tenure.

Summary of methods and URL

Summary of request body parameters

{
  "phoneNumber": "+990100000008",
  "tenureDate": "2026-05-01"
}

Summary of response parameters

Request

curl -X POST "https://api.orange.com/camara/playground/light/kyc-tenure/v0.2/check-tenure"
-H "Authorization: Bearer {your access token}"
-H "Cache-Control: no-cache"  
-H 'accept: application/json'
-H 'Content-Type: application/json'
-d  '{
       "tenureDate": "2026-05-01"
  }'

Response

200 Check successful
Content-Type: application/json

{
    "tenureDateCheck ": true
}

Fields description

Most frequent errors

If invalid input are provided in particular for the device identifier a 400 error is triggered.

HTTP/1.1 400 Invalid input
Content-Type: application/json
{
  "code": "INVALID_ARGUMENT",
  "status": 400,
  "message": "Invalid input"
}

If the network back end is not able to localize the equipment, a 404 error is sent.

HTTP/1.1 404 Not Found
Content-Type: application/json
{
  "status": 404,
  "code": "NOT_FOUND",
  "message": "Unknown Location"
}

If the localisation service is not up and running, a 503 error is sent.

HTTP/1.1 503 Service unavailable
Content-Type: application/json
{
  "code": "UNAVAILABLE",
  "status": 503,
  "message": "Service unavailable"
}

There are some cases where your client application will no longer gain access to API resources, and get an error back.

Please check the following points:

• Here, you attempt to use an expired or revoked access_token and you get an invalid token error. You will have to request a new access_token. As an example:

HTTP/1.1 401 Unauthorized
Content-Type: application/json
{
  "code": "UNAUTHENTICATED",
  "status": 401,
  "message": "Authorization failed: ..."
}

• Here, you removed your subscription to the API so that the capability to generate an access_token is not allowed anymore. As an example:

HTTP/1.1 403 Forbidden
Content-Type: application/json
{
  "code": "PERMISSION_DENIED",
  "status": 403,
  "message": "Operation not allowed: ..."
}

Looking for support ?

Facing technical issue when using this API ? please contact us

History of document

Note: The version of the documentation is independent from the API version.