Berbix Docs

Welcome to the Berbix docs! Here you’ll find comprehensive information for integrating Berbix Verify and its associated APIs as well as an overview of Berbix Dashboard functionality.

The fastest way to integrate Berbix Verify is to follow our Integration Guide, which walks through your entire Berbix integration step-by-step. You’ll integrate Berbix Verify into your site or app and then use one of our SDKs to retrieve the data you need from our API. You'll also be guided through the configuration of verification workflow rules to map to your existing business logic.

You can see the full Berbix Verify API specification in our API Reference Docs and find functional documentation for the Berbix Dashboard here.

If you have any questions, please don't hesitate to reach out to us at [email protected] or via your organization's shared Slack channel.

Docs & Guides    API Reference

Platform Overview

This document reviews key Berbix Verify concepts and describes how a sample application integration works holistically.

Key Concepts

The following Berbix concepts will be referenced throughout this guide:

  • Action Map: Actions are a way to customize the business logic associated with Berbix transactions and can be thought of as the "business decision" after a verification such as accept, reject, or review. Actions are included in the returned Transaction data and can be mapped to a Review Queue.
  • Templates: A template represents the configuration for a Berbix Verify flow including the types of verification you'd like to conduct (photo ID, selfie, etc.) and settings for the verification flow (number of attempts, timeouts, etc.).
  • Themes: Themes can be used to customize the look-and-feel of your Berbix Verify experience. Themes are associated with a template.
  • Transactions: Transactions are the core component of Berbix Verify and represent a user verification.
  • Review Queues: Review Queues contain new transactions that may require additional 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 Verify, it's helpful to understand how all of the key integration concepts fit together. We recommend reading the Verify Flow Overview to also understand how the application workflow relates to the end-user experience.

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.

Updated about a month ago

Platform Overview

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.