1 de 98

English

Welcome

Here you will find the technical information for the Unico IDCloud platform's REST APIs

Overview

Welcome to the Unico IDCloud platform REST API documentation! On this page, you'll find everything you need to know to enhance the security and quality of your applications using our REST API.

Learn more about

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our .

GETTING STARTED

Unico IDCloud

Learn all about our Unico IDCloud identity verification platform

What is the Unico IDCloud platform?

IDCloud is the only identity verification platform that combines security with guaranteed accuracy. It enables user identity validation through a simple and intuitive process using just a selfie, ensuring smooth and secure verification flows.

The platform is versatile and adaptable to various use cases, allowing customization based on your specific requirements. We offer a range of capabilities — features of our platform designed to support a wide variety of operations and needs. IDCloud can be integrated through two modes: and by Client.

For more information on our capabilities, visit the following page:

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Capabilities

In this section, you will find a description of all the capabilities of the Unico IDCloud platform

Below, you will find a detailed explanation of how each capability works:

Liveness

hen there is a need to verify that a person is real and alive at the time of the operation, this capability can be used either in isolation or in conjunction with the capabilities of Identity Verification, Behavior Alert, Risk Scoring, and Validation (1:1). It should always be used alongside the SDKs.

The possible responses are:

YES: indicates that the user is alive at the time of the selfie capture.
NO: indicates that the user is not alive at the time of the selfie capture.

Commonly referred to as IDLive or Smartlive/Liveness with Interaction.

Identity Verification

When there is a need to ensure that the user performing the process is who they claim to be, this capability is typically used in conjunction with the Liveness capability.

The possible responses are:

YES: indicates that the face matches the actual holder of the CPF (Cadastro de Pessoas Físicas).
NO: indicates that the face does not match the actual holder of the CPF.
INCONCLUSIVE: indicates that there is insufficient evidence to determine whether the face matches the actual holder of the CPF.

Commonly referred to as IDUnico.

Behavior Alert

Behavior Alert complements the Identity Verification response by adding a behavioral component that provides certainty regarding the risk associated with that identity, based on previous fraudulent behavior. It can only be used in conjunction with the Identity Verification capability.

The possible responses are:

YES: indicates that the face has been involved in fraudulent identity transactions.
INCONCLUSIVE: indicates that there is insufficient evidence to determine whether the face has been involved in fraudulent transactions in our database.

Commonly referred to as Trust or IDTrust.

Risk Score

The Risk Score capability is being discontinued and will only be available for exceptional cases. To verify your eligibility, please contact your account representative.

When there is a need to obtain a probability score regarding whether the user performing the process is who they claim to be, this capability can only be used in orchestration with the Identity Verification capability when its response is "INCONCLUSIVE".

The possible responses are:

Positive Score: can range from +10 to +100. The higher the score, the greater the probability that the face matches the actual holder of the CPF (Cadastro de Pessoas Físicas).
Zero Score: indicates that there is an error in the registration. A new capture is recommended.
Negative Score: can range from -10 to -100. The lower the score, the greater the probability that the face does not match the actual holder of the CPF.

Classification

Score

Recommendation

Negative

Between -40 and -100

We recommend denying the registration

Negative

Between -10 and -39

We recommend that the client assess the associated risks before making a decision

Neutral

Zero Score

We recommend denying the registration and asking the user to capture a new photo of the actual holder of the CPF

Positive

Between +10 and +49

We recommend that the client evaluate the risks involved in making a decision

Positive

Between +50 and +100

We recommend approving the registration

Commonly referred to as Check or Unico Check.

Validation (1:1)

When there is a need to recognize whether the person in the operation is the same one who completed the registration, this capability is typically used in conjunction with the Liveness. It can only be used in cases where an Identity Verification process has already been performed.

The possible responses are:

YES: indicates that the face performing the transaction is the same one that carried out the process used as reference;
NO: indicates that the face performing the transaction is not the same one that carried out the process used as reference.

Commonly referred to as Biometric Token or Transactional Token.

Document Capture and Reuse

When there is a need to request, store, and reuse documents, we offer the ability to leverage users' personal documents (Passport, CIN, RG, and CNH—both digital and physical), reducing friction. If we do not have the documents in our database, it is possible to capture them.

This capability can only be used in conjunction with the Identity Verification capability. For document validation, we use the following technologies:

Typification: indicates whether the provided document is valid or not.
OCR: involves extracting data from the document based on an image.
FaceMatch: involves comparing the face in the selfie with the face on the document.
CPF Match: involves searching for a specific CPF in the provided document.

Commonly referred to as IDDOCS.

Electronic Signature

When there is a need to use biometrics to sign a document, utilize the same method of user authentication throughout the journey to finalize the operation with the contract signature.

*The electronic signature capability is only available through the by Unico integration mode in flows that involve other capabilities. See more in the Possible Flows section.

Commonly referred to as SIGN or IDSIGN.

Serpro Similarity Return

The Serpro similarity return is not a native capability of IDCloud but rather an additional feature incorporated to comply with a regulation from Dataprev concerning INSS payroll credit operations aimed at retirees and pensioners.

Since these operations require the SERPRO similarity return, the IDCloud platform has been adjusted to include this functionality as an option in the product. When using the SERPRO similarity feature, the API response will be the score of similarity.

Commonly referred to as IDSerpro.

When Serpro finds the face, it returns a score from 0-100, as in the example below:

"government": {
        "serpro": 93.0
    }

When Serpro does not find the face, the score -1 is returned, as in the example below:

"government": {
        "serpro":-1
    }

When there is an error in the integration with Serpro, the score -2 is returned, as in the example below:

"government": {
        "serpro":-2
    }

To understand how you can use each of the capabilities, be sure to visit the "Integration Methods" section at the link below:

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Integration Methods

In this section, you will learn more about the integration methods of the Unico IDCloud platform

by Unico

For companies looking to partner with an expert to manage user experience with best practices and privacy, as well as ease in orchestrating flows with Unico's capabilities and automatic updates of technologies, such as SDKs.

With by Unico, you will have a team of security specialists and UX design best practices to ensure the best possible conversion in your operation. It can be used responsively on both Desktop and Mobile, offering the following usage options:

Channel

Redirect

Open.window()

iFrame

Webview

Mensagens

Desktop

Webmobile

App mobile

For the messaging flow, it is possible to send notifications through the channels of: WhatsApp, SMS, and Email.

Check out the end-user experience with by Unico in Messaging, Webview, and iFrame, respectively, in the tabs below:

by Client

For companies that want to control the user experience with their own frontend, as well as build flows with Unico's capabilities on the backend alongside other technologies and resources used for authentication,

with by Client, you have the freedom you need to create and manage the end-user journey as you see fit, leveraging the capabilities of the Unico IDCloud platform as needed.

Check out the experience of capturing the end user's selfie with by Client using Unico's SDKs:

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Capabilities and Integration Methods

In this section, you will find which capabilities are available for each integration method of the Unico IDCloud platform

To meet the diverse use cases of your operation, the capabilities of IDCloud have different availabilities based on the integration methods. Below, check the table with all the usage possibilities, categorized by integration method:

Capacidades

by Unico

by Client

Identity Verification

Risk Score

Behavior Alert

Liveness

Validation (1:1)

Document Capture and Reuse

Electronic Signature

In each integration method, it is possible to combine various capabilities with one another. To learn more about the possible flows for each integration method, refer to the "Overview" menus in their respective sections under "Integration."
For both integration methods, it is also possible to obtain the SERPRO similarity return.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

INTEGRATIONS

Quickstart

In this section, you will find an overview of how to integrate with the Unico IDCloud platform

Integration Overview

Authenticate

Regardless of the integration method you choose, the first step is . You must have a service account and perform OAuth2 authentication to obtain a valid access token.

Learn more in the section.

Define the Capabilities You Will Use

What capabilities do you need for your operation? Identity Verification? Liveness?

Understand the available on the Unico IDCloud platform and decide which ones you will utilize in your operation.

Learn more in the section.

Define Your Integration Method

Do you want the convenience of ? Or the freedom of?

Based on the you will use, define your integration method according to your operation and context.

Learn more in the section.

Create a Process

Opted for ?
- and define where the end user's journey will take place.
Prefer to go with ?
- Capture the end user's selfie using our and create a process.

Check the Process Result

Once the process is complete, check the result in the integration method you chose.

Done. With the result in hand, make the decision to approve or deny the user's registration.

