API v2 to v3.6 migration guide
Start here
The following guide is designed to help you migrate from Onfido API v2 to API v3.6. If you're migrating from API v3 to v3.6, please review our separate guide.
If you're updating to API v3.1 onwards and are currently using api.onfido.com
, you must now use the api.eu.onfido.com
base URL. You can read more about our supported regions.
Our versioning policy has changed for v3.6 onwards, you can read about in our versioning policy page.
You can also read about our supported API client libraries and which libraries support which versions of the API.
Skip to comprehensive tables for v2 -> v3 versions mappings for report names and endpoints.
If you have any difficulties migrating, please Onfido's Customer Support team.
Authentication
Authentication is exactly the same in all versions of our API. The sandbox and live environments are configured in the same way.
Read more about token authentication in our API reference.
Summary of differences
This section summarises the differences in API v3 versions compared to v2, which you should consider when migrating.
Applicant creation
In the request body when creating an applicant, the following fields no longer exist:
gender
telephone
mobile
country
(now solely withinaddress
)mothers_maiden_name
previous_last_name
nationality
country_of_birth
town_of_birth
addresses
(has becomeaddress
- read more in the following section of this guide)
An example of a valid API v3 version request body for creating an applicant:
1{2 "first_name": "Jane",3 "last_name": "Doe",4 "dob": "1990-01-31",5 "address": {6 "building_number": "100",7 "street": "Main Street",8 "town": "London",9 "postcode": "SW4 6EH",10 "country": "GBR"11 }12}
You can review the new form of the applicant object.
Applicant addresses
addresses
has become address
, and is now a single address rather than an
array of addresses. The country
field within address
is the only place you
need to provide information about an applicant's country of residence.
In API v3 versions, only a single address can be provided, not a list of past addresses.
"Applicant provides data" replaces standard checks
API v3 versions have no concept of "standard" and "express" checks.
If you previously used express checks in API v2, you no longer need to pass a
type
in check creation requests.
If you previously used standard checks to gather applicant information with
the applicant form, simply set
applicant_provides_data
to true
.
Asynchronous checks are the default
In API v3 versions, async
has changed to asynchronous
and is set to true
by
default. If set to false, report results in the check request response will
only be returned when all reports are complete. You can configure
webhooks to notify you when the
report is complete.
Check creation
There is new required applicant data for creating a check since API v3.4.
Location
We have introduced a new location
parameter in the applicant and documents resource for specifying the location of an applicant since API v3.4.
The location
parameter is mandatory for all applicants in order to create a check with a Facial Similarity report using API v3.4 onwards. If you do not provide it, all check requests will fail with a validation error.
Consent
We have introduced a new consents
parameter in the applicant resource.
The consents
parameter is mandatory for any applicant who is located in the US in order to create a check with Onfido using API v3.4 onwards. If you do not provide the consents parameter, and the location of the applicant is the US, all checks will fail with a validation error.
The privacy_notices_read_consent_given
parameter no longer exists in check creation.
You can read our Onfido privacy notices and consent migration guide for further guidance on how to update your integration to collect end user consent in API 3.6.
Client libraries
Please review our client libraries versioning guide to see which libraries support which versions of the API.
Default base URL for EU is now api.eu.onfido.com
You should use the api.eu.onfido.com
base URL if you're deployed in the EU region, which is now the API base URL in our documentation examples. You can read more about our supported regions.
Documents
Documents are no longer nested under the /applicants
resource. They're now
managed under /documents
.
Document IDs in Document and Facial Similarity reports
You can still specify which document to use as part of a Document report, and now also Facial Similarity reports, when creating a check. Simply use the document_ids
field when creating a check:
"document_ids": ["<DOCUMENT_ID>"]
If unspecified, the most recently uploaded document (or documents for a two-sided ID document) will be used.
Document uploads
The new endpoint is POST /documents/
and you should provide an applicant ID
in the request body to associate a document with an applicant.
Driving licence naming inconsistencies are fixed
In API v3, the spelling driving_licence
is used everywhere and there is no
inconsistency.
Facial Similarity score
The score
value is now returned in the properties
object under the new
face_match
sub-breakdown. You can read more in our API
documentation.
Identity reports
identity_enhanced
reports replace all Identity reports in API v3. They do
not support previous addresses.
PDF downloads
In API v2, a download_uri
string is returned in check response objects,
which is a link to a PDF output of the check results.
This is now available as an API v3.1 endpoint.
Report type groups
Report type groups do not exist in API v3 versions. Instead, we've simplified how to create a check. Read more in the section later in this guide on check creation.
Webhook event objects
The completed_at
timestamp in webhook event objects has been replaced by
completed_at_iso8601
(it now conforms to ISO
8601). For example:
1HTTP/1.1 201 Created2Content-Type: application/json34{5 "payload": {6 "resource_type": "report",7 "action": "report.completed",8 "object": {9 "id": "<REPORT_ID>",10 "status": "complete",11 "completed_at_iso8601": "2019-10-28T15:00:39Z",12 "href": "https://api.eu.onfido.com/v3/reports/<REPORT_ID>"13 }14 }15}
Checks in API v3 versions
Checks are no longer nested under the /applicants
resource. They're now
managed under /checks
.
Check creation
Check creation is designed to be much simpler in API v3 versions.
-
the new endpoint is
POST /checks/
-
we've removed the concept of variants and options (see the section 'Report names, options and package variants' later in this guide)
-
you now simply pass report names to the
report_names
array of strings -
an applicant ID is now required in the request body Example check creation (Document and Facial Similarity Photo reports)
Before (v2):
1POST /v2/applicants/<APPLICANT_ID>/checks HTTP/1.12Host: api.eu.onfido.com3Authorization: Token token=<YOUR_API_TOKEN>4Content-Type: application/json56{7 "type": "express",8 "reports": [9 {10 "name": "document"11 },12 {13 "name": "facial_similarity",14 "variant": "standard"15 }16 ]17}
Now (v3.6):
1POST /v3.6/checks HTTP/1.12Host: api.eu.onfido.com3Authorization: Token token=<YOUR_API_TOKEN>4Content-Type: application/json56{7 "applicant_id": "<APPLICANT_ID>",8 "report_names": [9 "document",10 "facial_similarity_photo"11 ]12}
Example check creation (Identity Enhanced report)
Before (v2):
1POST /v2/applicants/<APPLICANT_ID>/checks HTTP/1.12Host: api.eu.onfido.com3Authorization: Token token=<YOUR_API_TOKEN>4Content-Type: application/json56{7 "type": "express",8 "reports": [9 {10 "name": "identity",11 "variant": "kyc"12 }13 ]14}
Now (v3.6):
1POST /v3.6/checks HTTP/1.12Host: api.eu.onfido.com3Authorization: Token token=<YOUR_API_TOKEN>4Content-Type: application/json56{7 "applicant_id": "<APPLICANT_ID>",8 "report_names": [9 "identity_enhanced"10 ]11}
Example check creation (Watchlist Enhanced report)
Before (v2):
1POST /v2/applicants/<APPLICANT_ID>/checks HTTP/1.12Host: api.eu.onfido.com3Authorization: Token token=<YOUR_API_TOKEN>4Content-Type: application/json56{7 "type": "express",8 "reports": [9 {10 "name": "watchlist",11 "variant": "kyc"12 }13 ]14}
Now (v3.6):
1POST /v3.6/checks HTTP/1.12Host: api.eu.onfido.com3Authorization: Token token=<YOUR_API_TOKEN>4Content-Type: application/json56{7 "applicant_id": "<APPLICANT_ID>",8 "report_names": [9 "watchlist_enhanced"10 ]11}
Report names in API v3 versions
The concept of package variants and options for reports does not exist in API v3. The same functionality is achieved using more descriptive report names.
Report names: v2 → v3 versions mapping
You'll find a very similar table in our API reference documentation.
Report name (v2 terminology) | Report name in v3 |
---|---|
Document | document |
Document (options: document_address_information ) | document_with_address_information |
Document (options: driving_licence_information ) | document_with_driving_licence_information |
Facial Similarity (variant: standard ) | facial_similarity_photo |
Facial Similarity (variant: video ) | facial_similarity_video |
Known Faces | known_faces |
Identity (variant: kyc ) | identity_enhanced |
Watchlist (variant: kyc ) | watchlist_enhanced |
Watchlist (variant: aml ) | watchlist_aml |
Watchlist (variant: full ) | watchlist_standard |
Watchlist (options: peps ) | watchlist_peps_only |
Watchlist (options: sanctions ) | watchlist_sanctions_only |
Proof of Address | proof_of_address |
Endpoints: v2 → v3 versions mapping
The following table lists endpoint mappings from v2 to v3 in full. Any unlisted endpoints are unchanged:
Endpoint | v2/v3 comparison |
---|---|
Upload document | v2: POST /v2/applicants/{applicant_id}/documents/ |
v3: POST /v3.6/documents/ | |
Retrieve document | v2: GET /v2/applicants/{applicant_id}/documents/{document_id} |
v3: GET /v3.6/documents/{document_id} | |
List documents | v2: GET /v2/applicants/{applicant_id}/documents/ |
v3: GET /v3.6/documents?applicant_id=<APPLICANT_ID> | |
Download document | v2: GET /v2/applicants/{applicant_id}/documents/{document_id}/download |
v3: GET /v3.6/documents/{document_id}/download | |
Create check | v2: POST /v2/applicants/{applicant_id}/checks/ |
v3: POST /v3.6/checks/ | |
Retrieve check | v2: GET /v2/applicants/{applicant_id}/checks/{check_id} |
v3: GET /v3.6/checks/{check_id} | |
List checks | v2: GET /v2/applicants/{applicant_id}/checks/ |
v3: GET /v3.6/checks?applicant_id=<APPLICANT_ID> | |
Retrieve report | v2: GET /v2/checks/{check_id}/reports/{report_id} |
v3: GET /v3.6/reports/{report_id} | |
List reports | v2: GET /v2/checks/{check_id}/reports/ |
v3: GET /v3.6/reports?check_id=<CHECK_ID> | |
Resume report | v2: POST /v2/checks/{check_id}/reports/{report_id}/resume |
v3: POST /v3.6/reports/{report_id}/resume | |
Cancel report | v2: POST /v2/checks/{check_id}/reports/{report_id}/cancel |
v3: POST /v3.6/reports/{report_id}/cancel | |
OCR Autofill | v2: POST /v2/ocr/ |
v3: POST /v3.6/extractions | |
Retrieve RTG * | v2: GET /v2/report_type_groups/{report_type_group_id} |
v3: REMOVED | |
List RTGs * | v2: GET /v2/report_type_groups/ |
v3: REMOVED |
- RTG = Report type group