Fetches metadata about the transaction’s completed verifications. Includes data collected from user, the action based on dashboard configuration, any flags associated with the transaction, and more.
Requires an access_token bearer token for authentication in the Authorization header parameter: Authorization: Bearer <token>
API Library Usage
var transactionData = await client.fetchTransaction(transactionTokens)
$transactionData = $client->fetchTransaction($transactionTokens);
transaction_data = client.fetch_transaction(transaction_tokens)
transaction_data = client.fetch_transaction(transaction_tokens)
Transaction transactionData = client.fetchTransaction(Tokens tokens);
transactionData, err := client.FetchTransaction(transactionTokens)
Should I be consuming the flags exposed by Berbix through the API?
The Berbix API exposes the flags associated with transactions in the
flagsfield. This means that you can programmatically consume the flags associated with a transaction. However, we strongly recommend relying on theactionfield for making business decisions, and leveraging the action mapping functionality to map flags to actions. By leveraging the action mapping functionality, you'll be able to change your mappings without having to do any code change on your end!
Field Descriptions and Example Values
Included below are all possible field values that can be exposed via the API, their descriptions, and an example value.
New customers have access to the given_name, middle_name, family_name, id_type, id_issuer, email, and phone_number fields by default. Images are not included in our API responses by default. Additional fields can be added upon request if they are necessary for your use case. Please reach out to [email protected] if you'd like to get access to more fields or to images.
Even for the fields that you have access to, not all of them will be present for each transaction. Indeed, depending on the data on the ID itself and of whether or not Berbix was able to successfully extract data, certain fields might be missing. As an example, Berbix might return a middle_name that corresponds to an empty string when Berbix is able to determine that an end user does not have a middle name, but on the other hand, in the event that Berbix cannot determine whether the end user does have a middle name, that field would be entirely omitted ("middle_name": null).
Field Name | Description | Example Value |
|---|---|---|
| The city of the address collected in the flow. |
|
| The country of the address collected in the flow. |
|
| The postal code of the address collected in the flow. |
|
| The street address collected in the flow. |
|
| The subdivision of the address collected in the flow. |
|
| The unit of the address collected in the flow. |
|
| The age of the person completing the flow. |
|
| The date of birth of the person completing the flow. |
|
| The email address for the user if provided for creating a handoff. | |
| The family name (typically last) of the person completing the flow. |
|
| The given name (typically first) of the person completing the flow. |
|
| The expiry date of the ID collected in the flow. |
|
| The issue date of the ID collected in the flow. |
|
| The issuer of the ID collected in the flow. The subdivision code is provided if available such as a US DL and only the country code is populated for passports or national ID cards. The country codes are two-letter (ISO 3166-1 alpha-2) codes. |
|
| The ID number of the ID collected in the flow. |
|
| The type of ID collected. Possible values are |
|
| The middle name of the person completing the flow. |
|
| The nationality of the person completing the flow. Available when provided via national ID cards or passports. |
|
| The phone number of the user if provided for creating a handoff. |
|
| The sex of the person completing the flow. Possible values are |
|
Source Values
All verification fields include a source value to convey where the data was sourced from. fields.*.sources will be populated with at least one of the following values:
manual: sourced from data entered manually by the user when prompted to confirm or enter their basic details, or when creating a handoff. A verification with manual data entry will always have theid_manual_entryflag .mrz: sourced from a machine readable zone typically found on passports or other national ID cards.ocr: sourced from human readable components typically found on the front of identity documents through optical character recognition.pdf417: sourced from a PDF417 barcode typically found on the back of an AAMVA-compliant US or Canadian ID or DL.handoff: denotes aphone_numberoremailfor which a link has successfully been sent and clicked on.
Confidence Values
high: Data was sourced from a machine readable component or confirmed through some other high-confidence means (e.g. a handoff link being accessed).medium: Data was sourced from a human readable component.low: Data was provided manually by the user.