To optimize your integration, you can use the Webhook to know when the result of your process is complete.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our .

Authentication

In this section, you will find the full technical specifications for the authentication method required to use the IDCloud platform’s REST APIs

To use the IDCloud platform, you must authenticate via access token using the OAuth2 authentication system. Unico’s OAuth2 authentication supports server-to-server interaction between a web application and Unico's services.

In this setup, you will need a service account, an impersonal account that belongs to your application rather than to an individual user. Your application calls Unico’s APIs on behalf of the service account, so no users are directly involved. This setup is called “two-legged OAuth,” or “2LO.” Typically, an application uses a service account when it calls Unico’s APIs to work with its own data rather than user data.

This is the first essential step in your implementation, so be sure not to skip it.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Creating a Service Account

In this section, you will find instructions on how to create a service account to authenticate with the Unico IDCloud platform.

To use server-to-server interactions, you need to request the creation of a service account through the project manager responsible for your company by providing the following information: company name, application name, name, email, and phone number of the person responsible for the application within the company. Separate accounts are required for the Homologation and Production environments.

Once this information is received, a service account responsible for authenticating your application will be created, and an email will be sent to generate the key pair for the account.

A service account credential includes a unique account name, a company identifier (Tenant ID), and at least one key pair (public and private). After generating the keys, you will only receive the private key (a .key.pem file) along with the payload that must be used to construct the JWT. This payload will follow the format below:

If you need the public key for system configuration, please contact the project manager responsible for your account. Alternatively, you can generate a public key using the following OpenSSL command:

openssl req -x509 -new -nodes -sha256 -days 720 \
-key fileName.key.pem -out fileName.cert.pem

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Preparing to Make an Authenticated API Request

In this section, you’ll find instructions on how to complete the authentication process on the Unico IDCloud platform

After creating and configuring a service account, your application needs to complete the following steps:

Create a JSON Web Token (JWT), which includes the header, payload, and signature.
Request an Access Token from the OAuth2 authentication platform.
Process the JSON response returned by the authentication platform.

If the response includes an access token, you can use it to make requests to Unico product APIs for which the service account has access permissions. (If the response does not include an access token, your JWT or token request may be incorrect, or the service account might lack the necessary permissions to access the requested resources.)

The access token generated in the above request has a default validity of 3600 seconds, but this may vary based on the security configuration set for your company. When the access token expires, your application must generate a new JWT, sign it, and request a new access token from the authentication platform.

1 - Creating the JWT

A JWT (JSON Web Token) consists of three parts: a header, a payload, and a signature. The header and payload are JSON objects, which are serialized in UTF-8 and then encoded using Base64url encoding. This encoding ensures resilience against modifications due to repeated encoding operations. The header, payload, and signature are concatenated using a period (.) separator.

A JWT is structured as follows:

{Header in Base64url}.{Payload in Base64url}.{Signature in Base64url}

The base text for the signature is formed in the following way:

{Header in Base64url}.{Payload em Base64url}

1.1 - Forming the JWT Header

The header consists of two fields that specify the signing algorithm and the token format. Both fields are mandatory, and each field has only one value. Service accounts rely on the RSA SHA-256 algorithm and the JWT token format.

As a result, the JSON representation of the header is as follows:

{"alg":"RS256","typ":"JWT"}

The Base64url representation is as follows:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9

This ensures that both header and payload are properly encoded before signing, which is crucial for secure authentication.

1.2 - Forming the JWT Payload

The JWT payload contains information about the JWT, including the requested permissions (scopes), the account requesting access, the issuer, the time the token was issued, and the token's lifespan. Most fields are mandatory. Like the JWT header, the payload is a JSON object and is used in the composition of the signature.

1.3 - Required Fields

The required fields in the JWT are shown in the table below. They can appear in any order within the payload.

Name

Description

iss

The identifier of the service account within the company.

scope

A space-delimited list or a list separated by the plus sign (+) of the permissions that the application is requesting. If all permissions of the account are required, use the asterisk sign (*) for that purpose.

aud

exp

The expiration time of the token, specified in seconds since 00:00:00 UTC, January 1, 1970. This value has a maximum time of 1 hour after the moment of issuing the JWT. This value must be numeric. Common cases that DO NOT work:

Using quotes to delimit the value. For example: “1524161193” is a string and will not work. However, 1524161193 is a number and will work.

iat

The moment of issuing the JWT, specified in seconds since 00:00:00 UTC, January 1, 1970. This value must be numeric.

Using quotes to delimit the value. For example: “1524161193” is a string and will not work. However, 1524161193 is a number and will work.

Understand how the conversion works for the issuance (iat) and expiration (exp) fields of the JWT, and also see examples of how to use the values of these fields here. Additionally, the "iat" field should reflect the current time in the required format, and the "exp" field must adhere to the calculation below:

exp = iat + 3600

The representation of the mandatory JSON fields in the JWT payload is as follows:

{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, //This is just an example. Use the current value generated here.
  "iat": 1626293376 //This is just an example. Use the current value generated here.
}

1.4 - Calculating the Signature

The JSON Web Signature (JWS) specification is the mechanism that guides the calculation of the signature for a JWT. The input content for the signature calculation is the byte array of the following content:

{Header in Base64url}.{Payload in Base64url}

The same algorithm specified in the header of the JWT must be used for the signature calculation. The only signature algorithm supported by the OAuth2 authentication platform is RSA using SHA-256. It is expressed as RS256 in the alg field of the JWT header.

Sign the UTF-8 representation of the input content using SHA256withRSA (also known as RSASSA-PKCS1-V1_5-SIGN with SHA-256 hash) with the private key that was created and associated with the service account (the .key.pem file generated from the request received by email). The output content will be a byte array.

The signature must then be encoded in Base64url. The header, payload, and signature must be concatenated with a period (.). The result is the JWT. It should be in the following format: {Header in Base64url}.{Payload in Base64url}.{Signature in Base64url} Below is an example of a JWT token before Base64url encoding:

{Header in Base64url}.{Payload in Base64url}.{Signature in Base64url}

Below is an example of a JWT token before Base64url encoding:

{"alg":"RS256","typ":"JWT"}.
{
  "iss": "service_account_name@tenant_id.iam.acesso.io",
  "aud": "https://identityhomolog.acesso.io",
  "scope": "*",
  "exp": 1626296976, //This is just an example. Use the current value generated here.
  "iat": 1626293376 //This is just an example. Use the current value generated here.
}.
[byte array from signature]

Below is an example of the JWT that has been signed and is ready for transmission:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY291bnRf
bmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb
3BlIjoiKiIsImV4cCI6MTYyNjI5Njk3NiwiaWF0IjoxNjI2MjkzMzc2fQ.JsymP3NZdgCSqeNlgsOM2
-AQ7M450NxFnZnnaKSu4Q8g12QGEIvvM4EhCokUHfwk5s7pOpm2UD_Ng3Hb5g_wgrjfiVSLWH5Q2wYg1AvfLqo
YSoJWaMHm9KL0kpv32XdDD8TZVR-MVd2VBHmCMVbV6gvk8buUoK1HZDN7g84PaY3bfgcB3RKU-
H55lR8yyJjZxToIv17-wfla2G99uaMEFNGX0ZSE7ETn5Z8-WypmFrNAK0TM58upzvfVI6_-
gY4cj4iQvmRbuvxsAaGiHA2xd0RVm2Mrx-gQtdPqtbZPuQcH7k64Z_EOQBgiGTgVjucyHD6zBijr_P-
2mhIxuecNSw

It is also possible to use pre-established libraries to create the JWT. As a reference, you can find a list of libraries on the jwt.io website.

2 - Making a Request for an Access Token

After generating the signed JWT, an application can use it to request an access token. The access token request is a POST HTTPS request, and the body must be URL encoded. The URL is as follows:

https://identityhomolog.acesso.io/oauth2/token

The parameters below are mandatory in the request:

Name

Description

grant_type

Use the following text, URL-encoded if necessary: urn:ietf:params:oauth:grant-type:jwt-bearer.

assertion

The JWT, including the signature.

