Introduction

Welcome to the Veriff documentation.

Getting started with Veriff

Signing up

Fill-in the form at veriff.com and an e-mail with instructions on how to log in will be sent to you.

Logging in

Veriff’s environment can be accessed by going to Veriff Station. To log in for the first time, please use the link sent in the email and follow instructions.

Once you have set up your password, you will be presented with a QR code to set up the Authenticator application. We use two factor authentication for your Veriff account. You will need to download and install the Google Authenticator app on your mobile device. Please find it in the Apple App Store or in the Google Play Store

Open the app, select the "+" icon and scan the QR code on the screen. Use the generated PIN-code to log in.

New users for your colleagues can be created by an admin role account in Veriff Station Settings page.

Try our demos

Web

To try out the end-user facing verification flow, simply navigate to Veriff Demo - this will start the verification flow in your browser.

Mobile SDKs

Our mobile applications can be tested by downloading the demo versions: iOS / Android

Review Verifications

To review the submitted verification and its results, visit Veriff Station and View the individual verification sessions.

How to find your API keys

Your API keys are stored in the Veriff Station. Choose Integrations in the top menu, then integration you need.

Test Integrations are to be used for development and sessions will not count towards paid usage. Veriff will not provide decisions on sessions created for test integrations.

Sessions created for Live integrations will count towards usage and Veriff will be providing decisions for those.

Generating sessions for KYC with Veriff

Generating sessions manually

To generate a verification:

• Click "Verifications" on top menu
• Click "Add Verification" from the opened window
• Fill in the first name, last name
• Click "Generate Verification"
• Click on or copy the URL and finish the flow

You can see the completed verification in the Verifications list

Generating sessions in code

{
    "verification": {
        "callback": "https://this.is.your.redirect.url",
        "person": {
            "firstName": "John",
            "lastName": "Smith"
        },
        "lang": "en",
        "features": ["selfid"],
        "timestamp": "2016-05-19T08:30:25.597Z"
    }
}

The simplest way to get a KYC link for your user on the web, is to make a simple JSON object containing the user's name and the redirect(callback) URL to which the user will be sent after they complete KYC. Then use HTTP POST to send the object to https://api.veriff.me/v1/sessions, with Content-Type application/json and the X-AUTH-CLIENT header containing your API Key.

{
    "status": "success",
    "verification":{
        "id":"f04bdb47-d3be-4b28-b028-............",
        "url": "https://magic.veriff.me/v/sample-url.................",
        "sessionToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJh............",
        "baseUrl": "https://magic.veriff.me"
    }
}

In response, we give you a JSON session ID and a URL, as follows:

The URL of the KYC session is where you should redirect your user in your web front end.

The session ID should be saved on your end - you can tie back the webhook responses to your customer record that way.

Once the end user completes the KYC, they will be redirected back to the callback URL. If you do not specify it for each session call, then there is a default configured in your account settings. This "callback" could be to a "thank you" or waiting page on your side.

To be clear, the callback does not contain any decision or verification information yet. After the KYC process completes in the background, we notify your webhook endpoint (also configured in your account settings), or if you have not automated decisions yet, then you can look up the result by logging in to Veriff Station and checking the Verifications.

The full API for starting a KYC session with Veriff is documented here in the API: #sessions

Generating the X-SIGNATURE header

"verification": {
    "person": {
        "firstName": "John",
        "lastName": "Smith"
    },
    "features": ["selfid"],
    "timestamp": "2018-10-15T08:30:25.597Z"
}

The X-SIGNATURE header guarantees to us, that API calls are initiated by you. It is based on the shared secret (API secret) that is known only by you and by Veriff.

The X-SIGNATURE is a SHA-256 hex encoded hash of the concatenation of the request body and your API secret.

To generate the X-SIGNATURE header, please:

• serialize (stringify) the request (this should be your HTTP request body)
• in a temporary buffer, concatenate the request body and your API secret
• calculate a SHA 256 hash
• hex encode the hash

For example, if the request object is

{
    "verification": {
        "person": {
            "firstName": "John",
            "lastName": "Smith"
        },
        "features": ["selfid"],
        "timestamp": "2018-10-15T08:30:25.597Z"
    }
}

Next, the serialized JSON payload of the above object will look something like the following string

{
    "verification": {
        "person": {
            "firstName": "Joh..........."
        },
        "aeebd8dc-f646-4bc2.....": ".....etc"
    }
}

Then, you will need to concatenate the text of the serialized payload and the text of the API secret, so it will look something like

{"verification":{"person":{"firstName":"Joh...........}}aeebd8dc-f646-4bc2.....etc

Now you will need to calculate a SHA256 hash and hex encode it, as the description of that calculation is in the API spec at #sessions

This process depends on the language you use.

Using JavaScript / ECMA

To view the code sample select the language at the top-right

const payload = JSON.stringify(verification);
const signature = crypto.createHash('sha256');
signature.update(new Buffer(payload, 'utf8'));
signature.update(new Buffer(secret, 'utf8'));
return signature.digest('hex');

Using C# / .Net

To view the code sample select the language at the top-right

string hashString;
using (var sha256 = SHA256Managed.Create())
{
    var hash = sha256.ComputeHash(Encoding.Default.GetBytes(payloadPlusSecret));
    hashString = ToHex(hash, false);
}

Integrations

Android SDK integration

Requirements

Veriff Android SDK requiers Android 5.0 or newer.

Adding the SDK

allprojects {
    repositories {
        maven { url "https://cdn.veriff.me/android/" } //veriff
        google()
        jcenter()

    }
}

Open the root build.gradle file and add a new maven destination to the repositories in the allprojects section.

Add the Veriff SDK dependency to the application build.gradle file: implementation 'com.veriff:veriff-library:2.4.8'

Permissions

The SDK will request all the permissions it needs, please make sure that the CAMERA, RECORD_AUDIO, and WRITE_EXTERNAL_STORAGE permissions are not explicitly removed using tools:node="remove" in your app`s manifest file. Ignore this if you are not explicitly removing any permissions.

Starting the verification flow

The verification flow must be launched from the vendor Activity class with a unique session. A session is valid for 7 days and expires automatically after that.

Veriff.Builder veriffSDK = new Veriff.Builder("https://magic.veriff.me", sessionToken);
veriffSDK.launch(MainActivity.this, REQUEST_CODE);

Parameters are defined as below

Parameters	Description
sessionToken	sessionToken should be unique for each call. Check /sessions endpoint in the API documentation here to learn how to generate one.
REQUEST_CODE	Define an integer constant REQUEST_CODE in the vendor activity which can be used to compare in onActivityResult

Getting the verification status

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    if (requestCode == REQUEST_CODE && data != null) {
        int statusCode = data.getIntExtra(VeriffConstants.INTENT_EXTRA_STATUS, Integer.MIN_VALUE);
        String sessionToken = data.getStringExtra(VeriffConstants.INTENT_EXTRA_SESSION_URL);
        handleResult(statusCode, sessionToken); //see below to know how to handle result
    }
    super.onActivityResult(requestCode, resultCode, data);
}

public void handleResult(int statusCode, String sessionToken){
    if (statusCode == VeriffConstants.STATUS_USER_FINISHED) {
        // User finished the session, there might be other callbacks coming after this one. (for example if the images are still being uploaded in the background)
    } else if (statusCode == VeriffConstants.STATUS_ERROR_NO_IDENTIFICATION_METHODS_AVAILABLE) {
        // No identifications methods available
    } else if (statusCode == VeriffConstants.STATUS_ERROR_SETUP) {
        // issue with the provided vendor data
    } else if (statusCode == VeriffConstants.STATUS_ERROR_UNKNOWN) {
        // Unknown error occurred.
    } else if (statusCode == VeriffConstants.STATUS_ERROR_NETWORK) {
        // Network is unavailable.
    } else if (statusCode == VeriffConstants.STATUS_USER_CANCELED) {
        // User cancelled the session.
    } else if (statusCode == VeriffConstants.STATUS_UNABLE_TO_ACCESS_CAMERA) {
        // Failed to access device's camera. (either access denied or there are no usable cameras)
    } else if (statusCode == VeriffConstants.STATUS_UNABLE_TO_START_CAMERA) {
        // Failed to start the device's camera.
    } else if (statusCode == VeriffConstants.STATUS_UNABLE_TO_RECORD_AUDIO) {
        // Failed to access device's microphone.
    } else if (statusCode == VeriffConstants.STATUS_SUBMITTED) {
        // Photos are successfully uploaded.
    } else if (statusCode == VeriffConstants.STATUS_ERROR_SESSION) {
        // Invalid sessionToken is passed to the Veriff SDK.
    } else if (statusCode == VeriffConstants.STATUS_DONE) {
        // Session is completed from clients perspective.
    } else if (statusCode == VeriffConstants.STATUS_ERROR_UNSUPPORTED_SDK_VERSION) {
        // This version of Veriff SDK is deprecated.
    }
}

Veriff SDK sends callbacks to vendor`s mobile application. To capture the result override the onActivityResult method in the vendor activity that started the verification flow:

Note: After the verification data is uploaded, the SDK does not wait for the final verification result. The SDK only notifies whether the verification data upload was successful or not. The verification result is sent to the vendor`s server asynchronously in the background. (Reference for that can be found here).

Adding error logging

Veriff.setLoggingImplementation(<Instance of your logging class>);
Veriff.Builder veriffSDK = new Veriff.Builder(baseUrl, sessionToken);
veriffSDK.launch(MainActivity.this, REQUEST_CODE);

To turn on logging, you simply add your logging implementation instance (instance of LogAccess class) to the SDK before launching the SDK as shown.

Changelog

Below is a summary of changes introduced with each version of the Android SDK

iOS SDK integration

Requirements

Integration Veriff iOS SDK requires at least iOS version 10.0

Add framework to a project

To integrate Veriff SDK with Cocoapods, please add the line below to your Podfile and run pod install. New to Cocoapods? Learn more here.

pod 'VeriffSDK'

After installation is done, use the newly created .xcworkspace file of your project.

Using the Veriff iOS SDK

Add usage descriptions to application Info.plist

Not adding these usage descriptions causes system to kill application when it requests the permissions when needed.

Veriff iOS SDK requires camera and microphone permissions for capturing photos an video during identification. Your application is responsible to describe the reason why camera and microphone is used. You must add 2 descriptions listed below to info.plist of your application with the explanation of the usage.

• NSCameraUsageDescription
• NSMicrophoneUsageDescription

Import Veriff in your code

import Veriff

In order to use Veriff SDK, please import it to your class that will use the SDK.

Configure SDK before displaying it

Setting configuration parameters [Required]

let conf = VeriffConfiguration(sessionToken: token, sessionUrl: "https://magic.veriff.me")
let veriff = Veriff.shared
veriff.set(configuration: conf)

In order to start verification flow, you must configure the VeriffSDK first, to do that please call the method below with the token you receive from your backend implementation.

User Interface customization

You can customize Veriff user interface via your own application, by letting is know of your brand main color and logo.

See Veriff SDK customization guide document on how it looks.

let yourColor = UIColor.someColor()
let yourImage = UIImage(named: “NavigationBarImageName.png”)
conf.branding = Branding(themeColor: yourColor, navigationBarImage: yourImage)

Veriff iOS SDK allows the customization of theme color and navigation bar title image with Branding struct.

In order to use customization, please set the branding property of VeriffConfiguration before you start the verification.

Handling result codes from SDK

extension VerificationService: VeriffDelegate {
    func onSession(result: VeriffResult, sessionToken: String) {
         switch result.code {
             case .STATUS_DONE:
                // code
             case .STATUS_ERROR_SESSION:
                // code
             ...
             ...
         }
    }
}

Veriff SDK returns a number of result codes, that application can handle. Implement VeriffDelegate and assign it to delegate property of Veriff instance.

Here is list of all possible status codes

• UNABLE_TO_ACCESS_CAMERA User denied access to the camera
• STATUS_USER_CANCELED User canceled the verification process
• STATUS_SUBMITTED User submitted the photos
• STATUS_ERROR_SESSION The session token is either corrupt, or has expired. A new sessionToken needs to be generated
• STATUS_ERROR_NETWORK SDK could not connect to backend servers.
• STATUS_ERROR_NO_IDENTIFICATION_METHODS_AVAILABLE Given session cannot be started as there are no identification methods
• STATUS_DONE The session status is finished from clients perspective
• STATUS_ERROR_UNKNOWN An unknown error occurred

Start verification process

veriff.startAuthentication()

Alternatively you can pass a view controller that is used for presenting the verification UI. Please be aware that the view controller has to be in view hierarchy and not presenting.

startAuthentication(from viewController: UIViewController)

Veriff SDK looks for currently presented UIViewController from key UIWindows' root view controller. Using this view controller verification UI is presented.

Changelog

Below is a summary of changes introduced with each version of the SDK

Javascript SDK Integration

Veriff JS SDK, is a simple and customisable library which helps to integrate with Veriff Online Identity solution.

Repository in GitHub:

https://github.com/Veriff/veriff-js-sdk

Install

Include as a script tag:

<script src='https://cdn.veriff.me/sdk/js/veriff.min.js'></script>

add the CSS styles:

<link rel='stylesheet' href='https://cdn.veriff.me/sdk/js/styles.css'>

or install it via a package manager, styles are added inline

  $ npm install --save @veriff/js-sdk

   // CommonJS
  const Veriff = require('@veriff/js-sdk');

  // ES6 style import
  import Veriff from '@veriff/js-sdk';

Usage

Veriff JS SDK requires one parent element in HTML:

javascript <div id='veriff-root'></div>

In order to initialize the library, API Key, parentId and onSession callback function is required.

  var veriff = Veriff({
    apiKey: 'API_KEY',
    parentId: 'veriff-root',
    onSession: function(err, response) {
      // received the response, verification can be started now
    }
  });

  veriff.mount(); 

By default the following form will be rendered:

onSession function is executed after the response is received from the API, response body contains a verification object with following schema:

    {
      "status": "success",
      "verification": {
          "id": "UUID V4 Identifying the verification",
          "url": "full url to which a person should be redirected in order to proceed with verification flow",
          "host": "hostname",
          "status": "status of the verification",
          "sessionToken": "JWT encoded verification token"
      }
  }

In case the Given name / Last name or both are known, they can be passed to the SDK, therefore text input fields will not be rendered.

  veriff.setParams({
    person: {
      givenName: 'Foo',
      lastName: 'Bar',
      idNumber: 12345
    }
  });

// additionally the input labels and button text value can be customised.

  veriff.mount({
    formLabel: {
      givenName: 'First name',
      lastName: 'Family name',
      idNumber: 'Id'
    },
    submitBtnText: 'Veriff Me'
    loadingText: 'Please wait...'
  });

InContext Javascript SDK Integration

This is an experimental integration and API might change.

Installation

npm install @veriff/incontext-sdk

Usage

You need to have a Veriff session URL generated before initializing the SDK. Please, see our documentation to learn how to generate one.

// ES6
import { createVeriffFrame } from '@veriff/incontext-sdk';

// CommonJS
const { createVeriffFrame } = require('@veriff/incontext-sdk');

const veriffFrame = createVeriffFrame({ url: VERIFF_SESSION_URL })

This will render a modal with adapted Veriff application in iframe.

Listening for events

Pass onEvent callback function when initializing SDK

createVeriffFrame({
  url,
  onEvent: function(event) {
    //
  }
})

• event:
  • CANCELED - user closed the modal.
  • FINISHED - user finished verification flow.

Using with inline script

Include a script tag:

<script src='https://cdn.veriff.me/incontext/js/v1/veriff.js'></script>

window.veriffSDK.createVeriffFrame({ url: VERIFF_SESSION_URL });

API

createVeriffFrame([options])

Create modal with Veriff application.

• [options] - Configuration object.
  • url - Veriff session URL
  • onEvent - Event callback function

Returns an object that controls the modal.

.close()

Close Veriff modal. Normally modal will be closed due to user input, but if you want to control it(e.g. timeout), please use this function.

API Integration

There are a few scenarios where you may not wish to use Veriff's native SDK or Veriff's web interface to verify your customers. For example:

• you wish to completely implement your own front-end
• you wish to do an offline bulk audit of previously verified customers

In those cases, you can do the whole process using our API, according to the documentation, and not show any Veriff front end to your customers, or not expect customers to be present for the verification.

Here are the steps you should do to use the API for upload.

Create a new verification session

Create a new verification session using POST request to #sessions

The goal here is to create a new object (a verification session) that contains the one verification (referred to as 'verification', nested inside the session object in the response).

If you wish to restrict the accepted document to be the one you have on file, you can also send the document type, country, and number along with the session. Document type can be one of [‘PASSPORT’, ‘ID_CARD’, ‘RESIDENCE_PERMIT’, ‘DRIVERS_LICENSE'].

Send photos

Send photos (face, document front, document back, etc) by uploading all the pictures one by one using POST request to ‘/media’

The goal here is to upload the required photos and associate them with the verification created in step 1.

Documentation: /sessions/{sessionId} /media (POST)

Submit session for review

Submit the verification session using PATCH request to ‘/sessions/:id’

Once all the photos are uploaded, you would then update (PATCH) the verification to mark it into 'submitted' status. This marks the completion of the verification. This step requires all the photos to be submitted prior to triggering this.

Documentation: /sessions/{sessionid} (PATCH)

After these three steps, you've done your part, and the verification will then be taken care of by us.

Wait for webhook response

Veriff sends you a Decision event via Webhook using POST request. You will have to implement the listener.

This hook will be sent back asynchronously, and it contains more data, including the verified identity information.

Documentation: Webhook Decision (POST)

The webhook is sent to the URL that is configurable from Veriff Station under Integrations › Webhook Decision / Events URL.

Testing Integrations

You will have 1 Test integration pre-created for you in Veriff Station. You can create more test integrations if needed. The test integration will be used by you to test the communication between Veriff's and your system and to see how the responses are handled. Verification sessions generated for test integrations are not billed and not verified by Veriff.

To check quality of Veriff responses, please select plan and subscribe to a Trial on Billing page - this will allow to create Live integrations.

Testing verification sessions checklist

• New session is link generated
• Session data is saved with your customer record
• Sessions with odd names can be started
• Sessions with vendorData - do you get them back and do you perform actions on them
• User is graned access to your platform after receiving an "Approved" decision
• User is notified about verification failure after receiving "Resubmission" or "Declined" decision
• User is prompted to try again after receiving "Resubmission" decision
• In case of resubmitted session, user is directed to same SessionURL
• In case of disrupted session (browser close, user logout, etc), user should be directed back to earlier session
• In case generated session is over 7 days old (and thus in Expired or Abandonded status)- new session is generated
• At end of verification, callback URL redirects back to the correct place in your platform

Testing security

• Decision webhook with wrong API key should not be accepted
• Decision webhook with mismatched X-SIGNATURE should not be accepted
• Decision with invalid JSON should not break or crash your server

Testing responses

Each type of response should be accepted:

• Approved (Decision endpoint)
• Declined (Decision endpoint)
• Resubmission Requested (Decision endpoint)
• Expired (Event endpoint)
• Abandoned (Event endpoint)

Automated responses

If you wish to test the behavior of your integration and receive certain decisions when testing your integration with Veriff's service, create the sessions and include the desired decision - "Approve", "Decline", "Resubmit" in the "firstName" field.

This way, after going through the verification flow, you will receive an automated response with the desired decision. The feature can be used to test out the integration behavior on your side and see how Veriff's responses are handled. This will work only when using a test integration. Verifications done with live integrations will be treated as standard and these should not be used for testing purposes.

If you wish to receive certain client or document data along with the verification decision response, you can include data this in the initialization data when creating the verification session, it will be retained throughout the verification and included in the decision webhook response. json { "lang": "en", "person": { "idNumber": "38218.9318", "lastName": "Approved", "firstName": "Approve" }, "callback": "https://awesome.page", "document": { "type": "ID_CARD", "number": "Q021234567", "country": "EE", "nationality": "EE" }, "features": [ "selfid" ], "timestamp": "2016-05-19T08:30:25.597Z", "vendorData": "11111111" }

Testing process in your app

You should test the handling of best cases as well as edge cases

• approved users handled or notified as appropriate
• declined users handled as appropriate, your back office notified if necessary
• in case of resubmission request, user is invited back to try KYC again using the same sessionURL
• in case of Expired or Abandoned session (after 7 days), user is not offered to continue from same session, new session URL is created

Mobile testing

Test our demo app by downloading it in the app store. iOS / Android

API Upload testing

Required tools
Veriff's integration demo - js-integration-demo-master.zip
Node.js - (Download - https://nodejs.org/en/download/)
Notepad/TextEdit (default in Windows/Mac) or Notepad++ - (Download - https://notepad-plus-plus.org/)

1. Download and install Node.js
2. Download and extract js-integration-demo-master.zip
3. Open Command (Windows) or Terminal (Mac) on your local computer.
4. Navigate to js-integration-demo-master folder cd C:\Users\User\Desktop\Veriff API).
5. Run command >npm install
6. Open app.js with your text editing app (Notepad/TextEdit) and update 'Your-API-Key' and 'Your-API-Token' to the values in your Backoffice account (Management -> Vendor). Tokens must be in single quotes. Save the file.
7. Run the app.js node app.js

Now the verification session is created and it is being processed. Check your Backoffice dashboard to review the data extracted and decision made by Veriff.

API Reference

Requirements

API Key and API token can be found by logged in customers on settings page.

Headers

X-AUTH-CLIENT: string (required) - API Key
CONTENT-TYPE: string (required) - Type for the request: (application/json)
X-SIGNATURE: string (required) - Request Body signed with API Secret.

X-Signature is a SHA-256 hex encoded hash. The stringified body is concatenated by the API Secret and then hex digested.

API URL https://api.veriff.me/v1

Note: Headers are sent with each request

Lifecycle of a verification:

Endpoints

In this post request the vendor sends the data of the client to Veriff and receives in return a unique sessionToken that is related to the client. You can find an example implementation for Javascript. https://github.com/Veriff/js-integration-demo

Available endpoints and methods:

• /sessions
  • /sessions /{sessionId}
  • /sessions/{sessionId} /media GET
  • /sessions/{sessionId} /media POST
  • /sessions/{sessionId} /person
  • /sessions/{sessionId} /timestamps
  • /sessions/{sessionId} /attempts
  • /sessions/{sessionId} /decision
• /media /{mediaId}
• /attempts
• /timestamps /{timestampId}

/sessions

Request Properties explained:

• callback: String | default is defined on settings - Callback url to which the client is redirected after the verification session is completed
  
• person: object - Person to be verified
  
  • firstName: String - First name
    
  • lastName: String - Last name
    
  • idNumber: String - Identification number
    
  • gender: String - Gender
    
• document: object - Document of a person to be verified
  
  • number: String - Document number
    
  • country: ISO-2 - String Issuing country of the document
    
  • type: PASSPORT - (PASSPORT, ID_CARD, DRIVERS_LICENSE, RESIDENCE_PERMIT) Document type
    
• additionalData: object - Data from the filled application. JSON object should not have any nested objects it’s just simple key value pair
  
• vendorData: string - Vendor specific data string, max 40 characters long, will be sent back unmodified using webhooks
  
• lang: String - | default: en User preferred language
  
• features: array - of strings (required)
  

Veriff provided features which will be used during the verification process. Currently available features are: selfid : Client identifies himself showing a document and taking a portrait pictures of him/herself.

- Example: features: ["selfid"]

timestamp: String (required)

Combined ISO 8601 date and time in UTC (YYYY-MM-DDTHH:MM:S+Timezone Offset|Z, i.e., 2018-04-18T11:02:05.261Z)

Request method: POST
Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
Content-Type: application/json

Sample Request

curl

curl -X POST \
  https://api.veriff.me/v1/sessions/ \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-API-KEY' \
  -d '{
    "verification": {
        "callback": "https://veriff.me",
        "person": {
            "firstName": "Tundmatu",
            "lastName": "Toomas",
            "idNumber": "123456789"
        },
        "document": {
            "number": "B01234567",
            "type": "PASSPORT",
            "country": "EE"
        },
        "additionalData": {
            "citizenship": "EE",
            "placeOfResidence": "Tallinn"
        },
        "vendorData": "11111111",
        "lang": "en",
        "features": [
            "selfid"
        ],
        "timestamp": "2016-05-19T08:30:25.597Z"
    }
}'

Node.js

var request = require("request");

var options = { method: 'POST',
  url: 'https://api.veriff.me/v1/sessions/',
  headers: 
   { 'Content-Type': 'application/json',
     'X-AUTH-CLIENT': 'Your-api-key' },
  body: 
   { verification: 
      { callback: 'https://veriff.me',
        person: 
         { firstName: 'Tundmatu',
           lastName: 'Toomas',
           idNumber: '123456789' },
        document: { number: 'B01234567', type: 'PASSPORT', country: 'EE' },
        additionalData: { citizenship: 'EE', placeOfResidence: 'Tallinn' },
        vendorData: '11111111',
        lang: 'en',
        features: [ 'selfid' ],
        timestamp: '2016-05-19T08:30:25.597Z' } },
  json: true };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Response Properties explained:

• status: String (required) Request status
• verification: object (required) Verification object
  • id: UUID-v4 String (required) UUID v4 which identifies the verification session
  • url: String (required) URL of the verification to which the person is redirected (Combination of the baseUrl and sessionToken)
  • sessionToken: String (required) Session specific token of the verification
  • baseUrl: String (required) The base url the sessionToken can be used for

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample RESPONSE

{ "status": "success",
  "verification":{
    "id":"f04bdb47-d3be-4b28-b028-a652feb060b5",
    "url": "https://magic.veriff.me/v/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdXRoX3Rva2VuIjoiOThiYzdjMjEtZTQ0Yy00MTZiLTkxOTMtMTU5ZGZkMzBmMDg4Iiwic2Vzc2lvbl9pZCI6Ijc2ODhmMzYzLTAyZjctNDE1My1iMzM1LWE0ODQ3OTRkMzZmNyIsImlhdCI6MTUwMTIyODI1MSwiZXhwIjoxNTAxODMzMDUxfQ.bMEF37E6-zT2Aa6Q8UXK3B_ZL51w6D_lxnGgQvhj214",
    "sessionToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdXRoX3Rva2VuIjoiOThiYzdjMjEtZTQ0Yy00MTZiLTkxOTMtMTU5ZGZkMzBmMDg4Iiwic2Vzc2lvbl9pZCI6Ijc2ODhmMzYzLTAyZjctNDE1My1iMzM1LWE0ODQ3OTRkMzZmNyIsImlhdCI6MTUwMTIyODI1MSwiZXhwIjoxNTAxODMzMDUxfQ.bMEF37E6-zT2Aa6Q8UXK3B_ZL51w6D_lxnGgQvhj214",
    "baseUrl": "https://magic.veriff.me"
  }
}

/sessions/{sessionId}

Method to change the status of the verification.

Request properties explained:

• verification: object (required)
• frontState: String (required) Type of a verification state to switch on to (done)
• status: String (required) Status of a verification (submitted)
• timestamp: String (required) Combined ISO 8601 date and time in UTC YYYY-MM-DDTHH:MM:S+Timezone Offset|Z, i.e., 2018-04-18T11:02:05.261Z)

Request method: PATCH
Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Request body signed with API Secret. Content-Type: application/json

Sample REQUEST

curl

curl -X PATCH \
  https://api.veriff.me/v1/sessions/fd5c1563-1d23-4b1a-ae46-7ba429927ed8 \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-API-KEY' \
  -H 'X-SIGNATURE: dd994f70b1150ae012f9c1d6d20adf7ed69780044835d39de20b00ffae0660a0' \
  -d '{
    "verification": {
      "status": "submitted",
      "frontState": "done",
      "timestamp": "2019-10-29T06:30:25.597Z"
    }
}'

Node.js

var request = require("request");

var options = { method: 'PATCH',
  url: 'https://api.veriff.me/v1/sessions/fd5c1563-1d23-4b1a-ae46-7ba429927ed8',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': 'dd994f70b1150ae012f9c1d6d20adf7ed69780044835d39de20b00ffae0660a0',
     'X-AUTH-CLIENT': 'Your-api-key' },
  body: 
   { verification: 
      { status: 'submitted',
        frontState: 'done',
        timestamp: '2019-10-29T06:30:25.597Z' } },
  json: true };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Response properties explained:

• status: String (required) Request status
• verification: object (required) Verification object
  • id: UUID-v4 String (required) UUID v4 which identifies the image
  • url: String (required) URL for the timestamp
  • host: String (required) Host URI
  • status: String (required) Status of the verification
  • sessionToken: String (required) Session specific token of the verification

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample RESPONSE

{
    "status": "success",
    "verification": {
        "id": "fd5c1563-1d23-4b1a-ae46-7ba429927ed8",
        "url": "https://front.veriff.me/v/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX2lkIjoiZmQ1YzE1NjMtMWQyMy00YjFhLWFlNDYtN2JhNDI5OTI3ZWQ4IiwiaWF0IjoxNTcyMzM4MDIwfQ.3HbNq0YWKAfFrH-P658_WXMwcUMubyC1aXAMo-umfCU",
        "vendorData": "11111111",
        "host": "https://front.veriff.me",
        "status": "submitted",
        "sessionToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX2lkIjoiZmQ1YzE1NjMtMWQyMy00YjFhLWFlNDYtN2JhNDI5OTI3ZWQ4IiwiaWF0IjoxNTcyMzM4MDIwfQ.3HbNq0YWKAfFrH-P658_WXMwcUMubyC1aXAMo-umfCU"
    }
}

/sessions/{sessionId}/media GET

Get the list of media objects with sessionId = {sessionId}

Request method: GET
Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Session ID signed with API Secret. Content-Type: application/json

Sample REQUEST:

curl

curl -X GET \
  https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/media \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-API-KEY' \
  -H 'X-SIGNATURE: 334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14' \

Node.js

var request = require("request");

var options = { method: 'GET',
  url: 'https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/media',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': '334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14',
     'X-AUTH-CLIENT': 'Your-api-key' } };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Response Properties explained:

• status: String (required) Status of the request
  
• videos: object (required) Array of JSON objects identifying the videos
  
  • id: UUID-v4 (required) Video Id
  • name: String (required) Video name
  • duration: String (required) Video duration in seconds
  • url: String (required) Video download url
  • size: String (required) Video size in KB
  • timestamp: object (required) Timestamp object
    • id: UUID-v4 (required) Timestamp Id
    • url: String (required) Timestamp url
• images: object (required) Array of JSON objects identifying the images
  • id: UUID-v4 (required) Image Id
  • name: String (required) Image name
  • url: String (required) Image download url
  • size: String (required) Image size in KB
  • timestamp: object (required) Timestamp object
    • id: UUID-v4 (required) Timestamp Id
    • url: String (required) Timestamp url

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample RESPONSE

{ "status": "success",
  "videos": [
    {
      "id": "{MEDIA_ID}",
      "name": "{VIDEO_NAME}",
      "duration": "{DURATION_IN_SECONDS}",
      "url": "{MEDIA_DOWNLOAD_URL}",
      "timestamp": {
        "url": "{GUARDTIME_TIMESTAMP_URL}",
        "id": "{TIMESTAMP_ID}"
      },
      "size": "{SIZE_IN_KB}",
      "mimetype": "{MEDIA_MIME_TYPE}"
    }
  ],
  "images": [
    {
      "id": "{MEDIA_ID}",
      "name": "{IMAGE_NAME}",
      "url": "{MEDIA_DOWNLOAD_URL}",
      "timestamp": {
        "url": "{GUARDTIME_TIMESTAMP_URL}",
        "id": "{TIMESTAMP_ID}"
      },
      "size": "{SIZE_IN_KB}",
      "mimetype": "{MEDIA_MIME_TYPE}"
    }
  ]
}

/sessions/{sessionId}/media POST

In this post request the vendor sends a file (base64 encoded image string inside a JSON body object), where they could upload images (1 image at a time), specifying also a type of the image that is being uploaded.

Request

Request properties explained:

• image: object (required)
  • context: String (required) Type of a document (face|document-front|document-back)
  • content: String base64 encoded image (png|jpg|jpeg)
    
  • Example data:image/png;base64,R0lGODlhAQABAAAAACw=
    
  • timestamp: string (required) Combined ISO 8601 date and time in UTC (YYYY-MM-DDTHH:MM:S+Timezone Offset|Z, i.e., 2018-04-18T11:02:05.261Z)

Request method: POST
Media type: application/json
Type: object
Headers:
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Payload signed with API Secret. Content-Type: application/json

Sample REQUEST

curl

curl -X POST \
  https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/media \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-API-KEY' \
  -H 'X-SIGNATURE: 034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53' \
  -d '{
    "image": {
    "context": "document-front",
      "content": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA+.../9fgAEAKcxisFjVfn0AAAAASUVORK5CYII=",
      "timestamp": "2019-10-29T06:30:25.597Z"
    }
}'

Node.js

var request = require("request");

var options = { method: 'POST',
  url: 'https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/media',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': '034c6da2bb31fd9e6892516c6d7b90ebe10f79b47cfb3d155d77b4d9b66e1d53',
     'X-AUTH-CLIENT': 'Your-api-key' },
  body: 
   { image: 
      { context: 'document-front',
        content: 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA+.../9fgAEAKcxisFjVfn0AAAAASUVORK5CYII=',
        timestamp: '2019-10-29T06:30:25.597Z' } },
  json: true };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response:

Response properties explained:

• status: String (required) Request status
  
• image: object (required) Image object
  • id: UUID-v4 String (required) UUID v4 which identifies the image
  • name: String (required) File name that identifies the image
  • timestamp: String (required) Timestamp object
  • size: Integer (required) Size for the image
  • mimetype: String (required) Type for the image
  • url: String (required) URL for the image

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample RESPONSE

{ "status": "success",
  "image":{ 
     "id": "39388f8d-c6d6-4e9b-92c6-6978b2e8d664",
     "name": "document-back.jpg",
     "timestamp":{ 
        "url": "https://magic.veriff.me/v1/timestamps/6f7e2967-4953-4e35-9aed-4ba69f65db80",
        "id": "6f7e2967-4953-4e35-9aed-4ba69f65db80" },
     "size": 52268,
     "mimetype": "image/png",
     "url": "https://magic.veriff.me/v1/media/39388f8d-c6d6-4e9b-92c6-6978b2e8d664"
   }
}

/sessions/{sessionId}/person

Request method: GET

Media type: application/json
Type: object.

Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Session ID signed with API Secret. Content-Type: application/json

Sample request

curl

curl -X GET \
  https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/person \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-API-KEY' \
  -H 'X-SIGNATURE: 334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14' \

Node.js

var request = require("request");

var options = { method: 'GET',
  url: 'https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/person',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': '334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14',
     'X-AUTH-CLIENT': 'Your-api-key' } };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample RESPONSE

{
    "status": "success",
    "person": {
        "id": "uuid",
        "firstName": "string",
        "lastName": "string",
        "idCode": "string",
        "dateOfBirth": "string, format (YYYY-MM-DD)",
        "gender": "string, values can be M - male, F - female, null - undefined",
        "nationality": "string, iso2 country code",
        "placeOfBirth": "string, iso2 country code",
        "citizenships": [
            {
                "kind": "string, Main or Secondary",
                "citizenship": "string, country name"
            }
        ],
        "pepSanctionMatches": [
            {
                "numberOfMatches": "number",
                "date": "date with timestamp, 2018-11-28T17:13:28.154Z",
                "matches": [
                    {
                        "name": "string",
                        "nationality": "string",
                        "category": "string, SIP or PEP"
                    },
                ]
            }
        ]
    }
}

/sessions/{sessionId}/timestamps

Request method: GET

Media type: application/json
Type: object.

Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Session ID signed with API Secret. Content-Type: application/json

curl

curl -X GET \
  https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/timestamps \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-api-key' \
  -H 'X-SIGNATURE: 334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14' \

Node.js

var request = require("request");

var options = { method: 'GET',
  url: 'https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/timestamps',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': '334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14',
     'X-AUTH-CLIENT': 'Your-api-key' } };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Properties explained:

• status: String (required) Request status
• timestamps: object (required) Timestamp object
  • id: UUID-v4 (required) Timestamp Id
  • url: String (required) Timestamp url
  • context: String (required) Timestamp context

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample RESPONE

{
  "status": "success",
  "timestamps": [
    {
      "id": "{TIMESTAMP_ID}",
      "url": "{GUARDTIME_TIMESTAMP_URL}",
      "context": "{TIMESTAMP_TYPE}"
    }
  ]
}

/sessions/{sessionId}/attempts

Get the list of attempt objects with sessionId = {sessionId}

Request method: GET

Media type: application/json
Type: object.

Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Session ID signed with API Secret. Content-Type: application/json

curl

curl -X GET \
  https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/attempts \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-api-key' \
  -H 'X-SIGNATURE: 334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14' \

Node.js

var request = require("request");

var options = { method: 'GET',
  url: 'https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/attempts',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': '334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14',
     'X-AUTH-CLIENT': 'Your-api-key' } };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Response properties explained:

• status: String (required) Status of the request
  
• verifications: object (required) Array of JSON objects identifying the attempts
  • id: UUID-v4` (required) attempt Id
  • status: String (required) status of the attempt

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample Response

{ 
  "status": "success",
  "verifications": [ 
      {
      "id": "f5c68aea-7f4d-478d-80ab-ca9356074f69",
      "status": "approved"
      },
      {
      "id": "f2270684-8c51-4d03-88eb-dafd43e8b486",
      "status": "resubmission_requested"
      }
  ]
}

/sessions/{sessionId}/decision

Get the session decision with sessionId = {sessionId}

Request method: GET

Media type: application/json
Type: object.

Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Session ID signed with API Secret. Content-Type: application/json

curl

curl -X GET \
  https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/decision \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-api-key' \
  -H 'X-SIGNATURE: 334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14' \

Node.js

var request = require("request");

var options = { method: 'GET',
  url: 'https://api.veriff.me/v1/sessions/aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7/decision',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': '334141f052e317fde6668de54dc6640b4a5c47582ad86a8bed63afe566f17b14',
     'X-AUTH-CLIENT': 'Your-api-key' } };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Get the session decision with sessionId = {sessionId}

Response Properties explained:

• status: String (required) Status of the response
  
• verification: object Verification request decision object. Null if decision is not available yet
  
  • id: String UUID v4 which identifies the verification session
  • status: approved (one of approved, resubmission_requested, declined, expired, abandoned) Verification status
  • code: 9001 (one of 9001, 9102, 9103, 9104, 9151) Verification response code.
    Explanation of the meaning of the response codes
    
    • 9001 : Positive: Person was verified. The verification process is complete. Accessing the sessionURL again will show the client that nothing is to be done here.
    • 9102 : Negative: Person has not been verified. The verification process is complete. Either it was a fraud case or some other severe reason that the person can not be verified. You should investigate the session further and read the "reason". If you decide to give the client another try you need to create a new session.
    • 9103 : Resubmitted: Resubmission has been requested. The verification process is not completed. Something was missing from the client and she or he needs to go through the flow once more. The same sessionURL can and should be used for this purpose.
    • 9104 : Negative: Verification has been expired. The verification process is complete. After 7 days the session get's expired. If the client started the verification process we reply "abandoned" here, otherwise if the client never arrived in our environment the status will be "expired".
    • 9151 : Intermediate Positive: SelfID was successful - this code is only send if the configuration flag is set.
    • 9161 : Intermediate Positive: Video Call was successful - this code is only send if the configuration flag is set.
  • reason: String Reason of failed Verification
  • person: object Verified person
    • firstName: String First name
    • lastName: String Last name
    • idNumber: Strin Identification number
    • citizenship: ISO-2 String Citizenship
    • dateOfBirth: String (YYYY-MM-DD) Date of birth
    • gender: String (M, F or Null) Gender
  • document: object Verified document
    • number: String Document number
    • type: String(one of PASSPORT, ID_CARD, DRIVERS_LICENCE, RESIDENCE_PERMIT) Document type
    • country:ISO-2` String Document country
    • validFrom: String Document is valid from date
    • validUntil: String Document is valid undit date
  • additionalVerifiedData: object Additional vendor specific data which were verified by the verification specialist
  • comments: object Array of additional comments by verification specialist
    • type: String The type of the comment
    • comment: String The comment itself
    • timestamp: String UTC timestamp
• technicalData: object Technical data object
  • ip: String Ip of the device from which the verification was made

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

/attempts/{attemptId}/media

Get the list of media objects with attemptId = {attemptId}

Request method: GET

Media type: application/json
Type: object.

Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Attempt ID signed with API Secret. Content-Type: application/json

curl

curl -X GET \
  https://api.veriff.me/v1/attempts/f5c68aea-7f4d-478d-80ab-ca9356074f69/media \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-api-key' \
  -H 'X-SIGNATURE: acfe1cf21c986edf25cc6bc74fd769954443bbb606500019a4bed46645179b36' \

Node.js

var request = require("request");

var options = { method: 'GET',
  url: 'https://api.veriff.me/v1/attempts/f5c68aea-7f4d-478d-80ab-ca9356074f69/media',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': 'acfe1cf21c986edf25cc6bc74fd769954443bbb606500019a4bed46645179b36',
     'X-AUTH-CLIENT': 'Your-api-key' } };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Get the media with attemptId = {attemptId}

Response Properties explained:

• status: String (required) Status of the request
  
• videos: object (required) Array of JSON objects identifying the videos
  • id: UUID-v4 (required) Video Id
  • name: String (required) Video name
  • duration: String (required) Video duration in seconds
  • url: String (required) Video download url
  • size: String (required) Video size in KB
  • timestamp: object (required) Timestamp object
    • id: UUID-v4 (required) Timestamp Id
    • url: String (required) Timestamp url
• images: object (required) Array of JSON objects identifying the images
  • id: UUID-v4 (required) Image Id
  • name: String (required) Image name
  • url: String (required) Image download url
  • size: String (required) Image size in KB
    • timestamp: object (required) Timestamp object
    • id: UUID-v4 (required) Timestamp Id
    • url: String (required) Timestamp url

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample RESPONSE

{
  "status": "success",
  "videos": [
    {
      "id": "{MEDIA_ID}",
      "name": "{VIDEO_NAME}",
      "duration": "{DURATION_IN_SECONDS}",
      "url": "{MEDIA_DOWNLOAD_URL}",
      "timestamp": {
        "url": "{GUARDTIME_TIMESTAMP_URL}",
        "id": "{TIMESTAMP_ID}"
      },
      "size": "{SIZE_IN_KB}",
      "mimetype": "{MEDIA_MIME_TYPE}"
    }
  ],
  "images": [
    {
      "id": "{MEDIA_ID}",
      "name": "{IMAGE_NAME}",
      "url": "{MEDIA_DOWNLOAD_URL}",
      "timestamp": {
        "url": "{GUARDTIME_TIMESTAMP_URL}",
        "id": "{TIMESTAMP_ID}"
      },
      "size": "{SIZE_IN_KB}",
      "mimetype": "{MEDIA_MIME_TYPE}"
    }
  ]
}

/media/{mediaId}

Get the media with mediaId = {mediaId}

Request method: GET

Media type: application/json
Type: object.

Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Media ID signed with API Secret. Content-Type: application/json

curl

curl -X GET \
  https://api.veriff.me/v1/media/ebbf6434-3bf1-4020-8ac3-1ef51a25c673 \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-api-key' \
  -H 'X-SIGNATURE: 452bfca0e02f8ee0f56d97373cc6971067e43149f1b7e58b681d4e57353a2f6b' \

Node.js

var request = require("request");

var options = { method: 'GET',
  url: 'https://api.veriff.me/v1/media/ebbf6434-3bf1-4020-8ac3-1ef51a25c673',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': '452bfca0e02f8ee0f56d97373cc6971067e43149f1b7e58b681d4e57353a2f6b',
     'X-AUTH-CLIENT': 'Your-api-key' } };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Media data signed by API Secret.
TRANSFER-ENCODING: string (required) - Form of encoding used to safely transfer the payload body.

Sample RESPONSE Transfer-Encoding: chunked

/timestamps/{timestampId}

Get the timestamp with timestampId = {timestampId}

Request method: GET

Media type: application/json
Type: object.

Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Timestamp ID signed with API Secret. Content-Type: application/json

curl

curl -X GET \
  https://api.veriff.me/v1/timestamps/fe7fab32-cb78-4b8d-bd65-33e7da6ac2c9 \
  -H 'Content-Type: application/json' \
  -H 'X-AUTH-CLIENT: Your-api-key' \
  -H 'X-SIGNATURE: ea9623fc8dc546b134d504fa4d7d33328b6b4bdea9e7fa6fcd81ac36c8a59954' \

Node.js

var request = require("request");

var options = { method: 'GET',
  url: 'https://api.veriff.me/v1/timestamps/fe7fab32-cb78-4b8d-bd65-33e7da6ac2c9',
  headers: 
   { 'Content-Type': 'application/json',
     'X-SIGNATURE': 'ea9623fc8dc546b134d504fa4d7d33328b6b4bdea9e7fa6fcd81ac36c8a59954',
     'X-AUTH-CLIENT': 'Your-api-key' } };

request(options, function (error, response, body) {
  if (error) throw new Error(error);

  console.log(body);
});

Response

Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required) - API Key
X-SIGNATURE: string (required) - Response body signed with API Secret. Content-Type: application/json

Sample RESPONSE

{
  "status": "success",
  "timestamp": {
    "id": "{TIMESTAMP_ID}",
    "context": "{TIMESTAMP_CONTEXT}",
    "signature": "{SIGNATURE}",
    "dataHash": {
      "algorithm": "SHA-256",
      "value": "{HASH_VALUE}"
    }
  }
}

X-Signature

Signing requests

It is important to check that the webhook responses do indeed originate from Veriff.

You can secure the webhook listener URL in three ways:

have a good secure SSL server for your webhook listener (Veriff will call only to HTTPS URLs, to servers with a publicly verifiable certificate) check the X-AUTH-CLIENT and X-SIGNATURE headers on the decision webhook (the signature is calculated using the API secret that only you and Veriff know) finally, if you are really suspicious, you may restrict your webhook listener to only accept calls from the Veriff IP range (please ask your Veriff integration onboarding specialist for those details).
When Veriff calls your webhook endpoint, we use the same logic of X-SIGNATURE generation on our calls to you, as on your calls to us. So, when we call your endpoint for any notification URL, we set the X-AUTH-CLIENT http header to your API key, and we set the X-SIGNATURE header to the hex encoded sha256 digest of the request body and the secret.

When you accept a webhook call from us, you need to proceed as follows:

Compare the X-AUTH-CLIENT header to your api key, if different -> fail with error access the http request body (before it is parsed) calculate the sha256 digest of the request body string + api secret compare the hex encoded digest with the X-SIGNATURE header, if different -> fail with error only now you should parse the request body JSON object The calculation for X-SIGNATURE is following the same algorithm as for session generation.

Generating X-Signature:

Here are few examples how to do it.

NodeJS

const crypto = require('crypto');

// Globals
const API_KEY = 'Your-api-key';
const API_SECRET = 'Your-api-secret';

const data = 'my precious data';

// Headers 
const headers = 
   { 'Content-Type': 'application/json',
     'X-AUTH-CLIENT': API_KEY,
     'X-SIGNATURE': generateSignature(data, API_SECRET) };


function generateSignature(payload, secret, error) {
  if (payload.constructor === Object) {
    payload = JSON.stringify(payload);
  }

  if (payload.constructor !== Buffer) {
    payload = Buffer.from(payload, 'utf8');
  }

  const signature = crypto.createHash('sha256');
  signature.update(payload);
  signature.update(new Buffer.from(secret, 'utf8'));
  return signature.digest('hex');

};

console.log(headers);

Manual Generation:

Create session with following payload via API. Sometimes you might want to use Postman or any other tool for API testing. For this you will need to manually calculate sha-256 hash from payload and send it with X-signature header

{
    "verification": {
        "callback": "https://veriff.me",
        "person": {
            "firstName": "Tundmatu",
            "lastName": "Toomas",
            "idNumber": "1234567890"
        },
        "document": {
            "number": "B01234567",
            "type": "PASSPORT",
            "country": "EE"
        },
        "additionalData": {
            "citizenship": "EE",
            "placeOfResidence": "Tallinn"
        },
        "vendorData": "11111111",
        "lang": "en",
        "features": [
            "selfid"
        ],
        "timestamp": "2016-05-19T08:30:25.597Z"
    }
}

First take the payload and add your API-Secret to the end. (replace 'Your-API-Secret' with your API secret) Note: current example can be encoded using "Your-API-Secret" for manual calculation

{
    "verification": {
        "callback": "https://veriff.me",
        "person": {
            "firstName": "Tundmatu",
            "lastName": "Toomas",
            "idNumber": "1234567890"
        },
        "document": {
            "number": "B01234567",
            "type": "PASSPORT",
            "country": "EE"
        },
        "additionalData": {
            "citizenship": "EE",
            "placeOfResidence": "Tallinn"
        },
        "vendorData": "11111111",
        "lang": "en",
        "features": [
            "selfid"
        ],
        "timestamp": "2016-05-19T08:30:25.597Z"
    }
}Your-API-Secret

Use your favorite SHA-256 hash calculator to calculate hash.
E.g https://xorbin.com/tools/sha256-hash-calculator

SHA-256 hash is: dc813ed3551b64e2539a4e8c8b06945dcf82d2656a9700101ce4864fb81410fa

X-Signature included to your request headers is above hash:

Headers

Content-Type: application/json  
X-AUTH-CLIENT: Your-API-Key 
X-SIGNATURE: dc813ed3551b64e2539a4e8c8b06945dcf82d2656a9700101ce4864fb81410fa

Validating X-Signature:

We sign all responses using same logic. Response body + Your-API-Secret = X-SIGNATURE in response headers.
To be sure that response is sent by Veriff you can validate X-SIGNRATURE.

Here are few examples how to do validate response signature. Below is function you can use.

NodeJS

function isSignatureValid(data) {
  const { signature, secret } = data;
  let { payload } = data;

  if (data.payload.constructor === Object) {
    payload = JSON.stringify(data.payload);
  }
  if (payload.constructor !== Buffer) {
    payload = new Buffer.from(payload, 'utf8');
  }
  const hash = crypto.createHash('sha256');
  hash.update(payload);
  hash.update(new Buffer.from(secret));
  const digest = hash.digest('hex');

  return digest === signature.toLowerCase();
}

Validate from response:

Easiest way to test validation function is to setup webhook listnener on localhost and do use cURL for quick validation test. This way you can test your function independently from our Webhook or API responses.

Step 1 - Setup webhook listsener and validate payload.

NodeJS

const crypto = require('crypto');
const request = require("request");
const express = require('express');
const bodyParser = require('body-parser');
const app = express();

const WEBHOOK_PORT = 3001;
const API_SECRET = 'Your-API-Secret';

function isSignatureValid(data) {
  const { signature, secret } = data;
  let { payload } = data;

  if (data.payload.constructor === Object) {
    payload = JSON.stringify(data.payload);
  }
  if (payload.constructor !== Buffer) {
    payload = new Buffer.from(payload, 'utf8');
  }
  const hash = crypto.createHash('sha256');
  hash.update(payload);
  hash.update(new Buffer.from(secret));
  const digest = hash.digest('hex');

  return digest === signature.toLowerCase();
}

app.use(bodyParser.json());
let server = require('http').Server(app);

app.post('/verification/', (req, res) => {
  const signature = req.get('x-signature');
  const secret = API_SECRET;
  const payload = req.body;

  console.log('Received a webhook');
  console.log('Is signature valid:', isSignatureValid({ signature, secret, payload }));
  console.log('Payload', JSON.stringify(payload, null, 4));
  res.json({ status: 'success' });
  process.exit();
})

server.listen(WEBHOOK_PORT);
console.log('Server is UP \n Listsening port:', WEBHOOK_PORT);

Step 2 - Post some data to webhook listener for validation:

Below will return: Is signature valid: true if you use 'Your-API-Secret' for validating signature.

CURL

curl --request POST 'http://localhost:3001/verification/' -k \
--header 'accept:application/json' \
--header 'x-auth-client:Your-API-Key' \
--header 'x-signature:cd0e28104516bc27b4506026d81d07e532b927440b84c4f01ac02d92a2b1419c' \
--header 'content-type:application/json' \
--data '{"status":"success","verification":{"id":"aea9ba6d-1b47-47fc-a4fc-f72b6d3584a7","code":9001,"person":{"gender":null,"idNumber":"123456789","lastName":"Toomas","firstName":"Tundmatu","citizenship":null,"dateOfBirth":null,"nationality":null,"yearOfBirth":null,"pepSanctionMatch":null},"reason":null,"status":"approved","comments":[],"document":{"type":"ID_CARD","number":"ee12334","country":"EE","validFrom":null,"validUntil":null},"highRisk":null,"reasonCode":null,"vendorData":"11111111","decisionTime":"2019-10-30T07:32:44.540Z","acceptanceTime":"2019-10-29T12:41:01.000Z","additionalVerifiedData":{}},"technicalData":{"ip":"95.153.29.169"}}'

Manual Validation

All our responses are stringified
Note: current example can be encoded using "Your-API-Secret" for manual calculation

Example response for above:

Headers

Content-Type: application/json  
X-AUTH-CLIENT: Your-API-Key  
X-SIGNATURE: 253e28b027ca93d323d524d437b13ccc06730bd08709aac0194725b63e50b556

Use your favorite SHA-256 hash calculator to calculate hash.
E.g https://xorbin.com/tools/sha256-hash-calculator

{"status":"success","verification":{"id":"d04fd8e7-80cd-4fb8-b235-cec89c5c6790","url":"https://magic.veriff.me/v/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX2lkIjoiZDA0ZmQ4ZTctODBjZC00ZmI4LWIyMzUtY2VjODljNWM2NzkwIiwiaWF0IjoxNTcyMjUyODgyfQ.wBEsEAeAzBQamc6acujZoJ4VQxuCsYfwdH8Xe-JI4Qw","vendorData":"11111111","host":"https://front.veriff.me","status":"created","sessionToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX2lkIjoiZDA0ZmQ4ZTctODBjZC00ZmI4LWIyMzUtY2VjODljNWM2NzkwIiwiaWF0IjoxNTcyMjUyODgyfQ.wBEsEAeAzBQamc6acujZoJ4VQxuCsYfwdH8Xe-JI4Qw"}}Your-API-Secret

Compare X-Signature in response headers with the result from calculations:

X-SIGNATURE: 253e28b027ca93d323d524d437b13ccc06730bd08709aac0194725b63e50b556
SHA-256 hash: 253e28b027ca93d323d524d437b13ccc06730bd08709aac0194725b63e50b556

Attempts

/attempts /{attemptId}/media (GET)

Get the list of media objects with attemptId = {attemptId}

Request

URI Parameters attemptId: string (required)

Response

Properties

{
  "status": "success",
  "videos": [
    {
      "id": "{MEDIA_ID}",
      "name": "{VIDEO_NAME}",
      "duration": "{DURATION_IN_SECONDS}",
      "url": "{MEDIA_DOWNLOAD_URL}",
      "timestamp": {
        "url": "{GUARDTIME_TIMESTAMP_URL}",
        "id": "{TIMESTAMP_ID}"
      },
      "size": "{SIZE_IN_KB}",
      "mimetype": "{MEDIA_MIME_TYPE}"
    }
  ],
  "images": [
    {
      "id": "{MEDIA_ID}",
      "name": "{IMAGE_NAME}",
      "url": "{MEDIA_DOWNLOAD_URL}",
      "timestamp": {
        "url": "{GUARDTIME_TIMESTAMP_URL}",
        "id": "{TIMESTAMP_ID}"
      },
      "size": "{SIZE_IN_KB}",
      "mimetype": "{MEDIA_MIME_TYPE}"
    }
  ]
}

• status: String (required)
  Status of the request
• videos: object (required)
  Array of JSON objects identifying the videos
  • id: UUID-v4 (required)
    Video Id
  • name: String (required)
    Video name
  • duration: String (required)
    Video duration in seconds
  • url: String (required)
    Video download url
  • size: String (required)
    Video size in KB
  • timestamp: object (required)
    Timestamp object
  • id: UUID-v4 (required)
    Timestamp Id
  • url: String (required)
    Timestamp url
• images: object (required)
  Array of JSON objects identifying the images
  • id: UUID-v4 (required)
    Image Id
  • name: String (required)
    Image name
  • url: String (required)
    Image download url
  • size: String (required)
    Image size in KB
  • timestamp: object (required)
    Timestamp object
  • id: UUID-v4 (required)
    Timestamp Id
  • url: String (required)
    Timestamp url

Media

/media /{mediaId} (GET)

Get the media with mediaId = {mediaId}

Request

Headers

X-AUTH-CLIENT: string (required) Vendor’s API Key X-SIGNATURE: string (required) Media ID signed by Vendor’s API Secret URI Parameters mediaId: string (required)

Response

Headers

X-AUTH-CLIENT: string (required) Vendor’s API Key X-SIGNATURE: string (required) Media data signed by Vendor’s API Secret TRANSFER-ENCODING: string (required) Media data signed by Vendor’s API Secret

Transfer-Encoding: chunked

Timestamps

/timestamps /{timestampId}

Get the timestamp with timestampId = {timestampId}

Request

URI Parameters timestampId: string (required)

Response

{
  "status": "success",
  "timestamp": {
    "id": "{TIMESTAMP_ID}",
    "context": "{TIMESTAMP_CONTEXT}",
    "signature": "{SIGNATURE}",
    "dataHash": {
      "algorithm": "SHA-256",
      "value": "{HASH_VALUE}"
    }
  }
}

Response and error codes

	Common response codes
Code	Description
200	`{ "status": "success", "data" }`
201	`{ "status": "success", "data" }`
400	`{ "status": "fail", "code:": "1102", "message": "Mandatory parameters are missing from the request." }`
401	`{ "status": "fail", "message": "Not Authorized." }`
404	`{ "status": "fail", "message": "Not Found." }`
	Some Troubleshooting codes
Code	Description
1001	Query ID must be between 20 and 40 symbols.
1002	Query ID must be a valid UUID V4
1003	Query ID must be unique, it has already been used.
1101	Invalid Vendor API Key.
1102	Mandatory parameters are missing from the request.
1104	Request includes invalid parameters.
1201	Invalid timestamp. Timestamp must not be older than one hour.
1202	Timestamp format is incorrect. YYYY-MM-DDTHH:MM:S+Timezone Offset|Z or UTC.
1301	Requested features are not supported.
1302	Only HTTPS return URLs are allowed.
1500	Vendor data cannot be more than 40 symbols.
1501	Vendor data must be a string.
2003	Date of birth is not a valid date.
2102	Document number may contain only characters and numbers A-Z, 0-9.
2103	Document type is not supported.
2104	Document from provided country is not supported.
	Reason and Decision codes
Status	/descision Webhook and Endpoint verification.code object
Code	Description
9001	Positive: Person was verified. The verification process is complete. Accessing the sessionURL again will show the client that nothing is to be done here.
9102	Negative: Person has not been verified. The verification process is complete. Either it was a fraud case or some other severe reason that the person can not be verified. You should investigate the session further and read the "reason". If you decide to give the client another try you need to create a new session.
9103	Resubmitted: Resubmission has been requested. The verification process is not completed. Something was missing from the client and she or he needs to go through the flow once more. The same sessionURL can and should be used for this purpose.
9104	Negative: Verification has been expired. The verification process is complete. After 7 days the session get's expired. If the client started the verification process we reply "abandoned" here, otherwise if the client never arrived in our environment the status will be "expired"
9151	Intermediate Positive: SelfID was successful - this code is only send if the configuration flag is set.
Decline	/descision webhook and endpoint verification.reasonCode
Code	Description
101	Physical document not used.
102	Suspected document tampering.
103	Person showing the document does not appear to match document photo.
104	Name entered does not match name on document.
105	Suspicious behaviour.
106	Known fraud.
107	Velocity/abuse.
Resubmit	/descision webhook and endpoint verification.reasonCode
Code	Description
201	Video and/or photos missing.
202	Face not clearly visible.
203	Full document not visible.
204	Poor image quality.
205	Document damaged.
206	Document type not supported.
207	Document expired.

Webhooks

To automate the handling of responses from verifications, you will need to implement a webhook listener, according to the documentation at Webhook Decision (POST) Once you have determined the URL of the listener, it is possible to configure it in the Veriff back office (Integrations / Notifications / Decision webhook url ) In case you want to test web hooks before the mobile app fully working, it is possible to hand generate verification sessions in the back office (Verifications / Generated tokens / Generate session and then following the URL for a web-based verification session, which will post the result to your webhook)

Configuring the webhook endpoint

Go to Veriff's back office, Management -> Vendors -> Edit, and set 'Decision notification url' to the URL where your server will be listening for decision notifications from Veriff. Veriff will post decision notifications of verification results to this URL. Only HTTPS URLs are allowed.

If there is a network connectivity issue or technical issue with delivering the notification (any non-200 response code), Veriff will retry the notification multiple times for up to a week.

The full description of the webhook format is at Webhook Decision (POST)

Recognizing your customer

When your server receives a decision notification from Veriff, you have to figure out, which customer is it about.

There are two ways to do this:

• using the Veriff session ID, or
• using your own customer ID.

The easiest way is to track the session ID provided by Veriff during session creation. All future event and decision notifications refer to the session ID. The session ID is unique for each session, and it can be used to look up sessions in the administrative interface at Veriff Back Office

The other way is to provide Veriff with your internal customer ID, or some other key that uniquely identifies your customer. You can store your identifier in the vendorData element as a string, and we will send it back to you in webhook notifications. Please bear in mind that it is technically possible for one customer to be associated with multiple verification sessions, and this could potentially create ambiguous situations in code, if you are only recognizing customers by your own identifier, and not Veriff's session ID.

Handling security

It is important to check that the webhook responses do indeed originate from Veriff.

You can secure the webhook listener URL in three ways:

• have a good secure SSL server for your webhook listener (Veriff will call only to HTTPS URLs, to servers with a publicly verifiable certificate)
• check the X-AUTH-CLIENT and X-SIGNATURE headers on the decision webhook (the signature is calculated using the API secret that only you and Veriff know)
• finally, if you are really suspicious, you may restrict your webhook listener to only accept calls from the Veriff IP range (please ask your Veriff integration onboarding specialist for those details)

When Veriff calls your webhook endpoint, we use the same logic of X-SIGNATURE generation on our calls to you, as on your calls to us. So, when we call your endpoint for any notification URL, we set the X-AUTH-CLIENT http header to your API key, and we set the X-SIGNATURE header to the hex encoded sha256 digest of the request body and the secret.

When you accept a webhook call from us, you need to proceed as follows:

1. compare the X-AUTH-CLIENT header to your api key, if different -> fail with error
2. access the http request body (before it is parsed)
3. calculate the sha256 digest of the request body string + api secret
4. compare the hex encoded digest with the X-SIGNATURE header, if different -> fail with error
5. only now you should parse the request body JSON object

The calculation for X-SIGNATURE is following the same algorithm as for session generation.

Different webhook calls

The difference between the URLs is as follows:

• the Decision Webhook Url is where we post decisions about verifications (approved, declined, resubmission_required, expired, abandoned, etc)
• the Event Webhook Url is where we post events during the lifecycle of a verification (started, submitted, etc)
• finally, there is a Callback URL, which is actually the redirect URL for the user on the web site at the end of KYC

Meaning of the various verification responses

Verification status is one of

• approved
• resubmission_requested
• declined
• expired
• abandoned

Verification response code is one of 9001, 9102, 9103, 9104, 9151, 9161 All codes and explanations can be found from Response and error codes

Explanation of the meaning of the response codes: Webhook response codes

• 9001 : Positive: Person was verified. The verification process is complete. Accessing the sessionURL again will show the client that nothing is to be done here.
• 9102 : Negative: Person has not been verified. The verification process is complete. Either it was a fraud case or some other severe reason that the person can not be verified. You should investigate the session further and read the "reason". If you decide to give the client another try you need to create a new session.
• 9103 : Resubmitted: Resubmission has been requested. The verification process is not completed. Something was missing from the client and she or he needs to go through the flow once more. The same sessionURL can and should be used for this purpose.
• 9104 : Negative: Verification has been expired. The verification process is complete. After 7 days the session get's expired. If the client started the verification process we reply "abandoned" here, otherwise if the client never arrived in our environment the status will be "expired"
• 9151 : Intermediate Positive: SelfID was successful - this code is only send if the configuration flag is set

Lifecycle of the verification session

Responses 9001, 9102, and 9104 are conclusive responses. The session is closed and the URL is not available for the end user.

Response 9103 is an inconclusive response. The session remains open until you receive one of the above conclusive responses. The session is re-opened for the end user, accepting a new attempt.

Responses 9151 and 9161 are intermediate responses. The session is being processed, it is not open for the end user, and you will soon receive one of the above conclusive or inconclusive responses.

Preconditions for approval decisions

We give a positive conclusive decision (status approved, code 9001) when the user has provided us with:

• photos and video uploaded to us
• the data on the document is readable and matches throughout the document
• the user's portrait photo is recognizable
• the user on the portrait photo corresponds to the person on the document photo
• the document is valid (dates, etc) A positive decision means that the person was verified. The verification process is complete. Accessing the KYC session URL again will tell * the user that nothing more is to be done.

Reasons for negative conclusive decisions

• Physical document not used
• Suspected document tampering
• Person showing the document does not appear to match document photo
• Suspicious behaviour
• Velocity/abuse
• Known fraud

A negative decision means that the person has not been verified. The verification process is complete. Either it was a fraud case or some other severe reason that the person can not be verified. You should investigate the session further and read the "reason". If you decide to give the client another try you need to create a new session

Reasons for inconclusive decisions

• Video and/or photos missing
• Face not clearly visible
• Full document not visible
• Poor image quality
• Document damaged
• Document type not supported
• Document expired

*In case of verifications which have received a "Resubmission requested" decision from Veriff, we highly recommend notifying the user about the reason why the verification did verification fail and tips for what could be done better on the next attempt. This can be done either via e-mail, SMS and/or in your platform for better visibility. In case of resubmitted verificatoin attempts where something was missing or the quality of the submission was poor, a next attempt is created ready to be used and accessible via the same session URL. The same session URL should be used for verification attempts by the same user.

Final decisions

You have the right to make the final decision about verifying an end-user even after they have completed the verification process with Veriff. In order for you to make the final decision, we recommend you create an appropriate functionality in your back-end. This will enable you to either approve or reject applications after the person has completed Veriff’s verification session. When you perform additional checks outside of Veriff’s service, it is necessary to have another layer of decision making. The decision has to be motivated based on further checks or extra information independent of Veriff’s decision. The additional verification details can be determined in accordance with your business needs and the amount of data and background information available to you about the end-user. Potential use cases: * Age checks * Name validation checks * A user is unable to pass verification as required, but their attempt is sincere and the document is legitimate * A user has made multiple fraudulent attemtps to verify and cannot pass Veriff's verification any more * You wish to restrict the user's access to your platform based on their earlier behavior Veriff provides a more standardized solution where unconventional user behavior is not deferred to for the benefit of overall decision quality.

Meaning of the various event codes

{
  "id": "f04bdb47-d3be-4b28-b028-a652feb060b5",
  "feature": "selfid",
  "code": 7002,
  "action": "submitted"
}

The event webhook informs you about the progress of the verification. However, it does not inform you of the decision.

The event code can be one of:

• '7001 : Started
• '7002 : Submitted

Storing verification media

For businesses which are regulated by various KYC and AML laws and rules, storing proof of the customer's verification is often a requirement. While Veriff stores and holds the customer's media - photos and videos - it might also be mandatory and more convenient for the business to store this media internally.

First, you need to get the sessionId of a session you want to download the media for. This can be found from the decision webhook(parameter "id") which is automatically sent after a decision has been made for a verification session. With the sessionID, make a GET request to /sessions/{sessionId}/media endpoint. From there, you will find a mediaId for every media file we have stored.

With the mediaIds, you can make a GET request to /media/{mediaId} endpoint to get the media file in .jpeg or .mp4 format. A separate request will have to be made for each media file.

Automating the download of photo and video files associated with comlpeted verifications.

/sessions/{sessionId}/media First, query for a list of files using a GET request to /media/{mediaId} The response to your GET request to /sessions{sessionID}/media will be a list of videos and images related to this sessionID.

Second, the individual media files can be downloaded by using the mediaID returned in the first step with a GET request to /media/{mediaID}

/webhooks /decision (POST)

This endpoint specifies how the asynchronous response to the notification url looks like. It sends the result of the verification back to the vendor once the verification has been reviewed. The notification url needs to be specified in Veriff's backoffice.

Response

Description For testing this endpoint without depending on Veriff sending responses you can use this Curl command. Beware, that the signature will not match your Vendors Key and Secret. To validate this example signature and payload use Secret '3c184872-6929-43d9-91d5-9e68468b5aa1'.

curl --request POST 'https://your.url' -k \
--header 'accept:application/json' \
--header 'x-auth-client:8e4f7cd8-7a19-4d7d-971f-a076407ee03c' \
--header 'x-signature:328b360ef2bd2d6b8aa19b41ec5840f3cae94754ac0cfc11484d4ca84a82d9fd' \
--header 'content-type:application/json' \
--data '{"status":"success","verification":{"id":"a4c0a230-859a-4861-b99b-ac39e4a05bfd","status":"resubmission_requested","code":9103,"reason":"Photos are not from the same document.","acceptanceTime":"2017-09-26T12:27:55.000Z","decisionTime":"2017-09-26T12:34:21.000Z","person":{"firstName":"Morton","lastName":"Stracke","idNumber":"48002020011"},"document":{"number":"AA0052283","type":"ID_CARD","validFrom": "2017-02-27", "validUntil": "2022-02-27"},"comments":[{"type": "General Comment", "comment": "Person refuses to take off hat.", "timestamp": "2017-10-10T13:18:44.009Z"}],"technicalData":{"ip":"124.153.46.66"}}'

Properties

{
  "status": "success",
  "verification": {
    "id": "12df6045-3846-3e45-946a-14fa6136d78b",
    "code": 9001,
    "person": {
      "gender": null,
      "idNumber": null,
      "lastName": "MORGAN",
      "firstName": "SARAH",
      "citizenship": null,
      "dateOfBirth": "1967-03-30",
      "nationality": null,
      "yearOfBirth": null,
      "pepSanctionMatch": null
    },
    "reason": null,
    "status": "approved",
    "comments": [

    ],
    "document": {
      "type": "DRIVERS_LICENSE",
      "number": "MORGA753116SM9IJ",
      "country": "GB",
      "validFrom": null,
      "validUntil": "2022-04-20"
    },
    "reasonCode": null,
    "vendorData": "12345678",
    "decisionTime": "2019-11-06T07:18:36.916Z",
    "acceptanceTime": "2019-11-06T07:15:27.000Z",
    "additionalVerifiedData": {
    }
  },
  "technicalData": {
    "ip": "186.153.67.122"
  }
}

{
  "status": "success",
  "verification": {
    "id": "f04bdb47-d3be-4b28-b028-a652feb060b5",
    "code": 9103,
    "person": {
      "gender": null,
      "idNumber": null,
      "lastName": "TestName",
      "firstName": "TestName",
      "citizenship": null,
      "dateOfBirth": "1986-04-0",
      "nationality": null,
      "yearOfBirth": null,
      "pepSanctionMatch": null
    },
    "reason": "Video and/or photos missing",
    "status": "resubmission_requested",
    "comments": [

    ],
    "document": {
      "type": "PASSPORT",
      "number": null,
      "country": "DE",
      "validFrom": null,
      "validUntil": "2024-01-14"
    },
    "reasonCode": 201,
    "vendorData": null,
    "decisionTime": "2019-06-29T11:05:00.780Z",
    "acceptanceTime": "2019-08-29T11:00:51.000Z",
    "additionalVerifiedData": {
    }
  },
  "technicalData": {
    "ip": "186.153.68.122"
  }
}

• status: String (required)
  Status of the response
• verification: object (required)
  Verification request decision object
  • id: String (required)
    UUID v4 which identifies the verification session
  • status: (one of approved, resubmission_requested, declined, expired, abandoned) (required)
    Verification status
  • code: (one of 9001, 9102, 9103, 9104, 9151, 9161) (required)
    erification response code

9001	Positive: Person was verified. The verification process is complete. Accessing the sessionURL again will show the client that nothing is to be done here.
9102	Negative: Person has not been verified. The verification process is complete. Either it was a fraud case or some other severe reason that the person can not be verified. You should investigate the session further and read the "reason". If you decide to give the client another try you need to create a new session.
9103	Resubmitted: Resubmission has been requested. The verification process is not completed. Something was missing from the client and she or he needs to go through the flow once more. The same sessionURL can and should be used for this purpose.
9104	Negative: Verification has been expired. The verification process is complete. After 7 days the session get's expired. If the client started the verification process we reply "abandoned" here, otherwise if the client never arrived in our environment the status will be "expired"' '**9151** : Intermediate Positive: SelfID was successful - this code is only send if the configuration flag is set.
9151	Intermediate Positive: SelfID was successful - this code is only send if the configuration flag is set.

• acceptanceTime: ISO 8601 String (required)
  Timestamp of session creation
• decisionTime: ISO 8601 String (required)
  Timestamp of session decision
• reason: String (required)
  Reason of failed Verification
• reasonCode: String (required)
  Verification fail reason code

101	Physical document not used
102	Suspected document tampering
103	Person showing the document does not appear to match document photo
105	Suspicious behaviour
106	Known fraud
107	Velocity/abuse
201	Video and/or photos missing
202	Face not clearly visible
203	Full document not visible
204	Poor image quality
205	Document damaged
206	Document type not supported
207	Document expired.

• person: object (required)
  Verified person
  • firstName: String (required)
    First name
  • lastName: String (required)
    Last name
  • idNumber: String (required)
    Identification number
  • citizenship: ISO-2 String (required)
    Citizenship
  • dateOfBirth: String (YYYY-MM-DD) (required)
    Date of birth
  • yearOfBirth: String (YYYY) (required)
    Year of birth. Used in cases where only the year of birth is known from the document
  • gender: String (M or F) or Null (required)
    Gender
• document: object (required)
  Verified document
  • number: String (required)
    Document number
  • type: (one of PASSPORT, ID_CARD, DRIVERS_LICENCE, RESIDENCE_PERMIT) (required)
    Document type
  • country: ISO-2 String (required)
    Document country
  • validFrom: String (required)
    Document is valid from date
  • validUntil: String (required)
    Document is valid undit date
• comments: object
  Additional comment by verification specialist
  • type: String (required)
    The type of the comment
  • comment: String (required)
    The comment itself
  • timestamp: String (required)
    UTC timestamp
• technicalData: object (required)
  Technical data object
  • ip: String (required)
    Ip of the device from which the verification was made

/webhooks /events (POST)

Description To keep up to date with the clients progress during the verification process Veriff allows to subscribe to certain events, at the moment three events are triggered, first when client arrives to veriff environment and starts the verification process, second when client is done with the process and submits the attempt,

Properties

{
  "id": "f04bdb47-d3be-4b28-b028-a652feb060b5",
  "feature": "selfid",
  "code": 7002,
  "action": "submitted"
}

id: String (required)
UUID v4 which identifies the verification session attemptId: String (required)
UUID v4 which identifies session attempt feature: String (required)
Feature on which the event was triggered (selfid) code: (one of 7001, 7002) (required)
Event code

7001	Started.
7002	Submitted.

action: Corresponding action description (required)

Response and error codes

	Common response codes
Code	Description
200	`{ "status": "success", "data" }`
201	`{ "status": "success", "data" }`
400	`{ "status": "fail", "code:": "1102", "message": "Mandatory parameters are missing from the request." }`
401	`{ "status": "fail", "message": "Not Authorized." }`
404	`{ "status": "fail", "message": "Not Found." }`
	Some Troubleshooting codes
Code	Description
1001	Query ID must be between 20 and 40 symbols.
1002	Query ID must be a valid UUID V4
1003	Query ID must be unique, it has already been used.
1101	Invalid Vendor API Key.
1102	Mandatory parameters are missing from the request.
1104	Request includes invalid parameters.
1201	Invalid timestamp. Timestamp must not be older than one hour.
1202	Timestamp format is incorrect. YYYY-MM-DDTHH:MM:S+Timezone Offset|Z or UTC.
1301	Requested features are not supported.
1302	Only HTTPS return URLs are allowed.
1500	Vendor data cannot be more than 40 symbols.
1501	Vendor data must be a string.
2003	Date of birth is not a valid date.
2102	Document number may contain only characters and numbers A-Z, 0-9.
2103	Document type is not supported.
2104	Document from provided country is not supported.
	Reason and Decision codes
Status	/descision Webhook and Endpoint verification.code object
Code	Description
9001	Positive: Person was verified. The verification process is complete. Accessing the sessionURL again will show the client that nothing is to be done here.
9102	Negative: Person has not been verified. The verification process is complete. Either it was a fraud case or some other severe reason that the person can not be verified. You should investigate the session further and read the "reason". If you decide to give the client another try you need to create a new session.
9103	Resubmitted: Resubmission has been requested. The verification process is not completed. Something was missing from the client and she or he needs to go through the flow once more. The same sessionURL can and should be used for this purpose.
9104	Negative: Verification has been expired. The verification process is complete. After 7 days the session get's expired. If the client started the verification process we reply "abandoned" here, otherwise if the client never arrived in our environment the status will be "expired"
9151	Intermediate Positive: SelfID was successful - this code is only send if the configuration flag is set.
Decline	/descision webhook and endpoint verification.reasonCode
Code	Description
101	Physical document not used.
102	Suspected document tampering.
103	Person showing the document does not appear to match document photo.
104	Name entered does not match name on document.
105	Suspicious behaviour.
106	Known fraud.
107	Velocity/abuse.
Resubmit	/descision webhook and endpoint verification.reasonCode
Code	Description
201	Video and/or photos missing.
202	Face not clearly visible.
203	Full document not visible.
204	Poor image quality.
205	Document damaged.
206	Document type not supported.
207	Document expired.