Tutorial: Brick PII

📘

The Brick Passport API returns all previously connected account data of your users by providing PII (Email and/or Phone Number)

Brick is currently offering two environments:

  • Sandbox, a sandbox environment with test data perfect for test and development phases.
  • Production, a live environment used in production with real connections to institutions.

To generate your keys for each environment, have a look to our guide to get your Brick API keys or Sign Up now!

You follow this tutorial along side a video tutorial we made for better understanding.

Step 1: Generate a JWT bearer token (Public access token)

Use your Sandbox API keys viz. a ClientID & ClientSecret with the generate public token api to get a JWT((JSON Web Token). This JWT or what we call a public access token can be used to launch the Brick widget and access institution list.

curl -u Client ID:Client Secret https://sandbox.onebrick.io/v1/auth/token
{
    "status": 200,
    "message": "OK",
    "data": {
        "access_token": "public-sandbox-b70bcf83-87a1-4f2c-8f2a-16d48021413a"
    }
}

Step 2: API Connection

Use the JWT/public-access-token to authenticate your user via connection to our API with these inputs in order to generate clientId and redirectRefId which will be used in the next step in order to generate user-access-token from your user's account

curl --location --request POST 'https://sandbox.onebrick.io/v1/account/pii' \
--header 'Authorization: Bearer public-access-token' \
--header 'Content-Type: application/json' \
--data-raw '{
    "consent_id": "Cons.ABC.123",
    "consent_method": "Mobile Application - Button Click",
    "email": "[email protected]",
    "phone_number": "08112211312"
}'
Key ParameterData TypeDescription
consent_idString[Mandatory] Partner generated consent identifier that is unique per user
consent_methodString[Mandatory] The consent method used to gather consent from user

Type of consent:
Physical Form - Signature
Web Application - Button Click
SMS - SMS Reply
Mobile Application - Button Click
Email - Email Reply
Voice Call - Voice Reply
Video Call - Video Reply

For example: if the consent is collected by Button Click in your Mobile Application, then please input "Mobile Application - Button Click" as the consent_method
emailStringEmail of the user
phone_numberStringPhone number of the users

If the API call is successful, you will receive the list of accounts along with the user-access-token which is associated to the user.

{
  "status": 200,
  "message": "OK",
  "data": [
    {
      "institution_id": 12,
      "institution_name": "OVO",
      "institution_type": "e-wallet",
      "username": "+6281260988123",
      "user_access_token": null,
      "status": "unverified"
    },
    {
      "institution_id": 33,
      "institution_name": "ShopeePay",
      "institution_type": "e-wallet",
      "username": "+6281260988123",
      "user_access_token": null,
      "status": "unverified"
    },
    {
      "institution_id": 17,
      "institution_name": "Livin' by Mandiri",
      "institution_type": "mobile banking",
      "username": "paseksujana",
      "user_access_token": "{access-token}",
      "status": "verified"
    }
  ]
}
Key ParameterData TypeDescription
institution_idIntegerThe identification of user's account institution
institution_nameStringThe name of user's account institution
institution_typeStringThe type of user's account institution
usernameStringThe username of user's account institution
user_access_tokenStringThe user access token of user's account.
(If null, then the account is not verified)
statusStringThe verification status of user's account
- "verified", means that the user access token can directly be used
- "unverified", means that a re-authentication is needed to get the user_access_token

There will be 2 scenarios of return parameter which can be determine from the "status" variable:

  1. If the "status" returns unverified, that means the account needs to be re-authenticated in order to get the "user_access_token" (e.g: accounts with Multi Factor Authentication that needs unique OTP for every authentication)
  2. If the "status" returns verified, that means the "user_access_token" can be directly used to retrieve the data of user

Please refer to the table below on how to move to the next steps after you received the list of previously connected accounts from user based on the "institution_type"