POST /oauth2/token HTTP/1.1
Host: identityhomolog.acesso.io
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-
bearer&assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzZXJ2aWNlX2FjY
291bnRfbmFtZUB0ZW5hbnRfaWQuaWFtLmFjZXNzby5pbyIsInN1YiI6InVzZXJfaWRlbnRpZmllciIs
ImF1ZCI6Imh0dHBzOi8vaWRlbnRpdHlob21vbG9nLmFjZXNzby5pbyIsInNjb3BlIjoiKiIsImV4cCI
6MTMyODU1NDM4NSwiaWF0IjoxMzI4NTUwNzg1fQ.TjH-mTtwP6tBB93O1sDPaAA6yUF7N2-HZDlpIPz
bf_dxO8A6KZuRWG8ZnICrxX56qj0HREiMlYy27XJgxowrUa0JHvbqc8HJkT7-6Mh7J67UnubZKG1-hi
6jDtkC9BIXBcOhtkNUfZvZetXjLzsRsSDkqxdMtzYZwkRlocvaxL5QXiQhweeEwK_Ux81Adh3z0EIhT
yl7CKJLJ69PuHS7s9IdrjUl79owipp4LF1FvtMhoe7YIL69ohPgFqSv_-Y9qpPdW6be3OEAyKlOM08S
ZBbHBwW4XMvw3uZjTY1sgJ4cBoxrftDpjYOw34oPOKxirqc5-90uOCYe1O1hRtG45w

3 - Handling the response from the authentication platform

If the JWT and the access token request were properly formed and the service account has the necessary permissions, then the response from the authentication platform returns a JSON object containing an access token. Here’s an example of a response from the platform:

{
  "access_token": "<access_token>",
  "token_type": "Bearer",
  "expires_in": "3600"
}

The access token returned in the “access_token” field of the JSON object is also a JWT that should be used for the APIs of Unico’s products. If an error occurs in the request, you can check the type of error in the error table by clicking here.

4 - The duration of the access token

The duration of the access token is variable. Its duration is specified in the "expires_in" field, returned along with the access token. The same access token should be used during its validity for all calls to the product APIs.

Do not request a new access token until the validity of the current token is nearing its end. We recommend a margin of 600 seconds (10 minutes). To do this, perform the calculation:

decoded token:
new Date(token.exp - 600)

Where token.exp is the timestamp of the token's expiration.

By default, the token sent to the company is valid for 1 hour, but this can be changed. It is recommended to always use the expires_in as a reference and subtract 600 seconds from it to request a new token.

Examples:

Standard scenario:
expires_in: 3600 (1h) - Token generation at 2:42 PM

Request a new token only at 3:32, that is, 2:42 + (3600 - 600)

Scenario with altered duration:
expires_in: 7200 (2h) - Token generation at 2:42 PM

Request a new token only at 4:32, that is, 2:42 + (7200 - 600)

A new access token can be requested when there are 10 minutes left until expiration.

Do not use a fixed time to obtain a new token, as the duration of the received token may be shorter than the established time, which will result in service usage failures.

¹ According to RFC 4648 for BaseN encoding, the Base64url format is similar to the Base64 format, except that the character = should be omitted, and the characters + and / should be replaced with - and _, respectively.
² JSON Web Signature: https://tools.ietf.org/html/rfc7515.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Additional Resources

In this section, you will find additional resources related to authentication

Example in Javascript

In this section, you will find an example of implementing authentication for the Unico IDCloud platform in JavaScript

const fs = require('fs')
const path = require('path')
const jwt = require('jsonwebtoken')
const request = require('request')

// settings
const basePath = 'https://identityhomolog.acesso.io'

// entry point
let options = {
    serviceAccount: 'svcapp1',
    tenant: "9ea3c3bd-4447-4c3b-ae2e-504b795d3733"
}

requestAnAccessToken(createServiceAccountToken(options), (err, accessToken) => {
    let payload = jwt.decode(accessToken.access_token)
    console.log('Response:')
    console.log(' Access Token: ', accessToken.access_token)
    console.log(' ID: ', payload.jti)
    console.log(' Issuer: ', payload.iss)
    console.log(' Subject: ', payload.sub)
    console.log(' expires_in: ', accessToken.expires_in)
    console.log(' Expiration Date: ', new Date(payload.exp))
    console.log(' Creation Date: ', new Date(payload.iat))
})

// functions
function createServiceAccountToken({tenant, serviceAccount, account = ''}) {
    // Reads the service account private key
    let privateKey = fs.readFileSync(path.resolve(`${serviceAccount}.key.pem`))

    // Prepare the request
    let payload = {
        iss: `${serviceAccount}@${tenant}.iam.acesso.io`,
        aud: basePath,
        scope: '*',
        exp: Math.floor(Date.now() / 1000) + 3600,
        iat: Math.floor(Date.now() / 1000)
    }
    // Service account is requesting an access token for another user?
    if (account) {
        payload.sub = account
    }

    // Create JWS
    return jwt.sign(payload, privateKey, { algorithm: 'RS256' })
}

function requestAnAccessToken(serviceToken, callback) {
    // Prepare the request
    let options = {
        method: 'POST',
        url: `${basePath}/oauth2/token`,
        headers: {'content-type': 'application/x-www-form-urlencoded'},
        form: {
            grant_type: 'urn:ietf:params:oauth:grant-type:jwt-bearer' ,
            assertion: serviceToken
        }
    }
    console.log('Requesting Access Token with self created token:' )
    console.log('', serviceToken)

    // Ask identity and authorization server for an access token
    request(options, (error, response, body) => {
        if (error) {
            callback(new Error(error))
        }

        body = JSON.parse(body)

        if (body.error) {
            callback(new Error(`${body.error}: ${body.error_description}`))
        }

        callback(null, body)
    })
}

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Authentication Errors

In this section, you will find the possible errors that may occur when trying to authenticate on the Unico IDCloud platform.

The errors returned in the request can be identified by the codes below and have the following structure:

{
  "error": "server_error",
  "error_description": "Falha na autenticação x.x.x"
}

Name

Description

1.0.1

Check if the ID provided in the formation of "iss" is the correct tenant ID given during the generation of the private key.

1.0.14

Check with the project manager if the application being used is active.

1.1.1

The "scope" parameter was not provided in the payload of the JWT used in the request.

1.2.4

The JWT used in the request has expired. Check the value specified in the "exp" field of the payload.

1.2.5

The JWT used in the request cannot be validated. Verify the parameters provided and ensure that it was signed correctly.

1.2.6

The private key used to sign the JWT in the request is no longer acceptable. Request new credentials for the account used.

1.2.7

The JWT used in the request is no longer acceptable as it has already been used. Generate a new token to make a new request.

1.2.11

The account used is not active.

1.2.14

The account used does not have the necessary permissions.

1.2.18

The account used has been temporarily locked due to exceeding the number of invalid authentication attempts.

1.2.19

The account used is not authorized to impersonate another user account (remove the "sub" parameter from the payload).

1.2.20 1.2.21

Failed to decode the JWT used in the request. Use a new token by including only the fields specified in the "Mandatory Fields" and "Additional Fields" sections, adhering to the naming, semantics, and type of each field.

1.2.22

The JWT used in the request contains additional fields in the payload that are not allowed. Use a new token by including only the fields specified in the "Mandatory Fields" and "Additional Fields" sections, adhering to the naming, semantics, and type of each field.

1.3.1

The account used has source IP restrictions.

1.3.2

The account used has access date/time restrictions.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Postman Collection

In this section, you will find the Postman collection for the REST API to authenticate on the Unico IDCloud platform

Download the file below, import it into Postman, and replace the values of the parameters "service_account," "tenant_id," and "secret_key" to test the request.

Integration by Unico

In this section, you will find all technical specifications for the Unico IDCloud platform's REST APIs, using the by Unico integration method.

Overview

In this section you will find all the technical specifications of the by Unico REST APIs

An Introdution

The by Unico channel provides an infrastructure for identity validation solutions from the IDCloud platform.

It aims to simplify the use of IDCloud's capabilities by offering a solution that can be integrated into your back end and front end, enhancing transaction security.

Compatible devices

Android

iOS

Web

Compatible with all devices with a front camera, whether laptops or mobile, respecting the list of officially supported browsers below:

Native browsers

Mobile browsers

Computer/notebook browsers

Other browsers are not supported.

Possible Flows

The by Unico integration for Unico IDCloud allows clients to integrate more easily and connect different capabilities within a single journey. This integration provides the necessary resources for functions such as Liveness, Identity Verification, Risk Scoring, Document Capture and Reuse, and Electronic Signature.

To utilize these functions, simply adjust the flow parameter in the REST API payload, which unlocks various verification journey options.

Please refer to the table below to see the available flows and their respective capabilities:

If you use the Document Reuse and Capture capability, consider:

