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 flags field. This means that you can programmatically consume the flags associated with a transaction. However, we strongly recommend relying on the action field 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

address_city

The city of the address collected in the flow.

SAN FRANCISCO

address_country

The country of the address collected in the flow.

USA

address_postal_code

The postal code of the address collected in the flow.

94114

address_street

The street address collected in the flow.

2338 MARKET ST

address_subdivision

The subdivision of the address collected in the flow.

CA

address_unit

The unit of the address collected in the flow.

2A

age

The age of the person completing the flow.

30

date_of_birth

The date of birth of the person completing the flow.

1989-12-12

email_address

The email address for the user if provided for creating a handoff.

[email protected]

family_name

The family name (typically last) of the person completing the flow.

DOE

given_name

The given name (typically first) of the person completing the flow.

JOHN

id_expiry_date

The expiry date of the ID collected in the flow.

2018-08-08

id_issue_date

The issue date of the ID collected in the flow.

2016-10-05

id_issuer

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.

US-CA

id_number

The ID number of the ID collected in the flow.

D999999

id_type

The type of ID collected. Possible values are ID, DL, P (passport), V (visa), PRC (permanent resident card), PC (passport card), or UNK (unknown).

DL

middle_name

The middle name of the person completing the flow.

RYAN

nationality

The nationality of the person completing the flow. Available when provided via national ID cards or passports.

US

phone_number

The phone number of the user if provided for creating a handoff.

+14155559999

sex

The sex of the person completing the flow. Possible values are M, F, or X (non-binary).

M

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 the id_manual_entry flag .
  • 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 a phone_number or email for 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.
Language
Authentication
Header
Click Try It! to start a request and see the response here!