Verifications

The verification object

Attribute

Type

Description

id

uuid

The unique identifier for the verification.

type

string

The type of verification. drivers_license

email esign

funding_source_code identity

passport

sms

status

string

The status of verification. created

processing

approved

cancelled

rejected

failed

pending

attempts

integer

The number of verification attempts. Initial value is 1. The maximum number of attempts depends on the verification type and processor.

error_code

string

The error key, in case of an error. The value depends on the verification type and processor.

error_message

string

The error message, in case of an error. The value depends on the verification type and processor.

expires_at

time

The time when the verification expires.

Example

{
"id": "f346ced3-f80c-45d9-a9f5-a2b0288cb126",
"type": "sms",
"status": "pending",
"attempts": 1,
"error_code": "",
"error_message": "",
"expires_at": "2017-04-19T14:35:09.308904Z"
}

Single-step verification

Single step verification is when the user provides data of a specific type, such as passport or driver's liences information, and the provider processes it afterwards.

Request
Response
Request

POST /v1/verifications

Attribute

Type

Description

type

string

The type of verification.required email esign

funding_source_code identity

sms

key

string

Custom value. Should describe the purpose of the verification and represent the piece of data being verified, e.g. phone. This value can be passed along to custom or 3rd party processors. required

service

string

An optional reference to the external verification service being used, e.g. idology for KYC.

data

string

The data which the verification process needs for processing, e.g. passport ID. required

Example

{
"type": "identity",
"service": "idology",
"key": "expect_id",
"data": "01234567890123456789",
}
Response

201 Created

Returns a verification object.

Two-step verification

Two-step verification is used when the user initiates the verification process and then provides the required data. For example, request an SMS code for a specific phone number and then provide the code which was sent via SMS.

Note: If an object being verified is attached to a user and has the keys phone or email, it will directly affect the user by marking the phone or email verified for that user.

Step 1– Request data

Request
Response
Request

POST /v1/verifications

Attribute

Type

Description

type

string

The type of verification.required email esign

funding_source_code identity

sms

key

string

Custom value. Should describe the purpose of the verification and represent the piece of data being verified, e.g. phone. This value can be passed along to custom or 3rd party processors. required

value

string

If the verification involves a phone number, this field would contain the full phone number. required

{
"type": "sms",
"key": "phone",
"value": "+44 123 1234 1234",
}
Response

201 Created

Returns a verification object.

Step 2 – Provide requested data

Request
Response
Request

POST /v1/verifications/{id}/data

Attribute

Type

Description

data

string

The data which the verification process needs for processing, e.g. code sent by SMS. required

{
"data": "123456"
}
Response

200 OK

Returns a verification object.

Get a verification object

Get a single verification object by ID.

Request
Response
Request

GET /v1/verifications/{id}

Response

200 OK

Returns a verification object.