Reuse: Brazilian ID (RG), Brazilian Driver's License, CIN and Brazilian Passport;
Capture: Brazilian ID (RG), Brazilian Driver's License, CIN and Brazilian Passport;

How to integrate

Authenticate

First, you need a service account and must complete OAuth2 authentication to obtain a valid access token.

Learn more in Authentication.

Create a Process

With the access token obtained in the previous step, make a POST request to the endpoint client/v1/process (here you specify the "flow" you want to use).

Learn more in CreateProcess.

Define Your User’s Journey

In this step, determine where your user's journey will take place.

Will the journey be web-based? You can use the browser Redirect or iFrame.
Will the journey be in your app? You can use a Webview.
Will the journey be in a messaging flow? You can send notifications via WhatsApp, SMS, and Email (simply provide the corresponding parameter in the CreateProcess request in step 2).

Check the Process Result

With the access token from step 1, make a GET request to the endpoint client/v1/process/{id} (here you enter the "id" of the process created in step 2), check the process result, and decide whether to approve the user.

Learn more in GetProcess.

To optimize your integration, you can use a Webhook to be notified when your process result is complete.

API

In this section, you will find everything related the REST APIs for using the by Unico integration method

API Reference

In this section, you will find all available REST APIs for using the by Unico integration method

CreateProcess

In this section, you will find how to create a process in Unico via the REST API

Introduction

In this section, you will find detailed documentation on how the Process Creation endpoint works in by Unico. Note that to utilize the capabilities of the IDCloud platform in this integration method, you only need to change the value of the "flow" parameter when creating the process. Unico will handle the orchestration of all the desired capabilities.

Learn more about using capabilities in by Unico in the Overview section.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

You can learn more about generating an access token here.

Endpoints:

UAT: ;
Produção: .

Creat Process

Processes must be created exclusively through backend-to-backend communication, due to our CORS policy, which prevents processes from being created through frontend-to-backend communication.

Tips:

For more information about the scenarios you may receive in the response, refer to the Response Scenarios section.

CreateProcess separated by flows

In this section, you will find examples of CreateProcess requests in Unico

Requests separated by flows

This payload is used to create the following flows:

idlive / id / idlivetrust / idtrust / idcheck / iddocs / idchecktrust / idchecktrustdocs / idcheckserpro / idcheckserprodocs.

{
  "callbackUri": "/path/to/url",
  "flow": "idlive", //this flow is just an example
  "person": {
    "duiType": "DUI_TYPE_BR_CPF",
    "duiValue": "73689290074",
    "friendlyName": "Luke Skywalker",
    "phone": "5511974749090",
    "email": "luke@unico.io",
    "notifications":
    [
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_WHATSAPP"
      },
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_SMS"
      },
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_EMAIL"
      }
    ]
  },
  "purpose": "biometryonboarding",
  "expiresIn": "3600s"
}

This payload is used to create the following flows:

idsign / iddocssign / idchecktrustsign / idchecktrustdocssign / creditoconsignado / idcheckserprodocssign / idtrustdocssign / idunicodocssign.

{
  "callbackUri": "/path/to/url",
  "flow": "idsign", //this flow is just an example
  "person": {
    "duiType": "DUI_TYPE_BR_CPF",
    "duiValue": "73689290074",
    "friendlyName": "Luke Skywalker",
    "phone": "5511974749090",
    "email": "luke@unico.io",
    "notifications": 
    [
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_WHATSAPP"
      },
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_SMS"
      },
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_EMAIL"
      }
    ]
  },
  "purpose": "biometryonboarding",
  "expiresIn": "3600s",
  "payload": [
    {
      "envelopePayload": {
        "documents": [
          {
            "documentName": "teste",
            "fileContents": "JVBERi0xLjMNCiXi48/[...]DKJSVFT0YNCg=="
          }
        ]
      }
    }
  ]
}

This payload is used to create the following flows:

idtoken / idtokentrust.

{
  "callbackUri": "/path/to/url",
  "flow": "idtoken",
  "bioTokenId": "339f9225-6f09-4303-9688-bf35944787e1",
  "person": {
    "duiType": "DUI_TYPE_BR_CPF",
    "duiValue": "73689290074"
    "friendlyName": "Luke Skywalker",
    "phone": "5511974749090",
    "email": "luke@unico.io",
    "notifications": 
    [
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_WHATSAPP"
      },
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_SMS"
      },
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_EMAIL"
      }
    ]
  },
  "purpose": "biometryonboarding",
  "expiresIn": "3600s"
}

This payload is used to create the following flows:

idtokensign.

{
  "callbackUri": "/path/to/url",
  "flow": "idtoken", //este é um exemplo de flow
  "bioTokenId": "339f9225-6f09-4303-9688-bf35944787e1",
  "person": {
    "duiType": "DUI_TYPE_BR_CPF",
    "duiValue": "73689290074"
    "friendlyName": "Luke Skywalker",
    "phone": "5511974749090",
    "email": "luke@unico.io",
    "notifications": 
    [
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_WHATSAPP"
      },
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_SMS"
      },
      {
        "notificationChannel": "NOTIFICATION_CHANNEL_EMAIL"
      }
    ]
  },
  "purpose": "biometryonboarding",
  "expiresIn": "3600s",
  "payload": [
    {
      "envelopePayload": {
        "documents": [
          {
            "documentName": "teste",
            "fileContents": "JVBERi0xLjMNCiXi48/[...]DKJSVFT0YNCg=="
          }
        ]
      }
    }
  ]

Other ways to make a request

curl -X 'POST' \
  'https://api.cadastro.uat.unico.app/client/v1/process/' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {{TOKEN}}'
  -d '{
    "callbackUri": "/",
    "flow": "id",
    "person": {
        "duiType": "DUI_TYPE_BR_CPF",
        "duiValue": "73689290074",
    "friendlyName": "John Doe"
    },
    "purpose": "creditprocess"
}'

To use Postman, follow these steps:

Select the POST method.
Enter the URL https://api.cadastro.uat.unico.app/client/v1/process/.
Select the Authorization tab.
From the Type dropdown list, choose Bearer Token.
Enter the obtained token in the Token field with the prefix Bearer.
Select the Body tab and enter the data below according to your requirements.

{
  "callbackUri": "/paht/callback-url",
  "flow": "id",
  "person": {
    "duiType": "DUI_TYPE_BR_CPF",
    "duiValue": "73689290074",
    "friendlyName": "John Doe"
  },
  "purpose": "creditprocess"
}

const axios = require("axios");

const apiUrl = "https://api.cadastro.uat.unico.app/client/v1/process/";
const token =  "<YOUR_TOKEN_HERE>";

const requestData = {
  callbackUri: "/path/to/url",
  flow: "id",
  person: {
    duiType: "DUI_TYPE_BR_CPF",
    duiValue: "73689290074",
    friendlyName: "John Doe",
  },
  purpose: "creditprocess",
};

const headers = {
  "Content-Type": "application/json",
  Authorization: `Bearer ${token}`,
  accept: "application/json",
};

axios
  .post(apiUrl, requestData, { headers })
  .then((response) => {
    console.log("Resposta da API:", response.data);
  })
  .catch((error) => {
    console.error("Erro:", error);
  });

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.util.HashMap;
import java.util.Map;

