API Manual
In this documentation, we describe the process of embedding the page of the automatic capture of the document and the face to your site. In addition, we introduce the API which is necessary to work with this page.
Every method requires authorization using a token, which will be provided to you through the Bearer scheme
You can generate a token for authorization in the portal here.
[POST] /api/ValidationRequests
When making a request, if you do not send an SMS with the link to the users, you will need to determine the method of delivering the link of the validation page to a user. When sending an SMS, it is necessary to specify the callback URL for the system to make the redirection from requestId to the address denoted by you.
For security reasons, when redirecting a user, the described callback URL is to be validated in the white list of callback URLs which you should list in the portal. In case the white list is empty or URL has not been found in the list, a user will be redirected to the page of the closed request.
Field metadata is useful for storing additional, structured information on an object. As an example, you could store your user's full name and corresponding unique identifier from your system. Metadata is not used by DVS.
[GET] /api/ValidationRequests
Obtaining the list of all created requests
The endpoint allows you to obtain all the created requests with responses. For convenience, it is possible to filter the data and, in addition, the list is subdivided into pages.
[GET] /api/ValidationRequests/{requestId}
Obtaining the request data
On entry the endpoint accepts the ID of the request and its response contains the request data with responses.
[GET] /api/ValidationRequests/Response/{requestId}/{responseId}
Obtaining the data of the specified response in the specified request
[POST] /api/ValidationRequests/ReNotify/{requestId}
Sending the SMS with the link to the validation page to a user
Every response contains the following model which includes the type of the document, date of response creation, identified fields of the document, validation status of the document and data errors if there are any during the process of the document identification.
The full description of the response can be found in Swagger UI.
Listed below are the possible values and descriptions:
- status - possible values: 0, 1, 2, 3
0
- document is valid1
- document is fake2
- data error. If a document is of poor quality and we are not able to identify it, this status will be shown. Also in the field "InvalidDataErrors" there will be a list of problems related to the code and to the message.3
- server error during the document identification- validationStatus - list of meanings for validation steps.
Example of the filled field:
validationStatus: {
expired: false
documentIsValid: false
faceIsValid: false
}
expired
- whether the license is valid at the moment of validation or notdocumentIsValid
- whether a document is valid or notfaceIsValid
- whether the face in the document coincides with the face of the user.
During validation we check the document for data matching and coincidence of two faces.
Note
"expired" does not influence the final decision in relation to the validity of the document and serves as a guideline.
attemptsLeft
- the number of remaining validation attempts. This value is set in the portal here. If a suspicious document is found, the number of attempts is reduced. If the input data are not correct or there is a server error, the number of attempts is not reduced. In case if a user spends all the attempts for validation, the request will be closed.
Integration options: