API v2

Use our Atlas API services as building blocks for creating seamless KYC and verification steps for your customers. The flow can be integrated into your existing mobile and web applications. And can be customised to your exact needs. Our APIs are RESTful and all our responses are returned as JSON.

For instance, let’s say you would like your users to upload a proof of ID (e.g. PAN or Passport), a live photograph and verify the user’s location to be India. You can achieve this by calling the following APIs: The extract API to verify and extract the details from the proof of ID; The verify API to verify that the document uploaded is authentic; The liveness check API to check that the photo/video uploaded is the true likeness of the user and is real and not spoof; The face match API to match the live photograph from the photograph from the ID; and the location check API to ensure that the geo location is India.

As you can note, if you can imagine a flow, then you can build them exactly they way you want it using our APIs. In addition to the APIs, we also provide mobile SDKs for document capture and face capture and face liveness. You can refer to our SDK for more information. If you do not want any integration, you can use our no code dashboard. You can get access to the dashboard by writing to [email protected].

Authentication

All Atlas APIs are authenticated using Basic Auth. Basic auth requires the following:

[YOUR_KEY_ID] and [YOUR_KEY_SECRET]

Basic auth needs an Authorization Header for each request in the base64 format. Here, base64token is a base64 encoded string of YOUR_KEY_ID:YOUR_KEY_SECRET. Please ensure that you get this format right to prevent API authentication errors.

All server-side API requests need to be authenticated using the unique API Keys provided to the user. The keys must be stored securely as it carries many privileges and must not be shared in publicly accessible areas such as client-side code. All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail.

You should use a Content-Type: application/json header with all PUT and POST requests except when uploading documents or photos. For these requests, use a Content-Type: multipart/form-data header. API credentials must be included in the header of all requests made to the API.

Environment

We provide a production environment with trial access. You can use the trial API key to integrate and test the APIs and use the production key for going live with your integration.

Errors

Atlas uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided (e.g., a required parameter was missing or invalid). Codes in the 5xx range indicate an error with our backend AWS servers.

All successful responses are returned with HTTP Status code 200. In case of failure, Atlas API returns a JSON error response with the parameters that detail the reason for the failure.

For V2 we are maintaining standard error format, where "type", "message", "fields" are constant for all errors. The value "fields" are mentioned for validation schema errors to say that this particular input param is wrong , for other errors like invalid_enpoint/method_incorrect, "fields" will be null

Error Codes

Error Response Parameters

Sample Error Responses

          {
                "error": {
                    "type": "resource_not_found",
                    "message": "The requested resource doesn't exist.",
                    "fields": "null"
                }
            }

// Example validation error with improper input. Here the field 'file_batch' has an invalid input value. 

{
                "error": {
                    "type": "validation_error",
                    "message": "null",
                    "fields": [
                        {
                            "file_batch": {
                                "message": "Invalid Input value. The maximum file_batch limit is 25 images."
                            }
                        }
                    ]
                }
            }

Document Types

The list of countries and the IDs supported for OCR can be found here. If you do not find your ID here, please contact [email protected]. We have a generic OCR engine from which the key value pairs are generated and we can quickly add your desired ID document once we process it through our OCR engine.

Country Codes

The supported country codes to be passed as parameters are outlined below.

Test in Postman

Postman is a simple application to test the APIs without having to write a line of code. This is pretty useful to have our APIs tested for your business needs before beginning your integration work. You can follow these steps to test our APIs in about 10 minutes.

Step 1 – Once you have installed Postman, you can download our API collections by clicking on “Run in Postman” button from our API page.

Step 2 – Click on “Postman for Windows” or “Run for MAC” in “Run in Postman” window.

Step 3 – Now the “API Documentation” collection will be imported to your system postman.

Step 4 – Click on the API from the Collections and go to the Authorization tab and fill in the Basic Auth credentials (Username and Password) received from FRS Labs.

Step 5 – Now you have to pass values in “Params” and “Body” referring to the API documentation.

Step 6 – Now click on “Send” to get a response.

Core Resources