public class Main {
    public static void main(String[] args) {
        String apiUrl = "https://api.cadastro.uat.unico.app/client/v1/process/";
        String token = "<YOUR_TOKEN_HERE>";

        // Crie o corpo da solicitação em formato JSON
        String requestBody = "{\"callbackUri\":\"/\",\"flow\":\"id\",\"person\":{\"duiType\":\"DUI_TYPE_BR_CPF\",\"duiValue\":\"73689290074\"},\"purpose\":\"creditprocess\"}";

        // Configure os cabeçalhos da solicitação
        Map<String, String> headers = new HashMap<>();
        headers.put("Content-Type", "application/json");
        headers.put("Authorization", "Bearer " + token);
        headers.put("accept", "application/json");

        // Crie a instância do HttpClient
        HttpClient httpClient = HttpClient.newBuilder().build();

        // Crie a solicitação HTTP POST
        HttpRequest request = HttpRequest.newBuilder()
                .uri(URI.create(apiUrl))
                .headers(headers.entrySet().stream()
                        .map(e -> e.getKey() + ":" + e.getValue())
                        .toArray(String[]::new))
                .POST(HttpRequest.BodyPublishers.ofString(requestBody))
                .build();

        try {
            // Envie a solicitação e obtenha a resposta
            HttpResponse<String> response = httpClient.send(request, HttpResponse.BodyHandlers.ofString());

            // Exiba a resposta da API
            System.out.println("Status da resposta: " + response.statusCode());
            System.out.println("Corpo da resposta: " + response.body());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

using System;
using System.Net.Http;
using System.Text;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        string apiUrl = "https://api.cadastro.uat.unico.app/client/v1/process/";
        string token = "<YOUR_TOKEN_HERE>";

        string requestBody = "{\"callbackUri\":\"/\",\"flow\":\"id\",\"person\":{\"duiType\":\"DUI_TYPE_BR_CPF\",\"duiValue\":\"73689290074\"},\"purpose\":\"creditprocess\"}";

        HttpClient client = new HttpClient();
        client.DefaultRequestHeaders.Add("Content-Type", "application/json");
        client.DefaultRequestHeaders.Add("Authorization", "Bearer " + token);
        client.DefaultRequestHeaders.Add("accept", "application/json");

        try
        {
            HttpResponseMessage response = await client.PostAsync(apiUrl, new StringContent(requestBody, Encoding.UTF8, "application/json"));

            if (response.IsSuccessStatusCode)
            {
                string responseBody = await response.Content.ReadAsStringAsync();
                Console.WriteLine("Status da resposta: " + response.StatusCode);
                Console.WriteLine("Corpo da resposta: " + responseBody);
            }
            else
            {
                Console.WriteLine("Erro na solicitação. Status da resposta: " + response.StatusCode);
            }
        }
        catch (Exception e)
        {
            Console.WriteLine("Erro: " + e.Message);
        }
    }
}

package main

import (
    "bytes"
    "fmt"
    "net/http"
)

func main() {
    apiURL := "https://api.cadastro.uat.unico.app/client/v1/process/"
    token := "<YOUR_TOKEN_HERE>";

    // Crie o corpo da solicitação em formato JSON
    requestBody := []byte(`{
        "callbackUri": "/path/to/url",
        "flow": "id",
        "person": {
            "duiType": "DUI_TYPE_BR_CPF",
            "duiValue": "73689290074"
        },
        "purpose": "creditprocess"
    }`)

    // Crie um cliente HTTP
    client := &http.Client{}

    // Crie uma solicitação HTTP POST
    req, err := http.NewRequest("POST", apiURL, bytes.NewBuffer(requestBody))
    if err != nil {
        fmt.Println("Erro ao criar a solicitação HTTP:", err)
        return
    }

    // Defina os cabeçalhos da solicitação
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Authorization", "Bearer "+token)
    req.Header.Set("accept", "application/json")

    // Faça a solicitação HTTP
    resp, err := client.Do(req)
    if err != nil {
        fmt.Println("Erro ao fazer a solicitação HTTP:", err)
        return
    }
    defer resp.Body.Close()

    // Verifique o status da resposta
    if resp.StatusCode == http.StatusOK {
        // Leitura do corpo da resposta
        var responseBody []byte
        _, err := resp.Body.Read(responseBody)
        if err != nil {
            fmt.Println("Erro ao ler o corpo da resposta:", err)
            return
        }

        fmt.Println("Status da resposta:", resp.Status)
        fmt.Println("Corpo da resposta:", string(responseBody))
    } else {
        fmt.Println("Erro na solicitação. Status da resposta:", resp.Status)
    }
}

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

GetProcess

In this section, you will find how to obtain the result of a process in by Unico through the REST API

Introduction

In this section, you will find detailed documentation on how the Process Result Query endpoint works in by Unico.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

You can learn more about generating an access token here.

Endpoints:

UAT: https://api.cadastro.uat.unico.app;
Produção: https://api.cadastro.unico.app.

Process Result Inquiry

Processes must be created exclusively through backend-to-backend communication, due to our CORS policy, which prevents processes from being created through frontend-to-backend communication.

The content returned in the process.services.documents.doc.data parameter, referring to the OCR Extraction technology, can be consulted below:

If we are unable to extract a field from the document, it is not listed in the API return.

Tips:

To implement your business rules, always validate the response from the capabilities by checking the parameters in the following order:
- state = PROCESS_STATE_FINISHED AND result = PROCESS_RESULT_OK;
- THEN, you can proceed with decision-making by analyzing the authenticationInfo parameter.
- If you receive state = PROCESS_STATE_FINISHED with results result = PROCESS_RESULT_INVALID_IDENTITY or PROCESS_RESULT_ERROR, interpret this as an error in the biometric process and attempt the process again.
To enhance your operation's performance, you can utilize our Webhooks and only query the results of processes with a finalized status;
For more details about the scenarios you may receive in the response, refer to the Response Scenarios section.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

GetSelfie

In this section, you will find instructions on how to obtain the selfie from a process in by Unico via the REST API

Introduction

In this section, you will find detailed documentation on how the User Selfie Retrieval endpoint works in by Unico. This endpoint provides the user’s selfie, with a watermark, from completed processes, allowing you to use it as support in cases of user disputes.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

You can learn more about generating an access token here.

Endpoints:

UAT: https://api.cadastro.uat.unico.app;
Produção: https://api.cadastro.unico.app.

Obtaining User Selfie

Processes must be created exclusively through backend-to-backend communication, due to our CORS policy, which prevents processes from being created through frontend-to-backend communication.

Important:

The permission to obtain the user's selfie will depend on Unico's internal evaluation. Understand with the person responsible for your project whether you will be able to consume this service;
It is only possible to get the selfie with the watermark;
The user’s selfie is only available for consultation via REST API for 8 hours after the biometric process is completed. After this period, it is not possible to retrieve the user’s selfie.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

GetEvidenceSet

In this section, you will find instructions on how to obtain the evidential set from a process in by Unico via the REST API

Introduction

In this section, you will find detailed documentation on how the Proof Set Retrieval endpoint works in by Unico. This endpoint will provide the proof set of the completed biometric transaction, allowing you to store it for potential future disputes by the end user.

To learn more about the proof set, see the Specification if the evidenctial section.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

You can learn more about generating an access token here.

Endpoints:

UAT: https://api.cadastro.uat.unico.app;
Produção: https://api.cadastro.unico.app.

Obtaining the Evidentiary Set

Processes must be created exclusively through backend-to-backend communication, due to our CORS policy, which prevents processes from being created through frontend-to-backend communication.

The evidential set from the biometric capture is only available for consultation via the REST API for 2 hours after the completion of the biometric process. After this period, it is no longer possible to retrieve the evidence set.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

Specification of the evidential set

In this section, you will find all the specifications of the evidential set from by Unico

The evidential set is a .pdf document containing authentication evidence of a user who underwent identity validation at by Unico.

Below, you will see how this document is represented, as well as the specification of its return fields:

Evidence Set Fields (click on each to learn more)

User

Watermarked photo;
Name - indicates the name of the authenticated person. This data is obtained through the person.friendly_name parameter of CreateProcess;
CPF of the holder - indicates the CPF of the authenticated person. This data is obtained through the person.dui_value parameter of CreateProcess;
Contact channel - indicates the communication channel with the authenticated person. This data is obtained through the person.notifications parameter of CreateProcess.

Process

Executed flow - indicates which flow was executed. This data is obtained through the flow parameter of CreateProcess;
Process identifier - indicates the process ID. This data is obtained through the process.id parameter in the CreateProcess response;
URL - indicates the authentication URL of the process;
Creation - indicates the creation date of the process. This data is obtained through the createdAt parameter in the CreateProcess response;
Completion - indicates the completion date of the process. This data is obtained through the finishedAt parameter in the CreateProcess response;
State - indicates the status of the process. This data is obtained through the state parameter in the CreateProcess response.

Validations

Validation type - indicates the type of validation for the authentication process;
Identity - indicates the result of the Identity Verification;
Liveness detection - indicates the result of the Liveness Test.

Navegation data

Operating system and browser - indicates the device data;
IP address - indicates the device's IP address.

Evidence of module usage in the flows iddocs, idsign, and iddocssign

When the process involves the IDDocs and Sign flows, the probative set also returns data from these flows such as: Documents:

Document type - identifies the document shared by the person. Ex: CNH / RG;
Collection module - if Yes, identifies whether a document was captured;
Document validated - if Yes, indicates that the shared/reused document has been validated.

Signature:

Envelope data - indicates the documents and their signers;
Envelope ID - UUID that identifies the envelope in Unico Sign.

These evidences can be used to ensure the authenticity of the process.

Important:

The evidentiary set is only available for completed processes;
The evidentiary set for biometric capture is only available for consultation via REST API for 2 hours after the completion of the biometric process. After this period, it is not possible to retrieve the user's selfie.

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our Help Center.

GetDocumentSigned

In this section, you will find how to obtain the signed document of a process in by Unico through the REST API

Introduction

In this section, you will find detailed documentation on how the Signed Document Retrieval endpoint works in by Unico. This endpoint will provide the signed document of the end user in flows that have the Electronic Signature capability.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

You can learn more about generating an access token here.

Endpoints:

UAT: ;
Production: .

Obtaining the Signed Document

Exemplo de um documento gerado:

If the return of the signed document via by Unico is delayed in processing, we recommend waiting at least one minute after the process is completed before performing the query. Additionally, it is important to set up an automatic retry policy for cases where the signed document is not yet available, such as making up to 10 attempts with intervals of 1 to 5 minutes between them.

GetEvidenceSign

In this section, you will find how to obtain the signed document of a process in by Unico through the REST API

Introduction

In this section, you will find detailed documentation on how the Signed Document Proof Set Retrieval endpoint works in by Unico. This endpoint will provide the proof set of the end user's signature in flows that have the Electronic Signature capability.

Getting started

Your API requests are authenticated using an access token. Any request that does not include a valid access token will return an error.

You can learn more about generating an access token here.

Endpoints:

UAT: ;
Production: .

Obtaining the Evidentiary Set of the Signed Document

Example of a generated document:

Response Scenarios

In this section, you will find all response scenarios for by Unico, regardless of whether the processes are completed or not

Flow id

Scenario: Process created

It occurs when the process has been created but has not yet been completed by the user.

state

result

CreateProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

Scenario: Process created with an error

It occurs when the process has been created, but there was an error in the service.

CreateProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

Scenario: Process completed and approved in IDUnico

It occurs when the process was created, finalized by the user, and received a POSITIVE response from IDUnico.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_POSITIVE",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_FALSE",
                "score": 0
            },
            "authenticationId": "652f8864-c364-4cc7-9abb-d38a86d21d66",
            "livenessResult": "LIVENESS_RESULT_LIVE"
        }

