Introduction
Welcome to the Veriff documentation. This documentation will help you get started with Veriff. If you have any questions you can use Intercom on the bottom of the page or support@veriff.com to get in contact with us.
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.
New users for your colleagues can be created by an Administrator role account in Veriff Station Settings page.
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.
There are two types of Integrations that can be created by Station user:
Test Integrations are used for development and sessions will not count towards paid usage. Veriff will not provide decisions on sessions created for test integrations
Live Integrations are used for production and sessions created will count towards paid usage and Veriff will be providing decisions for those
Sessions Lifecycle
Generating verification with Veriff
Generating sessions manually
To generate a verification:
- Click "Verifications" on top menu
- Click "Add Verification" from the opened window
- Choose "Integration"
- Fill in the first name, last name
- Click "Generate Verification"
- Click on "Share" to copy the URL or QR image into clipboard
Generating sessions in code
{
"verification": {
"callback": "https://veriff.com",
"person": {
"firstName": "John",
"lastName": "Smith"
},
"document": {
"type": "PASSPORT",
"country": "EE"
},
"vendorData": "unique id of a user",
"lang": "en",
"timestamp": "2016-05-19T08:30:25.597Z"
}
}
The simplest way to get a verification link for web verification flow is to create JSON object containing the user's name and the redirect(callback) URL to which the user will be sent after completing web verification flow (usually it is "Thank you" or "Waiting" page on your side). Then use HTTP POST to send the object to https://stationapi.veriff.com/v1/sessions, with Content-Type application/json and the X-AUTH-CLIENT header containing your API Key.
In response, a JSON session ID and a URL will be sent as follows:
{
"status": "success",
"verification":{
"id":"f04bdb47-d3be-4b28-b028-............",
"url": "https://alchemy.veriff.com/v/sample-url.................",
"sessionToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJh............",
"baseUrl": "https://alchemy.veriff.com"
}
}
The URL of the verification session is where end-user should be redirected on web.
The session ID should be saved on your end - you can tie back the webhook responses to your customer record that way.
The session token is a JSON web token that consists of HS256 encrypted session ID and session creation timestamp. It will expire in 7 days.
Once the end user completes the verification flow, they will be redirected to the callback URL. If callback URL is not specified for the session, user will be redirected to Integration's default Callback URL, which can be set up in Station. It is important to note, the callback does not contain any decision or verification information yet.
Receiving decisions
There are 3 options to fetch decisions for a verification session:
Manual: Station Verifications list displays sessions' details including decisions made
Generating the X-SIGNATURE header
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:
- 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": {
"callback": "https://veriff.com",
"person": {
"firstName": "John",
"lastName": "Smith"
},
"document": {
"type": "PASSPORT",
"country": "EE"
},
"vendorData": "unique id of a user",
"lang": "en",
"timestamp": "2016-05-19T08:30:25.597Z"
}
}
Next, take the request object and add your API-Secret to the end.(replace 'Your-API-Secret' with your API secret)
{
"verification": {
"callback": "https://veriff.com",
"person": {
"firstName": "John",
"lastName": "Smith"
},
"document": {
"type": "PASSPORT",
"country": "EE"
},
"vendorData": "unique id of a user",
"lang": "en",
"timestamp": "2016-05-19T08:30:25.597Z"
}
}Your-API-Secret
Alternatively, if you use stringified request body then your concatenated payload will look as following.(replace 'Your-API-Secret' with your API secret)
{"verification":{"callback":"https://veriff.com","person":{"firstName":"John","lastName":"Smith"},"document":{"type":"PASSPORT","country":"EE"},"vendorData":"unique id of a user","lang":"en","timestamp":"2016-05-19T08:30:25.597Z"}}Your-API-Secret
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);
}
Try our demos
Web
To try out the end-user facing verification flow, 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.
Supported Browsers for verification flow
Desktop
Google Chrome
Mozilla Firefox
Safari
Microsoft Edge (Chromium based)
Opera
Yandex Browser
iOS
- Safari
Android
Google Chrome
Mozilla Firefox
Samsung Browser
Integrations
Android SDK integration
Android SDK Requirements
Veriff Android SDK requires Android 5.0 or newer at runtime. The project must also have Java 8 enabled and use AndroidX instead of support library.
Adding Android SDK
Open the root build.gradle
file and add a new maven destination to the repositories in the allprojects section.
allprojects {
repositories {
maven { url "https://cdn.veriff.me/android/" } //veriff
google()
jcenter()
}
}
Add the Veriff SDK dependency to the application build.gradle
file:
implementation 'com.veriff:veriff-library:3.14.0'
Permissions
The SDK will request all the permissions it needs, please make sure that the CAMERA, RECORD_AUDIO 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.
import com.veriff.VeriffSdk;
Intent intent = VeriffSdk.createLaunchIntent(activity, sessionUrl);
startActivityForResult(intent, REQUEST_CODE);
Parameters are defined as below
Parameters | Description |
---|---|
sessionUrl |
sessionUrl 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 your activity which can be used to compare in onActivityResult |
Customizing the SDK
Setting a theme (Optional)
Starting from version 2.6.0
you can customize the look and feel of the SDK flow by passing a VeriffBranding
instance via VeriffConfiguration
to createLaunchIntent
. See the example below.
VeriffBranding branding = new VeriffBranding.Builder()
.themeColor(getResources().getColor(R.color.theme_color))
.backgroundColor(getResources().getColor(R.color.background_color))
.statusBarColor(getResources().getColor(R.color.status_bar_color))
.primaryTextColor(getResources().getColor(R.color.primary_text_color))
.secondaryTextColor(getResources().getColor(R.color.secondary_text_color))
.toolbarIcon(R.drawable.toolbar_icon)
.bulletPoint(R.drawable.bullet_point)
.buttonCornerRadius(48f)
.notificationIcon(R.drawable.notification_icon)
.build();
VeriffConfiguration configuration = new VeriffConfiguration.Builder()
.branding(branding)
.build();
Intent intent = VeriffSdk.createLaunchIntent(activity, sessionUrl, configuration);
startActivityForResult(intent, REQUEST_CODE);
All custom values for branding are optional. If a value is not provided for them the default Veriff color or icon will be used.
Setting a locale for the SDK (Optional)
Starting from version 3.1.0
you can set a locale(java.util.Locale
) for the SDK from the app itself. Even if you set a locale for the SDK the users will still be able to change the language during the flow if they wish to.
Locale appLocale = Locale.ENGLISH;
VeriffConfiguration configuration = new VeriffConfiguration.Builder()
.locale(appLocale)
.build();
Intent intent = VeriffSdk.createLaunchIntent(activity, sessionUrl, configuration);
startActivityForResult(intent, REQUEST_CODE);
Getting the verification status
Veriff SDK sends callbacks to your mobile application. To capture the result override the onActivityResult
method in your activity that started the verification flow:
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
if (requestCode == REQUEST_CODE) {
VeriffResult result = VeriffResult.fromResultIntent(data);
if (result != null) {
handleResult(result); //see below for handling the result
}
}
super.onActivityResult(requestCode, resultCode, data);
}
public void handleResult(VeriffResult result) {
switch (result.getStatus()) {
case DONE:
// Session is completed from user's perspective
break;
case CANCELED:
// User cancelled the session
break;
case ERROR:
// An error occurred during the flow, Veriff has already shown UI, no need to display
// a separate error message here
Log.w(TAG, "Verification error occurred: " + result.getError());
break;
}
}
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
To turn on logging, simply add your logging implementation instance (instance of VeriffLogger
class) to the SDK before launching the SDK as shown.
VeriffSdk.setLogger(<Instance of your logging class>);
Intent intent = VeriffSdk.createLaunchIntent(activity, sessionUrl);
startActivityForResult(intent, REQUEST_CODE);
Excluding ML Kit support
Veriff Android SDK uses ML Kit for things like face detection, barcode scanning or text recognition to improve the end-user flow experience. It uses on-device models that are predownloaded with play services. If your app cannot use play services at all then you can exclude the transitive mlkit
dependency - this will remove any dependencies on ML Kit and disable the use of these ML modules at runtime:
implementation('com.veriff:veriff-library:3.14.0') {
exclude group: 'com.veriff', module: 'mlkit'
}
Migrating to Veriff Android SDK 3.0.0
Follow these steps to migrate from SDK 2.x.y to 3.0.0
Switch to AndroidX
Veriff SDK 3.0.0 requires AndroidX 1.0.0 or later. If you haven't switched to AndroidX in your app yet then follow this guide.
Enable Java 8
Veriff SDK 3.0.0 requires Java 8 language features to be enabled in your project. If you don't have this enabled already then add this to your app/build.gradle
file under the android {}
section:
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
See more here.
Switch from baseUrl
and sessionToken
to sessionUrl
The new 3.0.0 SDK requires a single sessionUrl
parameter instead of baseUrl
and sessionToken
. See the documentation here. As a backwards compatibility measure, if a sessionToken
value is passed into the sessionUrl
parameter then it will still work with an assumed baseUrl
of magic.veriff.com
.
Use com.veriff.*
classes instead of mobi.lab.veriff.data.*
ones
The name and location of the main SDK entry class has changed from mobi.lab.veriff.data.Veriff
to com.veriff.VeriffSdk
. The API is largely similar - instead of Veriff.Builder
there's a VeriffSdk.createLaunchIntent
method that returns an Intent
which you can then use to launch veriff. See example here.
If you are using Branding
to customize the look and feel of the SDK then it has a new name - VeriffBranding
. The builder interface has been streamlined by removing the set*
prefixes from all the methods. Read more about customization here.
Use com.veriff.VeriffResult
instead of reading return Intent
directly
Starting with 3.0.0 there's a new way to handle the result of the verification flow. Instead of reading INTENT_EXTRA_STATUS
directly from the returned data
intent, use VeriffResult.fromResultIntent(data)
to get a result object with a status
field and an optional error
field. We've reduced status
to just three - CANCELED, ERROR, DONE
. In case of ERROR
the error
field contains more information. See the example here.
Remove usage of deprecated types
While the old SDK entrypoints are still present for backwards compatibility they will be removed in the future. Please remove usage of any SDK type marked with @Deprecated
- the easiest way to discover these is to look at your Gradle build log with Java/Kotlin compilation warnings turned on.
Here's a list of old deprecated classes due to be removed in a future release:
mobi.lab.veriff.data.Veriff
mobi.lab.veriff.data.Veriff.Builder
mobi.lab.veriff.data.VeriffConstants
mobi.lab.veriff.data.Branding
mobi.lab.veriff.data.Branding.Builder
mobi.lab.veriff.data.DrawableProvider
mobi.lab.veriff.util.LogAccess
mobi.lab.veriff.util.LogAccess.LogLevel
mobi.lab.veriff.util.LogcatLogAccess
mobi.lab.veriff.service.VeriffStatusUpdatesService
Android SDK Changelog
Below is a summary of changes introduced with each version of the Android SDK
Versions
- Technical improvements and UI bug fixes
- Updated the barcode scanning copy
- Removed NFC biometric confirmation screen
- Removed camera switching button
- Technical optimisations and bug fixes
- Updated NFC flow UI for US passports
- Made session starts more robust
- Fixed a video issue on 6.x Huawei phones with TOPAZ encoder
- Technical optimisations and bug fixes
- The SDK now includes a transitive dependency on ML Kit
- Fixed an issue where camera preview didn't render properly on some 5.x devices
- Fixed a critical issue where camera stopped working if SDK was backgrounded.
- Added more contextual information for videos. This enables you to match videos to the step during the IDV process where they were recorded.
- SDK shows a better error message when microphone is in use by some other app.
- Technical optimisations and bug fixes.
- Updated barcode scanning design and UX.
- Technical optimisations and bug fixes.
- Added new SDK theming options - you can now customize text color, background color, status bar color, bullet point icon and button roundness.
- Fixed a NullPointerException crash originating from FlowActivity.
- Fixed a IllegalArgumentException: Bad limit crash on some Huawei devices.
- Technical optimisations and bug fixes.
- Technical optimisations and bug fixes.
- Fixed an ArrayIndexOutOfBounds crash.
- Technical optimisations and bug fixes.
- SDK is now 11 MB smaller.
- Removed WebRTC dependency.
- Added support for Catalan.
- Separate thank you screen won`t be shown in case user was left waiting for decision.
- Technical optimisations and bug fixes.
- Intro step can now be skipped if the host app is modified accordingly.
- Fixed an issue when languages weren't switched properly.
- Assisted image capture repeat attempts are now limited to 3.
- Fixed a langauge selection bug while relaunching the verification flow.
- Assisted image capture now has illustrations.
- Introduction messages are now fetched from the server.
- Fixed a thread and file descriptor leak.
- Technical optimisations and bug fixes.
- Added support for specifying a language by passing a Locale when launching the SDK.
- Fixed a crash when attempting to continue the flow without selecting a country.
- Fixed flow getting stuck if exit dialog was displayed during the initial session load.
- Added an option to have a selfie-pic-only flow.
- Breaking: Veriff Android SDK now requires AndroidX and Java8.
- Revamped the API of the SDK and deprecated the old API
- Improved messaging when reopening already completed sessions.
- Veriff resource IDs no longer show up in the IDE auto-complete window.
- Improved accessibility with various display zoom levels and screen readers.
- Fixed receiving feedback at the end of the flow.
- The document selection screen now specifically mentions "government ID".
- Fixed translation issues with Serbian (Latin) in various places.
- Fixed a crash with the combination of Android 10, `targetSdkVersion 29` and `READ_PHONE_STATE` permission.
- Added biometric verification flow for supported passports.
- Moved selfie step after the document steps.
- Improved assisted image capture.
- Technical optimisations and bug fixes.
- Improved translations and copy.
- Improved UI of the 'leave user waiting' feature.
- Fixed background video corruption on the Google Pixel 3 family.
- Technical optimizations and bugfixes
- Added 'leave user waiting' feature.
- Fixed a crash after session submission with residence permits.
- Improved efficiency and performance of image uploads
- Updated handover screen design
- Added a confirmation dialog when leaving the upload screen
- Added an option to retry failed uploads at the end of the flow
- Fixed language change for some host apps
- Fixed an occasional crash after scanning the barcode of a US driver's license
- Improved file uploads
- Improved error reporting and analytics
- Added support for additional image quality checks
- Fixed a crash on Android 5.x when host app uses AndroidX Appcompat 1.1.x
- Fixed a critical ClassNotFound regression introduced in 2.7.0
- Updated the look and feel of the SDK
- Fixed unclickable shutter button when capturing before camera has loaded
- Fixed duplicate flow if internet was lost in the photo preview screen
- Improved stability and reliability
- Added support for white labelling Veriff
- Added ability to disable Selfie step
- Pause WebRTC capturing when UI is paused
- Fixed a crash on camera focusing on some Samsung phones
- Fixed a crash when changing language on Android 6.x or older
- Added US driver's license barcode scanning
- Added support for customizing the UI look by changing the main color, toolbar and notification icon
- Added Spanish (Latin America) localization
- Added automatic face detection and focusing on face
- Changed the copy to be specific to every document type
- Reduced the file size of uploaded selfie and document images
- Added 11 new localizations
- Fixed bugs and increased stability of the SDK
- Added support for additional image quality checks
- Fixed language change from Spanish to Mexican Spanish
- Fixed "service did not then call startForeground" crashes
- Fixed video not working with the combination of Veriff, old Gradle plugin and OkHttp 4
- Added support for Mexican Spanish
- Removed white screen as flash while taking selfie
- WebRTC updates and improvements
- Improved downstream proguard rules
- Fixed SDK crashes after process recreate
- Fixed a large number of bugs concerning uploads
- Fixed restarting the verification from the "No internet" error screen
- Fixed dark room warning not being translated
- Added Japanese language
- Added dark room detection
- Fixed a few issues around ending the video session
- New intro screen outlining the verification flow
- Added Turkish language
- Fixed videos being broken from Samsung 6.x-7.x devices
- Fixed a few crashes
- Fixed Veriff title bar clashing with system statusbar on some Android versions
- Fixed country list keyboard behaviour on Android 5.0
- Fixed an issue with capturing photos on Android 5.x devices
- Added encryption for photos in internal storage
- Moved Probity collector into SDK, removing the external dependency on it
- Camera/webrtc fixes and improvements
- Various small fixes and improvements
- Increased minSdkVersion to 21
- Added video mandatory flag
- Increased socket write timeout when uploading
- Added Arabic support
- Other camera/webrtc fixes and improvements
- Added new languages: Georgian, Hindi, Malay, Ukranian
- Fixed multiple copy issues
- Fixed WebRtc client issues
- Fixed OnePlus 6T focusing issue
- Added option to enable verbose webrtc logging
- Other camera/webrtc fixes and improvements
- Language fixes for cancel dialog and instructions screen
- Country list is now translated
- Fixed a lot of camera issues on various devices
- Fixed "Internet connection lost" popping up after verification flow was completed
- Fixed country selection screen being partially translated
- Updated translation
- Critical hot fix for 2.3.1
- Removed setting custom color schema and background image
- Add proguard rule to keep WebRTC classes and methods (Fixes #6)
- Added scroll view to document selection screen to fix UI issue in phones with small form factor
- Bugfixes
- Added support for Inflow Feedback
- Added permission for foreground service
- Fixed camera issues with Pixel phones
- Bundled proguard rules with the SDK
- Fixed aspect ratio issue for legacy flow
- Added logging for WebRTC errors
- Added support for preselected country and document (Fixes #3)
- WebRTC production ready
- Match camera and image preview scaling (camera preview was zoomed in)
- Focus camera on screen touch
- Fix video rotation in Backoffice
- Event tracking for business funnel
- Implemented in-house crash reporting
- Improved performance while taking snapshots
- Always take and upload 2 pictures per step
- Added Czech and Lithuanian language support
- WebRTC beta support with a fallback
- Event tracking for business funnel
- Implemented crash reporting
- Improved performance while taking snapshots
- New design
- Integration changes
- Reduced library size
- Optimizations
- Fixed camera issue with older Android versions
- Fixed English langauge resource
- Added gradle publish script
- Added Italian, Dutch and French languages
- Removed Firebase dependency requirement
- Removed Twilio dependency requirement
- Removed Eventbus dependecy requirement
- Added missing translations
- Fixed indefinite upload bug
- Updated language resources
- New versioning management
- Upgraded gradle version
- Upgraded dependecy versions
- Fixed language persistence issue
- Further improved Latvian language resources
- New language selection
- New color schema
- Improved face detection
- Improved Latvian language resources
- Refactoring and general bug fixes
- New library wide toolbar with cancelation and language selection options
- Changed text values and removed unused resources
- Design improvements
- Refactoring and general bug fixes
- Implemented new Error screens for:
- Network error
- System error
- Uploading error
- Session expired error
- Fixed and improved Samsung phones camera issues
- Improved logging
- General bug fixes
Release 3.14.0
Release 3.13.0
Release 3.12.0
Release 3.11.0
Release 3.10.1
Release 3.10.0
Release 3.9.0
Release 3.8.0
Release 3.7.0
Release 3.6.0
Release 3.5.0
Release 3.4.0
Release 3.3.0
Release 3.2.1
Release 3.2.0
Release 3.1.2
Release 3.1.1
Release 3.1.0
Release 3.0.1
Release 3.0.0
Release 2.13.0
Release 2.12.0
Release 2.11.3
Release 2.11.2
Release 2.11.1
Release 2.11.0
Release 2.10.0
Release 2.9.0
Release 2.8.0
Release 2.7.1
Release 2.7.0 (Deprecated due critical build issues)
Release 2.6.2
Release 2.6.1
Release 2.6.0
Release 2.5.0
Release 2.4.8
Release 2.4.7
Release 2.4.6
Release 2.4.5
Release 2.4.4
Release 2.4.3
Release 2.4.2
Release 2.4.1
Release 2.4.0
Release 2.3.6
Release 2.3.5
Release 2.3.4
Release 2.3.2
Release 2.3.1
Release 2.3.0
Release 2.2.1
Release 2.1.1
Release 2.1.0.
Release 2.0.0.
Release 1.6.8.
Release 1.6.7.
Release 1.6.6.
Release 1.6.5.
Release 1.6.4.
Release 1.6.3.
Release 1.6.2.
Release 1.6.1.
Release 1.6.0.
Release 1.5.0.
Release 1.4.0.
iOS SDK integration
iOS SDK Requirements
Integration Veriff iOS SDK requires at least iOS version 11.0
Adding the SDK to the project
VeriffSDK requires the latest stable version of Xcode available at the time the release is made. If you would like to use versions that are independent of Swift versions, please integrate .xcframework
.
Using Swift Package Manager
To integrate Veriff SDK with Swift Package Manager, open File > Swift Packages > Add Package Dependency and add the Veriff iOS SDK Swift Package repository url as stated below;
https://github.com/Veriff/veriff-ios-spm/
After clicking Next, select the version you would like to integrate and complete the integration.
Using Cocoapods
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 Carthage
To integrate VeriffSDK into your Xcode project using Carthage, specify the required libraries below in your Cartfile
.
binary "https://cdn.veriff.me/ios/carthage/VeriffSDK.json"
After a carthage update
add Veriff framework from Carthage/Build/<platform>
to project.
To target build phases carthage copy-frameworks
run script step add the following input files:
$(SRCROOT)/Carthage/Build/iOS/Veriff.framework
To target build phases carthage copy-frameworks
run script step add the following output files:
$(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/Veriff.framework
Using XCFramework
To integrate VeriffSDK into your project manually, please download VeriffSDK.
After framework is downloaded, drag VeriffSDK.xcframework into the Frameworks, Libraries, and Embedded Content section of your target and that's all!
Adding permissions
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, microphone and NFC reader permissions for capturing photos, video and scanning passport during identification. Your application is responsible to describe the reason why camera, microphone and NFC reader is used. You must add 3 descriptions listed below to info.plist
of your application with the explanation of the usage.
NSCameraUsageDescription
NSMicrophoneUsageDescription
NFCReaderUsageDescription
Add required steps for NFC scanning
The application needs to define the list of application IDs or AIDs it can connect to, in the Info.plist file. The AID is a way of uniquely identifying an application on a ISO 7816 tag, which is usually defined by a standard. Passports use the AID A0000002471001.
<key>com.apple.developer.nfc.readersession.iso7816.select-identifiers</key>
<array>
<string>A0000002471001</string>
</array>
Add a new entitlement for NFC scanning, available since iOS 13. This new entitlement is added automatically by Xcode when enabling the Near Field Communication Tag Reading capability in the target Signing & Capabilities. After enabling the capability the *.entitelments file needs to contain the TAG format:
<key>com.apple.developer.nfc.readersession.formats</key>
<array>
<string>NDEF</string>
<string>TAG</string>
</array>
Starting verification flow
Import Veriff in your code
import Veriff
In order to use Veriff SDK, please import it to your class that will use the SDK.
Start the verification flow
In order to start the verification flow please call the method below with the sessionUrl
you receive from your backend implementation [Required].
var veriff = VeriffSdk.shared
veriff.startAuthentication(sessionUrl: sessionUrl)
Parameters are defined as below;
Parameters | Description |
---|---|
sessionUrl |
sessionUrl should be unique for each call. Check /sessions endpoint in the API documentation here to learn how to generate one. |
configuration |
Optional VeriffConfiguration object. Refer to Customize user interface (Optional) for how to use it. |
Customize user interface (Optional)
Setting theme color and logo
You can customize the Veriff user interface through your own application, by letting the SDK know of your brand's main color and logo. The Branding
struct allows customization of the theme color, navigation bar title image, button corner radius, background color, status bar color, primary and secondary text colors, bullet point image and button title text casing. In order to use customization set the branding
property of VeriffConfiguration
before you start the verification.
See the Veriff SDK customization guide document to see what it looks like.
let yourColor = UIColor.someColor()
let yourImage = UIImage(named: “logo.png”)
var branding = VeriffSdk.Branding(themeColor: yourColor, logo: yourImage)
branding.buttonCornerRadius = CGFloat.cornerRadius
branding.backgroundColor = UIColor.backgroundColor
branding.statusBarColor = UIColor.statusBarColor
branding.primaryTextColor = UIColor.primaryTextColor
branding.secondaryTextColor = UIColor.secondaryTextColor
branding.bulletPoint = UIImage(named: “bulletPoint.png”)
branding.isTextUppercase = false
Setting the user interface language
The Veriff iOS SDK allows setting the language of the SDK. In order to use this language, please set the languageLocale
property of VeriffSdk.Configuration
before you start the verification.
let locale = Locale(identifier: “et”)
Create the configuration object
var configuration = VeriffSdk.Configuration(branding: branding, languageLocale: locale)
Custom intro screen
Veriff supports replacing introduction screen with a custom client developed introduction screen for eligible clients. First, please ask about this possibility from your account manager. In case we can offer it for you then removal process is following:
- You agree your own introduction screen visuals and copy with our account manager and get relevant legal documents signed in case their needed.
- After that Veriff will enable custom introduction screen from backend for your integrations.
- After you have implemented your own introduction screen you can change the configuration option specified below.
configuration.customIntroScreen = true
Note: This step alone is not enough to enable the custom intro screen. Make sure to contact your account manager so they can enable the feature for your integration.
Start the verification flow by using the configuration
var veriff = VeriffSdk.shared
veriff.startAuthentication(sessionUrl: sessionUrl, configuration: configuration)
Handling result codes from SDK
To receive session results, you must implement the VeriffSdkDelegate
protocol and assign a delegate to the VeriffSdk
instance.
veriff.delegate = self
The Veriff SDK returns a number of result codes that your application can handle.
extension VerificationService: VeriffSdkDelegate {
func sessionDidEndWithResult(_ result: Veriff.Result) {
switch result.status {
case .done:
// The user successfully submitted the session
break
case .canceled:
// The user canceled the verification process.
break
case .error(let error):
switch error {
…
}
}
}
}
You can find the description of status codes below:
done
The session status is finished from clients perspectivecanceled
User canceled the verification processerror
An error occurred. To see the error reason, check the associated value(Veriff.Error
) passed by error status.
Notes
- The Veriff SDK always shows an error screen itself. The errors returned by the session are to inform your application.
- 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).
Migrating to Veriff iOS 3.0.0
Switch from baseUrl
and sessionToken
to sessionUrl
The Veriff
object in the SDK 3.0.0 takes a required sessionUrl
and an optional VeriffConfiguration
instance as parameters into initialisation. The sessionUrl
is received from your backend implementation (see the documentation here), it is composed of the baseUrl
and sessionToken
sent to the VeriffConfiguration
object in earlier versions.
Updated VeriffConfiguration
object
The VeriffConfiguration
struct now takes in branding
and languageLocale
as initialisation parameters.
The new VeriffDelegate
method
You can now receive session results via func sessionDidEndWithResult(_ result: Veriff.Result)
instead of the obsolete func onSession(result: VeriffResult, sessionToken: String)
. The sessionToken
is included in the Veriff.Result
as an instance variable.
Use Veriff.Result
instead of VeriffResult
The new Veriff.Result
struct comprises status: Status
and sessionToken: String?
instance variables. The Status
enum can be of three types: done
, canceled
, error
. The description
variable on the Veriff.Result
returns additional information as a string. See the example here.
Migrating to Veriff iOS 4.0.0
Rename Veriff
instances to VeriffSdk
The name Veriff
was used both for our module and public class name. However this blocked us from supporting Swift Package Manager due to Swift compiler bug. We renamed our public class name to VeriffSdk
.
VeriffConfiguration
is now VeriffSdk.Configuration
VeriffConfiguration struct is moved under VeriffSdk
. Please replace the occurences of VeriffConfiguration
with VeriffSdk.Configuration
.
Branding
is now VeriffSdk.Branding
Branding struct is moved under VeriffSdk
. Please replace the occurences of Branding
with VeriffSdk.Branding
.
Rename VeriffDelegate
to VeriffSdkDelegate
Please replace the occurences of VeriffDelegate
with VeriffSdkDelegate
.
VeriffSdk.Result.description
made non-optional
If you were dealing with unwrapping it, feel free to remove it.
VeriffSdk.Result.sessionToken
removed and VeriffSdk.Result.sessionUrl
added instead
Please remove the occurences of sessionToken
. You can now use sessionUrl
to get the full sessionUrl
including token.
iOS SDK Changelog
Below is a summary of changes introduced with each version of the SDK
Versions
- Support for capital first letters in branding.
- Landscape camera support.
- Translations are updated on leave user waiting screen.
- Fixed rendering problem for privacy policy in Hindi.
- Improved barcode picture quality.
- Streamlined NFC flow by removing biometric screen.
- Technical improvements for local videos.
- Minor bug fixes.
- Updated barcode scanning UI
- Added more logging for video quality
- Fixed a crash for devices that supports NFC but below iOS 13
- Technical improvements
- Streamlined flow by removing some screens.
- Fixed privacy policy being rendered wrong in some locales.
- Fixed a crash on Resubmission screen.
- Fixed an issue where introduction texts are in different locale than session locale.
- Fixed camera switch issue.
- Fixed no active and enabled connection crash.
- Added NFC support for passports.
- Added UISceneDelegate support.
- Updated support to Xcode 12.4 for non-SPM integrations.
- Fixed a localization issue on resubmission feedback view.
- Fixed an issue where camera opens with a black screen.
- Fixed a problem with some sessions missing background audio.
- Fixed a crash originating from appending pixel when writer is unexpected state.
- Fixed a crash that happens during loading of Handover view.
- Added leave user waiting feature. Users can wait until they get a decision.
- Added resubmission feedback feature. Users will see what was the problem with previous session.
- Added support for new customisation options.
- Fixed UIWindow dismiss issue.
- Fixed delegate error for camera permission.
- Fixed a bug where selfie with document step asked multiple times.
- More analytics information added for local video.
- Performance improvements on local video.
- Removed WebRTC dependency. SDK is now ~15MB smaller.
- Privacy policy updated.
- Fixed a leak on intro screen.
- Swift Package Manager support.
- Breaking API changes
- Added support for Catalan.
- Fixed a bug on setting UI langauge with SDK launch
- Xcode 12.0 compatible build. NOTE: If you are integrating through Cocoapods you will need to update to Xcode12 compatible version of Cocoapods. (Compatible version at time of the release is
1.10.0.rc.1
) - Analytics event fix.
- Xcode 11.7 compatible build.
- iOS 14 support
- Support for no intro flow
- Removed hints from camera view.
- New API
- Added support for specifying a language by passing a Locale when launching the SDK
- Moved selfie step to the end of the flow
- Image upload bug fix
- Dynamic intro page copy
- Technical optimisations and bug fixes.
- Accessibility support.
- Selfie only flow support.
- iOS 13 UIWindow fixes.
- Fixed info text for microphone permission callback.
- XCFramework support
- Removed SocketIO and Starscream dependencies.
- Updated ID translations.
- User interface improvements on Document Selection screen.
- Privacy policy link now respects UI language.
- Assisted Image Capture
- Handling of expired tokens improved.
- Connection timeouts increased.
- UI fixes on Upload and Language views.
- Light detection and language change crashes are fixed.
- Fix for scaling issue of navigation bar logo.
- WebRTC connection improvements.
- Terms of Service text updated.
- Network timeout improvements.
- Xcode 11.4 support.
- onSession delegate is called only once.
- Animated instruction added for document back pictures.
- Analytics and error logging improved.
- Camera refactored.
- Update brand
- Turn barcode scan frame green on success
- Fix privacy label hiding bug
- Fix Selfie step appearing in handover screen when portrait picture is disabled
- Fix language selector not opening over error screens
- Fix image upload error reporting.
- XCode 11.3 support.
- Image quality is increased.
- Re-architectured SDK
- Carthage support
- White label support
- Preselected document copy fix
- Preselected text field now clears if user wants to change manually
- All steps(selfie, document front, document back, passport) are optional now
- Serbian-Latin language fix
- Dropped iOS 10 support
- Reachability removed (a dependency)
- WebRTC stall error fixed
- Fix of AppStore submission warning about es-latam language file.
- Barcode reading improvements.
- WebRTC improvements for iOS 13.
- 3rd party dependency Presentr removed.
- Low light detection UI fixes.
- Xcode 11.2.1 & Swift 5.1.2 support.
- WebRTC improvements for iOS 13.
- Added US driver's license barcode scanning.
- Added support for 11 new languages.
- Added support for Mexican Spanish.
- Removed white screen as flash while taking selfie.
- Session validity token implemented.
- Privacy policy web pages localized.
- Performance & Analytics improvements.
- Support for changing UI colors.
- Japanese language support.
- Performance & Analytics improvements.
- UI improvements.
- Turkish language support.
- Performance & Analytics improvements.
- Camera freezeing when coming from background fixed.
- Enhanced logging output.
- Video mandatory added.
- RTL support added.
- Use correct strings for instruction view subtitles
- Remove 3rd party code from repo
- Tap to focus camera
- Camera started log event added
- Preselected document string change
- User can change country and document
- Country list is now translated
- Updated translations
- Device info logging
- Added support for preselected country and document (Fixes #2)
- New languages added: Czech and Lithuanian
- Bitcode support
- WebRTC video(bitcode support will follow in 2.2.1)
- WebRTC beta support(face detection and bitcode support will follow in 2.2.1)
- Xcode 10.2 support
- Improving uploading conversions for devices on slow networks
- Fallback to device language if session is missing language
- Minor UI changes
- Restores Xcode debugging support
- Bugfixes
- Navigation bar appearance issues fixed
- Restored support for i386 x86_64 architectures
- New design
- Added country selection
- Integration changes
- Reduced library size
- Optimizations
- New languages added: Dutch, French, Italian
- Removes video call functionality
- New languages added: Chinese, Polish, Portuguese, Spanish, Vietnamese
- Translations updated for existing languages
- Fixes storage wipe issue on cancel verification
- Updates Latvian and Russian translations
- Fixes issue with method name collision
- Minor design changes
- Fixes crash on upload
- New language switcher design
- Updates to default colors in UI
- Latvian translations updated
- General bugfixes
- New library wide toolbar with cancelation and language selection options
- Changed text values and removed unused resources
- Design improvements
- Camera stability improvements
- Refactoring and general bug fixes
- Improved camera stability
- Improved logging
- Updated Latvian translations
- General bug fixes
4.8.0
4.7.0
4.6.0
4.5.0
4.4.0
4.3.2
4.3.1
4.3.0
4.2.0
4.1.0
4.0.0
3.4.0
3.3.0
3.2.0
3.1.0
3.0.0
2.9.5
2.9.4 (Deprecated due critical upload bug)
2.9.3
2.9.2
2.9.1
2.9.0
2.8.4
2.8.3
2.8.2
2.8.0
2.7.4
2.7.3
2.7.1
2.7.0
2.6.2
2.6.1
2.6.0
2.5.2
2.5.1
2.5.0
2.4.2
2.4.1
2.4.0
2.3.4
2.3.3
2.3.2
2.3.0
2.2.0
2.1.0
2.0.5
2.0.4
2.0.3
2.0.2
2.0.1
2.0.0
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.2
1.5.1
1.5.0
1.4.0
React Native SDK integration
React Native SDK requirements
Integration with Veriff React Native SDK requires the project to target at least iOS version 11.0 and Android version 5.0 (api 21) or higher.
Add the SDK to a project
Add the Veriff React Native SDK to your package.json
file:
npx yarn add @veriff/react-native-sdk
Or if using npm
:
npm install @veriff/react-native-sdk --save
Update Android build.gradle
file
Open the root build.gradle
file in the android
folder and add a new maven destination to the repositories in the allprojects
section. The best place is right after the local node_modules
repositories and before the google()
repository.
allprojects {
repositories {
// ... local react native repos
maven { url "https://cdn.veriff.me/android/" } //veriff
google()
jcenter()
}
}
Add Swift to the ios module
Veriff SDK requires your ios module to have some Swift code. If you don't have any Swift code yet then add a new empty.swift
file in Xcode. If Xcode offers to add a bridging header then add it.
Update iOS Podfile
Open Podfile
in the ios
folder and make sure that platform
is 11.0 or higher:
platform :ios, '11.0'
Also make sure your main target in the Podfile
contains use_native_modules!
directive at the end:
target 'MyApp' do
# pod 'foo'...
use_native_modules!
end
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.
Add them to the ios/TARGET/Info.plist
file:
<dict>
...
<key>NSCameraUsageDescription</key>
<string>Access to camera is needed for user identification purposes </string>
<key>NSMicrophoneUsageDescription</key>
<string>Access to microphone is needed for video identification</string>
</dict>
Set the iOS target in Xcode
Make sure that the 'iOS Deployment Target' in Xcode (under Project > target > Info > Deployment Target) is set to iOS 11.0 or later.
Using the Veriff React Native SDK
Starting the verification flow
In order to use Veriff SDK, please import it to the file that will use the SDK.
import VeriffSdk from '@veriff/react-native-sdk';
Before you can launch the verification flow you'll need a session URL. See our documentation on generating one.
Once you have the URL you can launch Veriff using VeriffSdk
imported earlier:
var result = await VeriffSdk.launchVeriff({ sessionUrl: SESSION_URL });
User Interface customization
You can customize Veriff SDK user interface in your application by defining your brand main color and logo.
See Veriff SDK customization guide document on how it looks.
Veriff React Native SDK allows the customization of various colors and images in the SDK flow by passing in these optional properties when launching Veriff:
var result = await VeriffSdk.launchVeriff({
sessionUrl: SESSION_URL,
branding: {
themeColor: '#ff00ff',
backgroundColor: '#ffffff',
statusBarColor: '#ff00ff',
primaryTextColor: '#000000',
secondaryTextColor: '#333333',
buttonCornerRadius: 28,
logo: 'parrot', // see alternative options for logo below
androidNotificationIcon: 'ic_parrot'
},
});
When a color isn't defined the default Veriff theme color is used. Same applies to image assets - when they aren't defined the defaults are used. The image assets need to be added into Xcode assets in the iOS project and into drawable folders in the Android project. In the example above you would need to add an image asset named 'parrot' into Xcode assets and both 'parrot.png' and 'ic_parrot.png' to Android drawable folders in android/src/main/res
.
Alternative ways to provide the logo
Instead of using platform-specific image assets you can provide a URI to an image which will then be used:
var result = await VeriffSdk.launchVeriff({
sessionUrl: SESSION_URL,
branding: {
themeColor: '#ff00ff',
logo: { uri: 'http://example.com/logo/parrot.jpg' },
},
});
React Native assets are also supported through resolveAssetSource
:
const resolveAssetSource = require('react-native/Libraries/Image/resolveAssetSource');
const parrot = require('./img/parrot.png');
var result = await VeriffSdk.launchVeriff({
sessionUrl: SESSION_URL,
branding: {
themeColor: '#ff00ff',
logo: resolveAssetSource(parrot),
},
});
Setting the user interface language
The Veriff RN SDK allows setting the language of the SDK. In order to use this language, please pass the locale as in example below;
var result = await VeriffSdk.launchVeriff({
sessionUrl: SESSION_URL,
branding: {
themeColor: '...',
},
locale: 'et'
});
Handling the result from the SDK
The result
returned by launchVeriff
will have a status
field that is one of either VeriffSdk.statusDone
, VeriffSdk.statusCanceled
or VeriffSdk.statusError
. In case of statusError
there will be a error code (not human-readable) in the error
field.
var result = await VeriffSdk.launchVeriff({ sessionUrl: SESSION_URL });
switch (result.status) {
case VeriffSdk.statusDone:
// user submitted the images and completed the flow
// note that this does not mean a final decision yet
break;
case VeriffSdk.statusCanceled:
// user canceled the flow before completing
break;
case VeriffSdk.statusError:
// the flow could not be completed due to an error
console.log("Veriff verification failed with error=" + result.error);
break;
}
Migrating to React Native SDK 2.0.0
Follow these steps to migrate to React Native SDK 2.0.0 API
Use new parameter sessionUrl
New API uses sessionUrl
instead of a sessionToken
. sessionUrl
is a combination of base URL and session token.
Rename parameter navigationBarImage
to logo
We renamed the navigationBarImage
parameter in configuration to logo
.
React Native SDK Changelog
Below is a summary of changes introduced with each version of the React Native SDK
Versions
- Updated public readme of the package in npmjs, no functional changes.
- Updated public readme of the package in npmjs, no functional changes.
- Added new customization options to provide background, status bar and text colors.
- Added an option to customize primary button corner radius.
- The logo customization option now supports URLs and RN assets.
- Updated the iOS native module to use Veriff iOS SDK 4.+
- New public API for the React Native SDK.
- Updated the iOS native module to use Veriff iOS SDK 3.+
- Updated the Android native module to use Veriff Android SDK 3.+
- Enabled Java 8 support for Android.
- Added more granular error messages for NFC related errors.
- Fixed a 'NoSuchKeyException: branding' error on Android if no customization was applied
- Added support for UI customization
- Updated README in npmjs.com
- Initial React Native SDK release
Release 2.3.2
Release 2.3.1
Release 2.3.0
Release 2.2.0
Release 2.1.0
Release 2.0.0
Release 1.1.0
Release 1.0.1
Release 1.0.0
Release 0.9.1
Release 0.9.0
Javascript SDK Integration
Veriff JS SDK, is a simple and customisable library which helps to integrate with Veriff Online Identity solution. Use this to simply include Veriff flow. You don't need any backend on your side your own for this including JS SDK to your website.
Install JS SDK
Include as a script tag:
<script src='https://cdn.veriff.me/sdk/js/1.1/veriff.min.js'></script>
or install it via a package manager
$ npm install --save @veriff/js-sdk
// CommonJS
const Veriff = require('@veriff/js-sdk');
// ES6 style import
import Veriff from '@veriff/js-sdk';
Adding JS SDK
Veriff JS SDK requires one parent element in HTML:
<div id='veriff-root'></div>
It is possible to set the width of js-sdk form through style attribute:
<div id='veriff-root' style="width:400px"></div>
In order to initialize the library, API Key, parentId and onSession callback function is required.
const 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"
}
}
vendorData: string - Client specific data string, max 400 characters long, will be sent back unmodified using webhooks. In case the Given name / Last name / Vendor Data or all of them are known, they can be passed to the SDK, therefore text input fields will not be rendered.
const veriff = Veriff({
apiKey: 'API_KEY',
parentId: 'veriff-root',
onSession: function(err, response) {
// received the response, verification can be started now
}
});
veriff.setParams({
person: {
givenName: 'Foo',
lastName: 'Bar'
},
vendorData: 'example@mail.com'
});
veriff.mount({
submitBtnText: 'Get verified'
});
It is possible to disable fields rendering without passing any data by not including anything in corresponding value:
const veriff = Veriff({
apiKey: 'API_KEY',
parentId: 'veriff-root',
onSession: function(err, response) {
// received the response, verification can be started now
}
});
veriff.setParams({
person: {
givenName: ' ',
lastName: ' '
},
vendorData: ' '
});
veriff.mount({
submitBtnText: 'Get verified'
});
Additionally the input placeholder and button text value can be customised.
const veriff = Veriff({
apiKey: 'API_KEY',
parentId: 'veriff-root',
onSession: function(err, response) {
// received the response, verification can be started now
}
});
veriff.mount({
formLabel: {
givenName: 'First name',
lastName: 'Family name',
vendorData: 'Email'
},
submitBtnText: 'Get verified',
loadingText: 'Please wait...'
});
InContext Javascript SDK Integration
Use this if you would like to use incontext UI.
Install InContext JS SDK
npm install @veriff/incontext-sdk
Adding InContext JS SDK
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. createVeriffFrame()
returns an object that controls the modal.
Listening for events
Pass onEvent
callback function when initializing SDK
import { createVeriffFrame, MESSAGES } from '@veriff/incontext-sdk';
createVeriffFrame({
url,
onEvent: function(msg) {
switch(msg) {
case MESSAGES.CANCELED:
//
break;
}
}
})
msg
:STARTED
- session status changed to 'started'.CANCELED
- user closed the modal.FINISHED
- user finished verification flow.
Closing modal
const veriffFrame = createVeriffFrame({ url: VERIFF_SESSION_URL });
veriffFrame.close();
Setting the user interface language
To set the language, pass lang
property when initialising SDK. Language should be ISO 639-1
code.
createVeriffFrame({
lang: 'et',
...
})
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 });
Adding Content Security Policy to JS SDK
add_header Content-Security-Policy default-src 'self' *.veriff.me;
script-src 'unsafe-inline' 'unsafe-eval' 'self' *.veriff.me *.google-analytics.com *.googletagmanager.com *.hotjar.com *.probity.io;
img-src blob: 'self' *.probity.io *.google-analytics.com;
frame-src 'self' *.hotjar.com;
connect-src 'self' *.veriff.me *.probity.io;
style-src 'self' *.veriff.me 'unsafe-inline';
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.
SDK Support Policy
Support Policy for Veriff SDKs
Identity verification software, practices, and regulations move fast. To keep our software user-friendly, and maintain high conversion rates for our clients, our development team needs to be faster. To delvier an increasingly smarter, better and safer product, it's important to ditch backward compatibility layers and update SDKs at least once every three months. Our SDKs are updated every two weeks, and downloading new releases will keep your verification process smooth and error-free. All releases are fully tested by our team and before being deployed, and come with the support from our team in the form of:
SDK support for 6 months after release, including:
- Fixing all reported bugs in the upcoming SDK release
- Fixing critical bugs in any final version before a major release for three months
- In case an SDK release requires major implementation efforts, then the old version will be supported for one year
Notifications before major changes to SDK support such as:
- Dropping support for an SDK version, where we will inform you via email one month in advance
- The end of the one-month grace period, after which Veriff will block future use of a specified SDK version
- When end-users engage with outdated SDKs, they will receive a prompt to upgrade the host application
SDK release versioning To help you keep track of SDK releases, Veriff uses three numbers to represent the scale of the updates. Each release is assigned either X, Y, or Z according to the following descriptions:
- Major Release (X) - These releases may require addtional development efforts, and often come with large-scale improvements to the SDK
- Minor Release (Y) - These do not come with any mandatory development efforts on your end, but may include new functionalities that require development efforts to be activated
- Bug-fix Release (Z) - These resolve issues from the previous release and do not introduce any new features or improvements
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
Also see our support article for getting the desired test verification result
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 (Decision endpoint)
- Abandoned (Decision endpoint)
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/)
- Download and install Node.js
- Download and extract js-integration-demo-master.zip
- Open Command (Windows) or Terminal (Mac) on your local computer.
- Navigate to js-integration-demo-master folder
cd C:\Users\User\Desktop\Veriff API).
- Run command >npm install
- 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.
const API_TOKEN = process.env.API_TOKEN || 'Your-api-key';
const API_SECRET = process.env.API_SECRET || 'Your-api-token';
const API_URL = process.env.API_URL || 'https://api.staging.vrff.io/v1';
const WEBHOOK_PORT = process.env.WEBHOOK_PORT || 3002;
const IMAGE_DIR = process.env.IMAGE_DIR || 'documents'
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.
Batch testing
Batch upload tests are sometimes agreed with our onboarding team and are very use case specific. Therefore below might be not applicable for most of the clients. For batch tests customers will need to prepare dataset that will be used for testing. If you have been asked for dataset please see batch test data preparetion guide.
End-User In The Flow
Session Status Diagram
API Reference
Backwards compatible changes
Following changes are considered to be backwards compatible by Veriff:
- Adding new properties to existing API responses;
- Changing the order of properties in existing API responses;
- Adding new API resources;
- Adding new optional request parameters to existing API methods;
- Changing the length or format of opaque strings, such as error messages, object IDs, etc;
- Adding new event types to Webhooks;
- Webhook listener should gracefully handle unfamiliar event types;
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://stationapi.veriff.com/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 in return, recieves a unique sessionToken that is related to the client.
You can find the sample implementation for Javascript.
https://github.com/Veriff/js-integration-demo
The URIs have the following structure:
https://<Base-URL>/v1/
For example, https://your-veriff-baseUrl/v1/sessions/
Note: to get Base URL choose Integrations in the top menu of Veriff Station, then integration you need.
Available endpoints and methods:
/sessions
Request Properties explained:
verification
:object (required)
Verification objectcallback
:String
- default is defined on settings - Callback url to which the client is redirected after the verification session is completedperson
:object
- Person to be verifiedfirstName
:String
- First namelastName
:String
- Last nameidNumber
:String
- National identification numbergender
:String
- Gender
document
:object
- Document of a person to be verifiednumber
:String
- Document numbercountry
:ISO-2
- String Issuing country of the documenttype
:PASSPORT
- (PASSPORT, ID_CARD, DRIVERS_LICENSE, RESIDENCE_PERMIT) Document type
additionalData
:object (This field is deprecated , not actively used by Veriff)
- Data from the filled application. JSON object should not have any nested objects it’s just simple key value pairvendorData
:string
- Vendor specific data string, max 400 characters long, will be sent back unmodified using webhookslang
:String
- Language of end user flow. ISO 639-1 codes are being used.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)
Note: lang
: String
- The language of end user verification flow. In case it is sent with API we try to display flow in the predefined language. In case the value is not defined we try to detect browser/device language for flow. In case we do not have translation to defined language we default back to EN.
Request method: POST
Media type: application/json
Type: object
Headers
X-AUTH-CLIENT: string (required)
- API Key
Content-Type: application/json
Function to calculate X-Signature in Python samples
Python3
import hashlib
def generateSignature(payload, secret):
sha_signature = \
hashlib.sha256(f'{payload}{secret}'.encode()).hexdigest()
return sha_signature
Sample Request
curl
curl -X POST \
--url '/v1/sessions/' \
-H 'Content-Type: application/json' \
-H 'X-AUTH-CLIENT: Your-API-KEY' \
-d '{
"verification": {
"callback": "https://veriff.com",
"person": {
"firstName": "John",
"lastName": "Smith",
"idNumber": "123456789"
},
"document": {
"number": "B01234567",
"type": "PASSPORT",
"country": "EE"
},
"vendorData": "11111111",
"lang": "en",
"timestamp": "2016-05-19T08:30:25.597Z"
}
}'
Node.js
var request = require("request");
var options = { method: 'POST',
url: '/v1/sessions/',
headers:
{ 'Content-Type': 'application/json',
'X-AUTH-CLIENT': 'Your-api-key' },
body:
{ verification:
{ callback: 'https://veriff.com',
person:
{ firstName: 'John',
lastName: 'Smith',
idNumber: '123456789' },
document: { number: 'B01234567', type: 'PASSPORT', country: 'EE' },
vendorData: '11111111',
lang: 'en',
timestamp: '2016-05-19T08:30:25.597Z' } },
json: true };
request(options, function (error, response, body) {
if (error) throw new Error(error);
console.log(body);
});
Python3
import requests
import pprint
import json
API_SECRET = 'Your-api-secret'
url = '/v1/sessions/'
payload = json.dumps({
'verification': {
'callback': 'https://veriff.com',
'person': {
'firstName': 'John',
'lastName': 'Smith',
'idNumber': '123456789'
},
'document': {
'number': 'B01234567',
'type': 'PASSPORT',
'country': 'EE'
},
'vendorData': '11111111',
'lang': 'en',
'features': [
'selfid'
],
'timestamp': '2016-05-19T08:30:25.597Z'
}
})
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(payload, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request('POST', url, data=payload, headers=headers)
pprint.pprint(response.json())
Response
Response Properties explained:
status
:String
Request statusverification
:object
Verification objectid
:UUID
-v4 String UUID v4 which identifies the verification sessionurl
:String
URL of the verification to which the person is redirected (Combination of the baseUrl and sessionToken)sessionToken
:String
Session specific token of the verificationbaseUrl
:String
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://alchemy.veriff.com/v/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdXRoX3Rva2VuIjoiOThiYzdjMjEtZTQ0Yy00MTZiLTkxOTMtMTU5ZGZkMzBmMDg4Iiwic2Vzc2lvbl9pZCI6Ijc2ODhmMzYzLTAyZjctNDE1My1iMzM1LWE0ODQ3OTRkMzZmNyIsImlhdCI6MTUwMTIyODI1MSwiZXhwIjoxNTAxODMzMDUxfQ.bMEF37E6-zT2Aa6Q8UXK3B_ZL51w6D_lxnGgQvhj214",
"sessionToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdXRoX3Rva2VuIjoiOThiYzdjMjEtZTQ0Yy00MTZiLTkxOTMtMTU5ZGZkMzBmMDg4Iiwic2Vzc2lvbl9pZCI6Ijc2ODhmMzYzLTAyZjctNDE1My1iMzM1LWE0ODQ3OTRkMzZmNyIsImlhdCI6MTUwMTIyODI1MSwiZXhwIjoxNTAxODMzMDUxfQ.bMEF37E6-zT2Aa6Q8UXK3B_ZL51w6D_lxnGgQvhj214",
"baseUrl": "https://alchemy.veriff.com"
}
}
/sessions/{sessionId}
Method to change the status of the verification.
Request properties explained:
verification
:object
(required)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 \
--url '/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",
"timestamp": "2019-10-29T06:30:25.597Z"
}
}'
Node.js
var request = require("request");
var options = { method: 'PATCH',
url: '/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',
timestamp: '2019-10-29T06:30:25.597Z' } },
json: true };
request(options, function (error, response, body) {
if (error) throw new Error(error);
console.log(body);
});
Python3.py
import requests
import json
import pprint
API_SECRET = 'Your-api-secret'
url = '/v1/sessions/{sessionId}'
payload = json.dumps({
'verification': {
'status': 'submitted',
'timestamp': '2019-10-29T06:30:25.597Z'
}
})
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(payload, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request('PATCH', url, data=payload, headers=headers)
pprint.pprint(response.json())
Response
Response properties explained:
status
:String
Request statusverification
:object
Verification objectid
:UUID-v4
String UUID v4 which identifies the imageurl
:String
URL for the timestamphost
:String
Host URIstatus
:String
Status of the verificationsessionToken
:String
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://alchemy.veriff.com/v/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX2lkIjoiZmQ1YzE1NjMtMWQyMy00YjFhLWFlNDYtN2JhNDI5OTI3ZWQ4IiwiaWF0IjoxNTcyMzM4MDIwfQ.3HbNq0YWKAfFrH-P658_WXMwcUMubyC1aXAMo-umfCU",
"vendorData": "11111111",
"host": "https://alchemy.veriff.com",
"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 \
--url '/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: '/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);
});
Python3.py
import requests
import json
import pprint
API_SECRET = 'Your-api-secret'
SESSION_ID= 'Your-session-id'
url = '/v1/sessions/{sessionId}/media'
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(SESSION_ID, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request('GET', url, headers=headers)
pprint.pprint(response.json())
Response
Response Properties explained:
status
:String
Status of the requestvideos
:object
Array of JSON objects identifying the videoscontext
:String
Type of a video (selfid_video|face-pre-video|document-front-pre-video|document-back-pre-video|document-and-face-pre-video|document-back-barcode-pre-video)id
:UUID
-v4 Video Idname
:String
Video nameduration
:String
Video duration in secondsurl
:String
Video download urlsize
:String
Video size in bytestimestamp
:object
Timestamp object, deprecated, will return null/None
images
:object
Array of JSON objects identifying the imagescontext
:String
Type of an image (face|face-pre|face-nfc|document-back|document-back-pre|document-front|document-front-pre|document-and-face|document-and-face-pre)id
:UUID
-v4 Image Idname
:String
Image nameurl
:String
Image download urlsize
:String
Image size in bytestimestamp
:object
Timestamp object, deprecated, will return null/None
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": [
{
"context": {VIDEO_TYPE},
"duration": "{DURATION_IN_SECONDS}",
"id": "{MEDIA_ID}",
"mimetype": "{MEDIA_MIME_TYPE}",
"name": "{VIDEO_NAME}",
"sessionId": "{SESSIOND_ID}",
"size": "{SIZE_IN_B}",
"timestamp": null(deprecated),
"url": "{MEDIA_DOWNLOAD_URL}"
}
],
"images": [
{
"context": {IMAGE_TYPE},
"id": "{MEDIA_ID}",
"name": "{IMAGE_NAME}",
"url": "{MEDIA_DOWNLOAD_URL}",
"sessionId": "{SESSIOND_ID}",
"timestamp": null(deprecated),
"size": "{SIZE_IN_B}",
"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 \
--url '/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: '/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);
});
Python3.py
import requests
import json
import pprint
url='/v1/sessions/{sessionId}/media'
payload = json.dumps({
'image': {
'context': 'document-front',
'content': 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA+.../9fgAEAKcxisFjVfn0AAAAASUVORK5CYII=',
'timestamp': '2019-10-29T06:30:25.597Z'
}
})
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(payload, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request('POST', url, data=payload, headers=headers)
pprint.pprint(response.json())
Response:
Response properties explained:
status
:String
Request statusimage
:object
Image objectcontext
:String
Type of an imageid
:UUID-v4
String UUID v4 which identifies the imagename
:String
File name that identifies the imagetimestamp
:Object
Timestamp object, deprecated, will return null/Nonesize
:Integer
Size for the imagemimetype
:String
Type for the imageurl
:String
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":{
"context": "document-back",
"id": "39388f8d-c6d6-4e9b-92c6-6978b2e8d664",
"name": "document-back",
"timestamp": null,
"size": 52268,
"mimetype": "image/png",
"url": "/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 \
--url '/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: '/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);
});
Python3.py
import requests
import json
import pprint
API_SECRET = 'Your-api-secret'
SESSION_ID= 'Your-session-id'
url = '/v1/sessions/{sessionId}/person'
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(SESSION_ID, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request('GET', url, headers=headers)
pprint.pprint(response.json())
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, place of birth",
"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}/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 \
--url '/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: '/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);
});
Python3.py
import requests
import json
import pprint
API_SECRET = 'Your-api-secret'
SESSION_ID= 'Your-session-id'
url = '/v1/sessions/{sessionId}/attempts'
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(SESSION_ID, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request('GET', url, headers=headers)
pprint.pprint(response.json())
Response
Response properties explained:
status
:String
Status of the requestverifications
:object
Array of JSON objects identifying the attemptsid
:UUID
-v4` attempt Idstatus
:String
status of the attempt. It can be one ofcreated
,started
,abandoned
,expired
,submitted
,approved
,resubmission_requested
,declined
,inflow_completed
,review
.
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"
}
]
}
/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 \
--url '/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: '/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);
});
Python3.py
import requests
import json
import pprint
API_SECRET = 'Your-api-secret'
ATTEMPT_ID= 'attemptId'
url = '/v1/attempts/{attemptId}/media'
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(ATTEMPT_ID, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request('GET', url, headers=headers)
pprint.pprint(response.json())
Response
Get the media with attemptId = {attemptId}
Response Properties explained:
status
:String
Status of the requestvideos
:Object
Array of JSON objects identifying the videoscontext
:String
Type of a video (selfid_video|face-pre-video|document-front-pre-video|document-back-pre-video|document-and-face-pre-video|document-back-barcode-pre-video)id
:UUID
-v4 Video Idname
:String
Video nameduration
:String
Video duration in secondsurl
:String
Video download urlsize
:String
Video size in bytestimestamp
:object
Timestamp object, deprecated, will return null/None
images
:Object
Array of JSON objects identifying the imagescontext
:String
Type of an image (face|face-pre|face-nfc|document-back|document-back-pre|document-front|document-front-pre|document-and-face|document-and-face-pre)id
:UUID-v4
Image Idname
:String
Image nameurl
:String
Image download urlsize
:String
Image size in bytestimestamp
:object
Timestamp object, deprecated, will return null/None
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": [
{
"context": "{VIDEO_TYPE}",
"id": "{MEDIA_ID}",
"name": "{VIDEO_NAME}",
"duration": "{DURATION_IN_SECONDS}",
"url": "{MEDIA_DOWNLOAD_URL}",
"timestamp": "null",
"size": "{SIZE_IN_B}",
"mimetype": "{MEDIA_MIME_TYPE}"
}
],
"images": [
{
"context": "{IMAGE_TYPE}",
"id": "{MEDIA_ID}",
"name": "{IMAGE_NAME}",
"url": "{MEDIA_DOWNLOAD_URL}",
"timestamp": "null",
"size": "{SIZE_IN_B}",
"mimetype": "{MEDIA_MIME_TYPE}"
}
]
}
/sessions/{sessionId}/decision
Get the session decision with sessionId = {sessionId}
Note: to have verification object filled, it is necessary to have a webhook url configured for the integration which sessionId is linked with.
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);
});
Python3.py
import requests
import json
import pprint
API_SECRET = 'Your-api-secret'
SESSION_ID= 'Your-session-id'
url = 'https://api.veriff.me/v1/sessions/{sessionId}/decision'
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(SESSION_ID, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request("GET", url, headers=headers)
pprint.pprint(response.json())
Response
Get the session decision with sessionId = {sessionId}
Response Properties explained:
status
:String
Status of the responseverification
:object
Verification request decision object. Null if decision is not available yetid
:String
UUID v4 which identifies the verification sessioncode
:9001
(one of 9001, 9102, 9103, 9104) Verification response code. Detailed meaning of the response codes:
Code Meaning 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 gets expired. If the client started the verification process we reply - "abandoned", otherwise, if the client never comes back to the verification, the status will be "expired". person
:object
Verified personfirstName
:String
First namelastName
:String
Last nameidNumber
:String
Identification numbercitizenship
:ISO-2
String CitizenshipdateOfBirth
:String
(YYYY-MM-DD) Date of birthgender
:String
(M, F or Null) Gender
reason
:String
Reason of failed Verificationstatus
:approved
(one of approved, resubmission_requested, declined, expired, abandoned) Verification statuscomments
:object
Array of additional comments by verification specialisttype
:String
The type of the commentcomment
:String
The comment itselftimestamp
:String
UTC timestamp
document
:object
Verified documentnumber
:String
Document numbertype
:String
(one of PASSPORT, ID_CARD, DRIVERS_LICENSE, RESIDENCE_PERMIT) Document typecountry
:ISO-2
String Document countryvalidFrom
:String
Document is valid from date
validUntil
:String
Document is valid undit datehighRisk
:bool
if session is considered high risk or notriskLabels
:array
Optional array of risk labels related to the session. The presence of this property depends on risk labels being enabled for the integrationlabel
:String
name of the risk labelcategory
:String
(one of client_data_mismatch, crosslinks, device, document, images, network, session, person)
vendorData
:String
- Vendor specific data stringdecisionTime
:String
Combined ISO 8601 date and time in UTC YYYY-MM-DDTHH:MM:S+Timezone OffsetacceptanceTime
:String
Combined ISO 8601 date and time in UTC YYYY-MM-DDTHH:MM:S+Timezone OffsetadditionalVerifiedData
:object
Data which has been optionally verified for session.driversLicenseCategory
:object
Optional, depending on integration.B
:boolean | null
technicalData
:object
Technical data objectip
: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
/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 \
--url '/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: '/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);
});
Python3.py
import requests
API_SECRET = 'Your-api-secret'
MEDIA_ID= 'mediaId'
url = '/v1/media/{mediaId}'
headers = {
'X-AUTH-CLIENT': 'Your-api-key',
'X-SIGNATURE': generateSignature(MEDIA_ID, API_SECRET),
'Content-Type': 'application/json'
}
response = requests.request('GET', url, headers=headers)
print(response.content)
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
Sample chunked data handling /media/{mediaId}
Sample how to store response data to file (image or video)
Headers
X-AUTH-CLIENT: string (required)
- API Key
X-SIGNATURE: string (required)
- Media data signed by API Secret.
Media ID: string (required)
- Media ID which can be parsed from /media response by session or attempt
Node.js
Here is a simple example how to download media with Node.js , it is applicable for both video and image files . Just make sure to use correct file extention which can be found from /media api response
const fs = require('fs');
const request = require("request");
const mediaId = 'Your-media-Id';
var options = { method: 'GET',
url: '/v1/media/'+mediaId,
headers:
{ 'Content-Type': 'application/json',
'X-SIGNATURE': 'Calculate sha256 hash with mediaID + YOUR_API_SECRET',
'X-AUTH-CLIENT': 'YOUR_API_KEY' } };
request(options, function (error, response, body) {
if (error) throw new Error(error);
}).pipe(fs.createWriteStream(__dirname+"/myMedia.jpeg"));
Python3.py
def generateSignature(payload, secret):
sha_signature = \
hashlib.sha256(f"{payload}{secret}".encode()).hexdigest()
return sha_signature
Video files sample
media_id = '05cfc122-15d8-4838-bbf1-7b26a736b2d2'
media_url = f'/v1/media/{media_id}'
headers = {
"X-AUTH-CLIENT": API_KEY,
"X-SIGNATURE": generateSignature(media_id, API_SECRET),
"Content-Type": "application/json",
}
response = requests.get(media_url, headers=headers)
with open('media_filename.webm', "wb") as media_file:
for chunk in response.iter_content():
media_file.write(chunk)
Image files sample
media_id = '2b3b3a9f-d73d-445a-aabe-9b41c1c1a2ac'
media_url = f'/v1/{media_id}'
headers = {
"X-AUTH-CLIENT": API_KEY,
"X-SIGNATURE": generateSignature(media_id, API_SECRET),
"Content-Type": "application/json",
}
response = requests.get(media_url, headers=headers)
with open("image_file_name.jpg", "wb") as write_file:
write_file.write(response.content)
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);
Python3
import hashlib
import json
#Globals
API_KEY = 'Your-api-key'
API_SECRET = 'Your-api-secret'
payload=json.dumps({'my precious data':'goes here'})
def generateSignature(payload, secret):
sha_signature = \
hashlib.sha256(f'{payload}{secret}'.encode()).hexdigest()
return sha_signature
print(generateSignature(payload, API_SECRET))
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 Keep in mind that if you stringify payload body then you will need to sign stringified payload at hash calculation step as well.
{
"verification": {
"callback": "https://veriff.com",
"person": {
"firstName": "John",
"lastName": "Smith",
"idNumber": "1234567890"
},
"document": {
"number": "B01234567",
"type": "PASSPORT",
"country": "EE"
},
"vendorData": "11111111",
"lang": "en",
"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.com",
"person": {
"firstName": "John",
"lastName": "Smith",
"idNumber": "1234567890"
},
"document": {
"number": "B01234567",
"type": "PASSPORT",
"country": "EE"
},
"vendorData": "11111111",
"lang": "en",
"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: 4f6a803b432dae66340ea7aba816527f0ccac2e8956c3f3db37510eca1177941
X-Signature included to your request headers is above hash:
Headers
Content-Type: application/json
X-AUTH-CLIENT: Your-API-Key
X-SIGNATURE: fae37e40c27875f52f944a39d37540d6d32ab4c39bf004c5e107925e44c7c05a
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 'https://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":"Smith","firstName":"John","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: 6b57df1c1284d3bcc24bd49bbac0da323c2380b7d6bcdc1f3d886f6b2ed32a88
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://alchemy.veriff.com/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: 6b57df1c1284d3bcc24bd49bbac0da323c2380b7d6bcdc1f3d886f6b2ed32a88
SHA-256 hash: 6b57df1c1284d3bcc24bd49bbac0da323c2380b7d6bcdc1f3d886f6b2ed32a88
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
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": "Entry not found." }` |
500 | `{ "status": "fail", "message": "Something went wrong." }` |
Crendentials & Authorization | |
1801 | `Mandatory X-AUTH-CLIENT header containing the API key is missing from the request.` |
1802 | `API key is not a valid UUID.` |
1803 | `Integration with the API key was not found.` |
1804 | `Integration with the API key is not active.` |
1811 | `Mandatory X-SIGNATURE header containing the SHA256 hash is missing from the request.` |
1812 | `Signature is not a valid SHA256 hash.` |
1813 | `Signature does not match the SHA256 hash of query ID and integration API secret.` |
1814 | `Signature does not match the SHA256 hash of request body and integration API secret.` |
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. |
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. |
1203 | Invalid ISO 8601 date. Date needs to be in format YYYY-MM-DD. |
1301 | Requested features are not supported. |
1302 | Only HTTPS return URLs are allowed. |
1303 | Invalid status. |
1304 | Cannot transition to "$STATUS" status. |
1400 | Image data not found. |
1401 | Image is not in valid base64. |
1402 | Image context is not supported. |
1403 | Image property is missing. |
1500 | Vendor data cannot be more than 400 symbols. |
1501 | Vendor data must be a string. |
2003 | Date of birth is not a valid date. |
2101 | Document number has to be between 6 and 9 characters. |
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 | |
Decline | 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. |
105 | Suspicious behaviour. |
106 | Known fraud. |
107 | Velocity/abuse. (Deprecated) |
108 | Velocity/abuse duplicated user. |
109 | Velocity/abuse duplicated device. |
110 | Velocity/abuse duplicated ID. |
Resubmit | 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. |
Decision | verification.code |
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 gets 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" |
Veriff Assisted Image Capture API
Process overview
- Generate session. Check
/sessions
endpoint in the API reference here to learn how to generate one. - Upload media
- Wait for response
- Patch session to inflow_completed
Upload media
Upload media for a specific verification session and receive inflow feedback
URL
/sessions/{sessionId}/media
Method
POST
URI Parameters
sessionId: string (required)
- Session uuid
Headers
Content-Type: application/json
X-AUTH-CLIENT: string (required)
- API Key
X-SIGNATURE: string (required)
- Payload signed with API Secret.
Request Properties
image
:object (required)
context
:string (required)
information about the media being uploaded. Possible options aredocument-front
,document-back
,face
,document-and-face
content
:string (required)
base64 encoded image (png|jpg|jpeg)timestamp
:string (required)
timestamp of when the photo was takeninflowFeedback
:boolean (optional)
if true, we wait up to 4 seconds to respond with feedback
Example request body
{
"image": {
"content": "/9j/4AAQSkZJRgABAQEBLAEsAAD/4R...",
"context": "document-back",
"timestamp": "2019-10-16T10:19:48.445Z",
"inflowFeedback": true
}
}
RESPONSE
Inflow feedback passed Happens when no issues were found with the image
Code
: 200 OK
{
"status": "success",
"image": {
"id": "be660c8f-3fc4-49aa-8051-ac042f07d6c7",
"name": "document-back",
"context": "document-back",
"timestamp": {
"url": "https://stationapi.veriff.com/v1/timestamps/b65b3628-232c-424a-9277-f3b84b568e82",
"id": "b65b3628-232c-424a-9277-f3b84b568e82"
},
"size": 35406,
"mimetype": "image/jpeg",
"url": "https://stationapi.veriff.com/v1/media/be660c8f-3fc4-49aa-8051-ac042f07d6c7",
"sessionId": "7c66bb47-b071-451f-a55b-66a8d125470f",
"inflowFeedback": {
"combined": {
"result": true
},
"reasons": []
}
}
}
Inflow feedback rejected Happens when some issues were found with the image
Code
: 200 OK
{
"status": "success",
"image": {
"id": "be660c8f-3fc4-49aa-8051-ac042f07d6c7",
"name": "document-back",
"context": "document-back",
"timestamp": {
"url": "https://stationapi.veriff.com/v1/timestamps/b65b3628-232c-424a-9277-f3b84b568e82",
"id": "b65b3628-232c-424a-9277-f3b84b568e82"
},
"size": 35406,
"mimetype": "image/jpeg",
"url": "https://stationapi.veriff.com/v1/media/be660c8f-3fc4-49aa-8051-ac042f07d6c7",
"sessionId": "7c66bb47-b071-451f-a55b-66a8d125470f",
"inflowFeedback": {
"combined": {
"result": false
},
"reasons": [
{
"name": "document_data_readable",
"result": false
},
{
"name": "document_found",
"result": false
},
{
"name": "document_valid_position",
"result": false
}
]
}
}
}
Inflow feedback timeout Happens when we’re not able to give feedback in time
Code
: 200 OK
{
"status": "success",
"image": {
"id": "be660c8f-3fc4-49aa-8051-ac042f07d6c7",
"name": "document-back",
"context": "document-back",
"timestamp": {
"url": "https://stationapi.veriff.com/v1/timestamps/b65b3628-232c-424a-9277-f3b84b568e82",
"id": "b65b3628-232c-424a-9277-f3b84b568e82"
},
"size": 35406,
"mimetype": "image/jpeg",
"url": "https://stationapi.veriff.com/v1/media/be660c8f-3fc4-49aa-8051-ac042f07d6c7",
"sessionId": "7c66bb47-b071-451f-a55b-66a8d125470f",
"inflowFeedback": null
}
}
List of feedbacks
Priority | Suggested user guidance | Reason identifier | Image type |
---|---|---|---|
1 | Photo is too dark. Please take a brighter photo to continue. | image_not_too_dark | Any |
2 | No ID card/driver's license/residence permit/passport detected. Please check if your card/driver's license/residence permit/passport is valid and in the photo | document_found | Document |
3 | ID card/driver's license/residence permit/passport is too small. Try bringing your ID card closer to the camera. | document_valid_size | Document |
4 | Make sure your ID card/driver's license/residence permit/passport photo page fits fully in the frame. | document_valid_position | Document |
5 | Please use a valid and supported identification document. These include ID cards, passports, residence permits, or driver's licenses. | document_valid_type | Document |
6 | Monochrome photo. Please take a color photo of your original ID card/driver's license/residence permit/passport to continue. | document_photocopy_not_monochrome | Document |
7 | Your ID card/driver's license/residence permit/passport appears to be a photocopy. Please use the original to continue. | document_photocopy | Document |
8 | Take a photo of the front of your ID card/driver's license/residence permit. | document_front_shown | Document front |
9 | Take a photo of the back of your ID card/driver's license/residence permit. | document_back_shown | Document back |
10 | Camera glare detected. Try moving away from direct light. | document_data_glare | Document |
11 | Document data is not readable. Please take a sharper photo to continue. / Make sure there is no not finger covering the data. | document_data_readable | Document |
12 | Make sure your face and ID card/driver's license/residence permit/passport photo page are fully in the frame when taking a photo. | document_face_shown | Face + Document |
13 | Make sure that your face is in the frame and clearly visible | face_found | Face |
14 | Multiple faces detected. Please make sure you are alone in the photo. | face_count | Face |
Patch the session
Patching session to inflow_completed
signals Veriff to leave the session alone. Check /sessions/{sessionId}
endpoint in the API reference here for more details.
Method
PATCH
URI Parameters
sessionId: string (required)
- Session uuid
Headers
Content-Type: application/json
X-AUTH-CLIENT: string (required)
- API Key
X-SIGNATURE: string (required)
- Payload signed with API Secret.
Request Properties
verification
:object
(required)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)
Example request body
{
"verification": {
"status": "inflow_completed",
"timestamp": "2019-09-03T08:36:25.597Z"
}
}
RESPONSE
Code
: 200 OK
{
"status": "success",
"verification": {
"id": "4bb7b3b1-986c-4134-af72-8683c532cfe2",
"url": "https://alchemy.veriff.com/v1/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX2lkIjoiNGJiN2IzYjEtOTg2Yy00MTM0LWFmNzItODY4M2M1MzJjZmUyIiwiaWF0IjoxNTcxNjU5ODgwfQ.0Z7ZmPM9sNOljt2IfOGisCJGqw4u5AywcpXASmunyo8",
"vendorData": "11111111",
"host": "https://alchemy.veriff.com",
"status": "completed",
"sessionToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzZXNzaW9uX2lkIjoiNGJiN2IzYjEtOTg2Yy00MTM0LWFmNzItODY4M2M1MzJjZmUyIiwiaWF0IjoxNTcxNjU5ODgwfQ.0Z7ZmPM9sNOljt2IfOGisCJGqw4u5AywcpXASmunyo8"
}
}
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). Determine the URL of the listener, also, take into account that Veriff doesn't allow custom ports to be added to the webhooks urls (neither on decisions nor on events). Once the URL is determined it can be configured in the Veriff Station under Integrations › Webhook Decision / Events URL. In case you want to test web hooks before the mobile app fully working, it is possible to manually generate verification session in Station 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 Station, Integrations -> Open the integration you want to configure -> Settings, and set 'Webhook decisions 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 every once in an hour 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 Station interface
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)
- you may also 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.
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, review)
- the Event Webhook Url is where we post events during the lifecycle of a verification (started, submitted)
- 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 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"
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.
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 verificaton 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",
"vendorData": "QWE123"
}
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 completed 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:50991b7ce6da52cf6c9a0d039f19f6f74340458ef697d9b2b98a10cace480f99' \
--header 'content-type:application/json' \
--data '{"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":"1967","placeOfBirth":"MADRID","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":{},"riskLabels":[{"label":"document_integration_level_crosslinked_with_fraud","category":"document"},{"label":"document_integration_level_crosslinked_with_multiple_declines","category":"document"}]},"technicalData":{"ip":"186.153.67.122"}}'
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": "1967",
"placeOfBirth": "MADRID",
"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": {
"driversLicenseCategory": {
"B": true
}
},
"riskLabels": [
{
"label": "document_integration_level_crosslinked_with_fraud",
"category": "document"
},
{
"label": "document_integration_level_crosslinked_with_multiple_declines",
"category": "document"
}]
},
"technicalData": {
"ip": "186.153.67.122"
}
}
Properties explained:
status
:String
(required) Status of the responseverification
:object
Verification request decision object. Null if decision is not available yet
id
:String
UUID v4 which identifies the verification sessionstatus
:approved
(one of approved, resubmission_requested, declined, expired, abandoned) Verification statuscode
:9001
(one of 9001, 9102, 9103, 9104) Verification response code. See Response and error codesreason
:String
Reason of failed Verificationperson
:object
Verified personfirstName
:String
First namelastName
:String
Last nameidNumber
:String
National Identification numbercitizenship
:(Deprecated)
ISO-2
String CitizenshipdateOfBirth
:String
(YYYY-MM-DD) Date of birthnationality
:String
NationalitypepSanctionMatch
:String
PEP check result. It is optional, depending on integration.gender
:String
(M, F or Null) GenderyearOfBirth
:String
(YYYY) Year of birthplaceOfBirth
:String
Place of birth
document
:object
Verified documentnumber
:String
Document numbertype
:String
(one of PASSPORT, ID_CARD, DRIVERS_LICENSE, RESIDENCE_PERMIT, OTHER) Document typecountry
:ISO-2
String Document countryvalidFrom
:String
Document is valid from date in YYYY-MM-DD formatvalidUntil
:String
Document is valid until date in YYYY-MM-DD format
comments
:object
(Deprecated)
Array of additional comments by verification specialisttype
:String
The type of the commentcomment
:String
The comment itselftimestamp
:String
UTC timestamp
additionalVerifiedData
:object
Data which has been optionally verified for session.driversLicenseCategory
:object
Optional, depending on integration.B
:boolean | null
vendorData
:object
Additional vendor specific data.reasonCode
:101
Physical document not used. See Response and error codesdecisionTime
:string
Timestamp of the decisionacceptanceTime
:string
Timestamp of the session generationriskLabels
:array
Optional array of risk labels related to the session. The presence of this property depends on risk labels being enabled for the integration.label
:String
name of the risk labelcategory
:String
(one of client_data_mismatch, crosslinks, device, document, images, network, session, person)
technicalData
:object
Technical data objectip
:String
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 two 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",
"attemptId": "e30122d1-740b-4764-853f-470374a7abf4",
"feature": "selfid",
"code": 7002,
"action": "submitted",
"vendorData": "QWE123"
}
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 refers to the end user flow) code: (one of 7001, 7002) (required) Event code vendorData: Vendor specific data string, max 400 characters long, set during session creation
For Full list of reason and response codes see documention Response and error codes
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": "Entry not found." }` |
500 | `{ "status": "fail", "message": "Something went wrong." }` |
Crendentials & Authorization | |
1801 | `Mandatory X-AUTH-CLIENT header containing the API key is missing from the request.` |
1802 | `API key is not a valid UUID.` |
1803 | `Integration with the API key was not found.` |
1804 | `Integration with the API key is not active.` |
1811 | `Mandatory X-SIGNATURE header containing the SHA256 hash is missing from the request.` |
1812 | `Signature is not a valid SHA256 hash.` |
1813 | `Signature does not match the SHA256 hash of query ID and integration API secret.` |
1814 | `Signature does not match the SHA256 hash of request body and integration API secret.` |
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. |
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. |
1203 | Invalid ISO 8601 date. Date needs to be in format YYYY-MM-DD. |
1301 | Requested features are not supported. |
1302 | Only HTTPS return URLs are allowed. |
1303 | Invalid status. |
1304 | Cannot transition to "$STATUS" status. |
1400 | Image data not found. |
1401 | Image is not in valid base64. |
1402 | Image context is not supported. |
1403 | Image property is missing. |
1500 | Vendor data cannot be more than 400 symbols. |
1501 | Vendor data must be a string. |
2003 | Date of birth is not a valid date. |
2101 | Document number has to be between 6 and 9 characters. |
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 | |
Decline | 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. |
105 | Suspicious behaviour. |
106 | Known fraud. |
107 | Velocity/abuse. (Deprecated) |
108 | Velocity/abuse duplicated user. |
109 | Velocity/abuse duplicated device. |
110 | Velocity/abuse duplicated ID. |
Resubmit | 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. |
Decision | verification.code |
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 gets 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" |