Glossary & Overview

This document defines the concepts you'll encounter in Berbix, and presents a sample end-to-end application workflow.

Key Concepts

The following Berbix concepts will be referenced throughout this guide:

  • Transactions: When your end-user verifies their identity, the end-to-end process is called a Transaction. The data captured in each transaction may be viewed individually in the Berbix dashboard, or may be retrieved programmatically via integration.
  • Transaction ID: The unique identifier we assign to a transaction when it is generated.
  • Customer UID: When you create transactions, we strongly recommend that you assign a unique identifier to the individual end-user. For best practices, check out our Frequently Asked Questions.
  • Templates: When you configure a Template, you are defining the steps your end-users will take to verify their identity. This may include selecting an allowed document type, uploading photos of the front and back of their ID, taking selfies, and more.
  • Action Map: An Action Map uses possible transaction flags to set business logic. When your end-users complete transactions, we use this logic to decide on an Action; accept, reject, or review.
  • Themes: Customize the look and feel of the end-user experience to match your branding with Themes.
  • Review Queues: Transactions that result in a review action are routed to Review Queues for manual verification.

Token Types

There are three token types associated with any given transaction within Berbix:

  • access_token: short-lived (one hour) token that enables your backend to fetch data about a given transaction.
  • client_token: short-lived (one hour) token that connects the Berbix frontend with a given transaction.
  • refresh_token: long-lived token that may be used to regenerate the other two tokens.

End-to-End Application Workflow

Before integrating Berbix, it's helpful to understand how all of the key integration concepts fit together.


The typical end-to-end application workflow is:

  1. An end-user in your application flow needs to perform some form of identity verification.
  2. Before initiating the verification flow, your application creates a new Berbix transaction associated with a customer_uid and template_key, which returns an associated access_token, refresh_token, and client_token.
  3. Your application stores the refresh_token alongside your user record, which is used to generate an access_token and client_tokens in future requests.
  4. Your application sends the generated client_token for the transaction to your frontend to initialize the Berbix flow.
  5. The end-user performs the selected form of identity verification and their details are sent directly to Berbix for validation.
  6. Upon completion, the Berbix frontend SDK triggers a successful callback hook or an error if verification is unsuccessful.
  7. Your application fetches the metadata for a successful verification using the transaction's access_token.
  8. Your backend sends the returned action to your client to determine the user experience.

To check out how this is experienced by the end-user, we recommend that you review the End-User Verification Flow.

© Berbix Inc. All rights reserved.