Scenario: Process completed and inconclusive in IDUnico

It occurs when the process was created, finalized by the user, but received an INCONCLUSIVE response from IDUnico.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_INCONCLUSIVE",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_FALSE",
                "score": 0
            },
            "authenticationId": "652f8864-c364-4cc7-9abb-d38a86d21d66",
            "livenessResult": "LIVENESS_RESULT_LIVE"
        }

Scenario: Process completed and refused in IDUnico

It occurs when the process was created, finalized by the user, but received an REFUSED response from IDUnico.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_NEGATIVE",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_FALSE",
                "score": 0
            },
            "authenticationId": "652f8864-c364-4cc7-9abb-d38a86d21d66",
            "livenessResult": "LIVENESS_RESULT_LIVE"
        }

Scenario: Process completed and failed the Liveness

It occurs when the process was created, completed by the user, but received a failure response for the Liveness.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_NOT_LIVE"
        }

Flow idcheck

Scenario: Process created

It occurs when the process has been created but has not yet been completed by the user.

CreateProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

Scenario: Process created with an error

It occurs when the process has been created, but there was an error in the service.

CreateProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

Scenario: Process completed and approved in IDUnico

It occurs when the process was created, finalized by the user, and received a POSITIVE response from IDUnico.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_POSITIVE",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_TRUE",
                "score": 0
            },
            "authenticationId": "8b2516fa-0c83-44ef-a365-3269e425166d",
            "livenessResult": "LIVENESS_RESULT_LIVE"
        }

Scenario: Process completed, inconclusive in IDUnico and with score in IDCheck

It occurs when the process was created, completed by the user, received an inconclusive response from IDUnico, but still returned a score from IDCheck.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_INCONCLUSIVE",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_TRUE",
                "score": 10
            },
            "authenticationId": "09f14518-e083-44c2-bd32-2d0a56426711",
            "livenessResult": "LIVENESS_RESULT_LIVE"
        }

Scenario: Process completed and refused in IDUnico

It occurs when the process was created, finalized by the user, but received an REFUSED response from IDUnico.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_NEGATIVE",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_FALSE",
                "score": 0
            },
            "authenticationId": "652f8864-c364-4cc7-9abb-d38a86d21d66",
            "livenessResult": "LIVENESS_RESULT_LIVE"
        }

Scenario: Process completed, inconclusive in IDUnico and with discarded due to a divergence in IDCheck

It occurs when the process was created, completed by the user, received an inconclusive response from IDUnico, and generated a divergence in IDCheck, which took longer than 60 seconds to be resolved by the divergence engines.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_UNSPECIFIED"
        }

Scenario: Process completed and failed the Liveness

It occurs when the process was created, completed by the user, but received a failure response for the Liveness.

GetProcess

"authenticationInfo": {
            "authenticationResult": "AUTHENTICATION_RESULT_UNSPECIFIED",
            "scoreEngineResult": {
                "scoreEnabled": "SCORE_ENABLED_UNSPECIFIED",
                "score": 0
            },
            "authenticationId": "",
            "livenessResult": "LIVENESS_RESULT_NOT_LIVE"
        }

For detailed verification of the API parameters, please refer to the Parameters Specification section.

Additional Resources

In this section, you will find additional resources related to the by Unico integration method

Postman Collection

In this section, you will find the Postman collection with the REST APIs of by Unico

Still need help?

Didn't find something or still need help? If you're already a client or partner, you can reach out through our .

Controlling the experience

In this section, you will find the experience components that can be used with by Unico

Redirecting the user

In this section, you will find information on how to redirect a user in your applications within the by Unico experience

he userRedirectUrl field is used to direct the user. This field is received in the success response of the process creation when making the CreateProcess request.

Here you will find three ways to manage the user experience in web applications:

(1) Using Redirect:

It is recommended to follow these steps:

In your common flow (which includes the by Unico Registration), you will redirect the client to the link generated through the API;
After that, the client within the platform carries out the necessary procedures to continue the flow;
When completed, they are redirected to your page (using the redirectUrl provided during the process creation).

(2) Using `window.open()`:

The window.open() option consists of opening a new tab in the user's browser so that they can complete the process. At the end, this tab is closed and redirected to your application.

For this, it is recommended to:

Follow the public documentation on this, which can be found ;
Monitorar se houve alteração de URL (para a redirectUrl) e então fechar a aba utilizando window.close().

Step 1: Using CustomTabs for Integration

1 - Add the necessary dependency for using CustomTabs in your app/build.gradle:

implementation("androidx.browser:browser:1.5.0")

Step 2: Opening a CustomTab

import android.net.Uri
import androidx.activity.ComponentActivity
import androidx.browser.customtabs.CustomTabsClient
import androidx.browser.customtabs.CustomTabsIntent

class CustomTabActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
       super.onCreate(savedInstanceState)

       openCustomTab(<URL_CBU>)
    }

    fun openCustomTab(url: String) {
        val builder = CustomTabsIntent.Builder()
        val customTabsIntent = builder.build()
        customTabsIntent.launchUrl(this, Uri.parse(url))
    }
}

Step 3: Modifying AndroidManifest

Add the necessary permissions and intents in the AndroidManifest.xml for the Activity that you want to receive the callback_uri. It is necessary to include the attribute android:launchMode="singleTop" as well as the <data> tag providing the URI data.

xml

<uses-feature android:name="android.hardware.camera" android:required="false"/>
<uses-permission android:name="android.permission.CAMERA"/> 
// ermissions for camera and geolocation are required

<activity
    android:name=".CustomTabActivity"
    android:exported="true"
    android:label="@string/app_name"
    android:theme="@style/Theme.Customtabs"
    android:launchMode="singleTop">

    <intent-filter android:label="Custom Tab">
        <action android:name="android.intent.action.VIEW" />

        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />

        <!-- scheme e host são os dados fornecidos na criação de um processo no campo callback_uri
        callback_uri: "foobar://success?code=1234" -->
        <data android:scheme="foobar" android:host="success"/>
    </intent-filter>

</activity>

The following permissions are necessary for it to function correctly:

Camera
Geolocation

Step 4: Getting Return Information

o retrieve redirect information with the provided data, you can use the following code in the onNewIntent method of your Activity:

override fun onNewIntent(intent: Intent) {
    super.onNewIntent(intent)

    val url = intent.data
    val scheme = url.scheme // "foobar"
    val host = url.host // "success"
    val code = url.getQueryParameter("code") // "1234"
}

Passo 1: Criar o controlador de autenticação

1 - O primeiro passo é criar o controlador de autenticação, e, para isso crie uma classe chamada UnicoAuthenticationController (ou como preferir chamar).

2 - Na sequência, importe o framework AuthenticationServices no topo da classe.

3 - Declare a classe como NSObject e implemente o protocolo ASWebAuthenticationPresentationContextProviding.

O resultado deve ser:

import AuthenticationServices

class UnicoAuthenticationController: NSObject, ASWebAuthenticationPresentationContextProviding {
    func presentationAnchor(for session: ASWebAuthenticationSession) -> ASPresentationAnchor {
           if let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene {
               if let mainWindow = windowScene.windows.first {
                   return mainWindow
               }
           }
           return ASPresentationAnchor()
       }
}

Passo 2: Implementar a autenticação

1 - Abra o arquivo onde você executa a autenticação e adicione as importações necessárias (como exemplo, o ContentView.swift é usado).

import SwiftUI
import AuthenticationServices

2 - Para controlar o estado do fluxo é preciso criar a propriedade @State.

@State private var finished = false

3 - Crie uma instância da classe UnicoAuthenticationController fora do corpo da estrutura ContentView.

let unicoController = UnicoAuthenticationController()

4 - Para a validação do processo, crie uma função chamada redirectUser.

func redirectUser() {
        guard let url = URL(string: "URL_AUTHENTICATION") else { return }

        var session: ASWebAuthenticationSession?
        session = ASWebAuthenticationSession(url: url, callbackURLScheme: "BUNDLE") { callbackURL, error in
            guard callbackURL != nil else {
                if let error = error {
                    return print("Erro durante o processo: \(error.localizedDescription)")
                }
                return
            }

            // Processa o URL de callback para verificar se o processo foi finalizado
            session?.cancel()
            finished = true
        }

        session?.presentationContextProvider = unicoController
        session?.prefersEphemeralWebBrowserSession = true
        session?.start()
    }

Ambientes:

Lembre-se de alterar a url URL_AUTHENTICATION para a URL de autenticação recebida em seu processo e também o callbackURLScheme BUNDLE para o redirect informado na criação do processo (o uso do Bundle Identifier de seu aplicativo é recomendado).

Autenticação única:

É importante setar prefersEphemeralWebBrowserSession para true para garantir uma autenticação única por processo.

It is also possible to use the link generated by Unico in hybrid frameworks. To do this, you can create a bridge between the framework used and the native one and follow as we suggest in the documents or use a library that makes these integration options available.

Integrating WebView into your application is the customer's sole responsibility, as this functionality is not offered as part of Unico's libraries or SDKs. Because of this, we do not offer technical support for questions or problems related to implementing WebView in your application. For configuration guidance, we recommend consulting the official documentation for the technology used in your project (e.g. React Native, Flutter, etc.).

SDK

In this section, you will find how to implement the Unico SDK in your web application for using the by Unico

The use of integrations that do not comply with the standards outlined in this documentation may result in unexpected system interruptions, which will not be covered or supported by by Unico.

Examples: Embedding the by Unico SDK (iFrame) within a webview, implementing the iFrame using an HTML tag, etc.

How to start

To use by Unico through the Unico Web SDK, the first step is to register the domains that will be used as hosts to display the user journey experience.

Please inform the person responsible for your integration project or the Unico support team to carry out this configuration.

To begin using the SDK, we should start with the installation of the Unico web SDK:. by Unico uses the same SDK that is used for IDPay:

$ npm install idpay-b2b-sdk

When installing the Unico SDK package, deploy without specifying the version you are using so that your dependency manager always updates minors and patches to the latest version.

To check previous versions, go to .

Available methods

init(options)

This method initializes the SDK by preloading assets, creating a smoother experience for the end user. At this point, it is necessary to send the token received as a result of the CreateProcess.

Parameters:

options - an object with the following configuration properties:
- type
  - The type of flow to be initialized. In by Unico, we use the "IFRAME" option.
- token
  - Receives the token of the created process. This token is important to authenticate the journey and ensure that only authorized domains can use it (can be obtained when creating the process via API).

import { UnicoSDK } from “idpay-b2b-sdk”;

UnicoSDK.init({
  type: 'IFRAME',
  env: 'uat'//only if the environment is uat
  token,
});

open(options)

This method opens the by Unico experience. For the IFRAME flow, this function displays the already preloaded iFrame and initiates the messaging flow between the client page and the by Unico experience.

Parameters:

options - an object with configuration properties:

processId
- Receives the ID of the created process. This ID is important to obtain the process details and carry out the entire flow correctly (can be obtained when creating the process via API).
token
- Receives the token of the created process. This token is important to authenticate the journey and ensure that only authorized domains can use it (can be obtained when creating the process via API).
onFinish(process)
- Receives a callback function that will be executed at the end of the by Unico journey, passing the process object with the following data: { captureConcluded, concluded, id }.

const processId = '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf';
const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

const process = {
  id: '9bc22bac-1e64-49a5-94d6-9e4f8ec9a1bf',
  concluded: true,
  captureConcluded: true
};

const onFinishCallback = process => {
  console.log('Process', process);
}

UnicoSDK.open({
  transactionId: processId,
  token: token,
  onFinish: onFinishCallback
});

The sequence diagram below demonstrates how to use the SDK and the API result from by Unico to configure the iFrame:

Opt for the Iframe Solution with Auth Token Instead of CSP

After careful analysis of our needs and challenges, we have decided to adopt a solution based on iframes with authentication tokens rather than implementing a Content Security Policy (CSP). This choice was motivated by various considerations related to the security and flexibility required to meet our clients' demands.

Context and Challenges with CSP

Content Security Policy (CSP) is a powerful tool for protecting web applications against various types of attacks, such as Cross-Site Scripting (XSS) and code injection. However, when configuring a CSP policy, it is necessary to define a strict list of trusted domains. This approach is effective when the domains are fixed and predictable. However, for our clients, who often use dynamic and variable domains, this rigid configuration presents significant challenges.

Vulnerability with Dynamic Domains

Dynamic domains pose a substantial security risk when using CSP. When a client has domains that frequently change or are created dynamically, it would be necessary to constantly update the CSP policy to include these new domains. This not only increases maintenance efforts but also exposes the domains to which the CSP policy applies. Each domain added to the CSP policy is potentially a vulnerability point if not adequately managed.

Solution with Iframe and Auth Token

To mitigate these risks and meet the flexibility required by our clients, we opted to use iframes combined with authentication tokens. This solution provides an additional layer of security and avoids the need to expose or manage an extensive and dynamic list of domains.

How It Works

Secure Authentication: Each iframe is loaded with a unique authentication token for each transaction, ensuring that only authorized users can access the content. This token is verified in real-time, providing an additional layer of security and control.
Content Isolation: The use of iframes allows for the isolation of content in a separate context, reducing the risk of interference between different origins and mitigating potential attacks.
Flexibility for Dynamic Domains: By not relying on a static CSP policy, our solution easily adapts to our clients' dynamic domains without the need for constant updates to security policies.

API

In this section, you will find everything related the REST APIs for using the by Client integration method

API Reference

In this section, you will find all the available REST APIs for using the by Client integration method

Additional Resources

In this section, you will find additional resources related to the by Client integration method

SDK

In this section, you will find all the technical specifications of the available SDKs from the Unico IDCloud platform

SDK Integration

In this section, you will find all the necessary information to implement the SDKs of the Unico IDCloud platform

Android SDK

In this section, you will find all the necessary information to implement the Android SDK of the Unico IDCloud platform

iOS SDK

In this section, you will find all the necessary information to implement the Unico IDCloud platform's iOS SDK

Flutter SDK

Nesta seção, você encontrará todas as informações necessárias pra implementar o SDK Flutter da plataforma Unico IDCloud

Web SDK

In this section, you will find all the necessary information to implement the Web SDK of the Unico IDCloud platform

Additional Resources

In this section, you will find additional resources related to the SDK

help & faq

Selfie Capture

In this section, you will find all the necessary information for using and integrating the Unico IDCloud platform SDK into your iOS applications for selfie capture

This guide has been designed to help you quickly and easily implement the Android SDK. Below, you'll find the step-by-step process for the complete integration. If you wish to customize the experience further, check out the iOS Customization section.

Initializing the SDK

To get started with the Unico Check iOS SDK, import the SDK and implement the AcessoBioManagerDelegate interface within the ViewController you want to use. The implementation of this class is straightforward and can be done with just a few lines of code.

All you need to do is instantiate the builder with the relevant context and override the callback methods with your application’s business logic:

.m:
#import "ViewController.h"
#import <AcessoBio/AcessoBio.h>

@implementation ViewController: UIViewController
- (void)viewDidLoad {
    [super viewDidLoad];  
    unicoCheck = [[AcessoBioManager alloc]initWithViewController:self];
}

- (void)onErrorAcessoBioManager:(ErrorBio *)error {
  // your code
}

- (void)onSystemChangedTypeCameraTimeoutFaceInference {
  // your code
}

- (void)onSystemClosedCameraTimeoutSession {
  // your code
}

- (void)onUserClosedCameraManually {
  // your code
}
@end

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate {
  var unicoCheck: AcessoBioManager!

  override func viewDidLoad() {
    super.viewDidLoad()      
    unicoCheck = AcessoBioManager(viewController: self)
  }

  func onErrorAcessoBioManager(_ error: ErrorBio!) {
      // your code
  }

  func onUserClosedCameraManually() {
      // your code
  }

  func onSystemClosedCameraTimeoutSession() {
      // your code
  }

  func onSystemChangedTypeCameraTimeoutFaceInference() {
      // your code 
  }
}

Environment configuration

Configure the environment that will be used to run the SDK. Use the enumerated environment that contains the following enumerates:

PROD: for production environment;
UAT: for approval environment.

See how to implement it in the example below:

  [unicoCheck setEnvironment:UAT];

 unicoCheck.setEnvironment(.UAT);

Implementing the Callback Functions

As shown in the previous example, the main task when implementing the AcessoBioManagerDelegate interface is configuring the callback methods. Each method is called in response to a specific return from the SDK.

Simply override the methods illustrated in the previous step with your application’s business logic:

onErrorAcessoBioManager(_ error: ErrorBio!)

This method is invoked whenever any implementation error occurs using any SDK method. It receives an ErrorBio parameter that contains error details. See the Error Handling section for more about ErrorBio.

onUserClosedCameraManually()

This method is invoked when the user manually closes the camera, such as by clicking the "Back" button.

onSystemClosedCameraTimeoutSession()

This method is invoked when the maximum session time is reached (without capturing an image).

You can configure the session timeout in seconds using setTimeoutSession. The default and minimum timeout is 40 seconds.

onSystemChangedTypeCameraTimeoutFaceInference()

This method is invoked when the maximum time for face detection is reached without detection.

The maximum time is 13 seconds. The mode is then switched to manual capture to facilitate the user’s action.

All the above methods must be created as indicated in your project (even without any logic); otherwise, the project won’t compile successfully.

Configuring Camera Mode

The SDK is preconfigured with intelligent framing and automatic capture. Configure the camera mode in the builder as follows:

.m:
- (IBAction)configureSmartCamera:(UIButton *)sender {
   [unicoCheck setSmartFrame:true];
   [unicoCheck setAutoCapture:true];
}

@IBAction func configureSmartCamera(_ sender: Any) {
    unicoCheck.setSmartFrame(true)
    unicoCheck.setAutoCapture(true)    
}

The false/true values in the above methods do not alter the capture experience; they are solely used for the SDK's internal logic.

Implementing Delegates for Camera Events

The camera launch method needs to know how to handle situations when an image is successfully captured or when an error occurs during the process. The handling instructions are passed to the camera launch method by setting delegates, which are called in cases of success or error.

Through delegate configuration, you can specify what actions your app should take in the event of an error (using the onErrorSelfie method) or success (using the onSuccessSelfie method) in capturing images.

To set up the delegates, you must implement the SelfieCameraDelegate and AcessoBioSelfieDelegate interfaces:

.h:
#import <UIKit/UIKit.h>
#import <AcessoBio/AcessoBio.h>
#import "SelfieCameraDelegate.h"

@interface ViewController: UIViewController <AcessoBioManagerDelegate, SelfieCameraDelegate,
   AcessoBioSelfieDelegate> {
  AcessoBioManager *unicoCheck;
  // Your code from previous and next steps here
}

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate,
                      SelfieCameraDelegate, AcessoBioSelfieDelegate {    
  //Your code from previous and next steps here
}

`onSuccessSelfie` Method

Upon successful image capture, this method returns a SelfieResult object for subsequent API requests:

- (void)onSuccessSelfie:(SelfieResult *)result {
    NSLog(@"%@", result.base64);
}

func onSuccessSelfie(_ result: AcessoBio.SelfieResult!) {
    // Your code
 }

The SelfieResult object provides two attributes: base64 and encrypted:

Use base64 for preview in the app;
Use encrypted for sending to REST APIs.

The encrypted attribute is strictly intended for sending the image through the by Client APIs. It should not be opened or serialized, as its characteristics may change without prior notice. Its use must be exclusive to interactions with the APIs to ensure the integrity and security of the data. Unico is not responsible for any damages arising from this practice, as modifications may occur unexpectedly.
The base64 and encrypted files can vary in size due to several factors, including the quality of the devices and the photos generated, as well as Unico's business rules. To avoid issues in your application, do not restrict the size of the string generated by the SDK for these files in your programming logic or infrastructure.

`onErrorSelfie` Method

If an error occurs during image capture, this method returns an ErrorBio object:

- (void)onErrorSelfie:(ErrorBio *)errorBio {
  // Your code
}

func onErrorSelfie(_ errorBio: ErrorBio!) {
  // Your code
 }

Learn more about ErrorBio types in the SDK Error Handling section.

Environment Configuration

If not configured, the SDK will use the environment set in the configuration file (getHostKey). If getHostKey is not being used, an error will be returned.

You can configure the environment to be used during SDK execution by using the EnvironmentEnum enumeration, which contains the following options:

EnvironmentEnum.PROD: for the Production environment
EnvironmentEnum.UAT: for the Testing (UAT) environment

See the implementation example below:

[unicoCheck setEnvironment:PROD];

unicoCheck.setEnvironment(.PROD);

Prepare and Open Camera

To proceed with opening the camera, you must first prepare it using the prepareSelfieCamera method. This method takes two parameters: the implementation of the SelfieCameraDelegate class and the JSON with the credentials generated in the previous step.

.h:
#import <UIKit/UIKit.h>
#import <AcessoBio/AcessoBio.h>
#import "SelfieCameraDelegate.h"

@interface ViewController: UIViewController <AcessoBioManagerDelegate,
SelfieCameraDelegate, AcessoBioSelfieDelegate> {
    AcessoBioManager *unicoCheck;
}

.m:
- (IBAction)openCamera:(UIButton *)sender {
    [[unicoCheck build] prepareSelfieCamera:self config:[YourUnicoConfigClass new]];
}

import UIKit
import AcessoBio

class ViewController: UIViewController, AcessoBioManagerDelegate,
  SelfieCameraDelegate, AcessoBioSelfieDelegate {
    @IBAction func openCamera(_ sender: Any) {
        unicoCheck.build().prepareSelfieCamera(self, config: YourUnicoConfigClass())
    }
}

When the camera is prepared, the onCameraReady event is triggered, receiving an object of type AcessoBioCameraOpenerDelegate as a parameter. You should override this method to open the camera using the object received through the open() method:

- (void)onCameraReady:(id)cameraOpener {
    [cameraOpener open:self];
}

- (void)onCameraFailed:(ErrorPrepare *)message {
    // Your code
}

func onCameraReady(_ cameraOpener: AcessoBioCameraOpenerDelegate!) {
    cameraOpener.open(self)
 }
 
func onCameraFailed(_ message: ErrorPrepare!) {
    // Your code
 }

The ErrorPrepare type is an extension of ErrorBio, containing all of its properties. Learn more about the ErrorBio type in the SDK error handling section.

If an error occurs while preparing the camera, the onCameraFailed event is triggered. You should implement this method according to your app's business logic.

Making a POST Request to the Client API

After capturing images, the next step is to send the generated encrypted image from the SDK to the Client APIs.

For security reasons, the interval between the generation of the encrypted data and the sending through one of the available flows must be no more than 10 minutes. Submissions made beyond this period will be automatically rejected by the API.