IMPORTANT: This feature is only available after a distribution channel has been created for your organization.To request the creation of a distribution channel, contact Trio Support or your Trio Account Manager.
Important: this guide explains the flow and the concepts involved. To check all available fields, types, and responses, see the onboarding creation API reference.
1. How the organization model works
In this model, there are two main parties:- Distributor organization: the organization that holds the API credentials and controls the flow for its customers.
- Customer organization: the organization created during onboarding, which will be used for the customer’s transactions.
Trio-Target-Org-Id header.
Also see Acting on another organization.
2. Creating the onboarding
Onboarding is created through the endpoint:client_id and client_secret.
Required data
To start onboarding, send the company’s data, the representative’s data, and the consent data.
Within
business_infos, information such as the following is provided:
- annual revenue;
- average ticket.
- name;
- tax ID (CPF);
- phone number;
- email.
false when omitted:
is_pep: whether the representative is a politically exposed person (PEP);is_us_person: whether the representative is a US person for tax purposes.
- the tax ID (CPF) of the person responsible for the consent;
- IP address;
- date and time of the authorization.
3. Creation example
4. What happens after creation
Onboarding creation is synchronous. After the request is processed, the API returns the main identifiers of the structure that was created, including:entity_id;org_id;company_id;external_id;tax_number;status.
Best practice: save theorg_id,entity_id, andexternal_idin your system. Theorg_idwill be used later to perform operations on the customer’s organization.
Required documents
The response includes arequired_documents field in two places, based on the documents configured for your distribution channel:
- at the entity level (
data.required_documents): the documents the company must provide, such ascompany_contract,power_of_attorney, andfinancial_statement; - inside each representative (
data.representatives[].required_documents): the documents that representative must provide, typicallyidentification.
null when no document is required. Use them to know exactly which documents to upload in the next step.
5. Uploading entity and representative documents
Depending on the distribution channel configuration, Compliance may require supporting documents to be uploaded for the entity and/or its representatives. Documents are sent after the onboarding is created, using the identifiers returned byPOST /onboarding.
Each document is uploaded individually through:
multipart/form-data and the same Basic Authentication as the onboarding creation. Only PDF files are accepted.
Fields
Document types by reference:
- Entity (
reference_type: entity):company_contract,power_of_attorney,financial_statement; - Representative (
reference_type: entity_representative):identification.
entity_id and the representative id are both returned in the POST /onboarding response.
Upload example
Uploading a financial statement for the entity:Response
Tip: upload one document per request. Repeat the call for each required document of the entity and of each representative. See the upload document API reference.
6. Liveness step
After creation, onboarding moves on to the validation process. The representative needs to complete the facial recognition (liveness) check required to open the account. Example:7. Compliance analysis
Once liveness is completed, the customer’s information moves on to Compliance analysis. The distributor organization does not need to keep polling the API to find out whether the analysis has finished. Tracking should be done through entity webhooks. Events in theentity category are sent whenever the Compliance status of an entity created through onboarding changes.
See the Entity events reference.
8. Onboarding webhooks
The main events related to onboarding are:entity.in_review
Indicates that the entity has entered the analysis stage.
When applicable, the event also contains the representative’s liveness_link.
entity.approved
Indicates that the entity was approved by Compliance and is ready to operate.
entity.rejected
Indicates that the entity was rejected by Compliance.
In this case, the event contains a reason field describing the reason for the rejection.
9. Using the customer’s organization
Once onboarding has been approved, the distributor organization can make calls on behalf of the customer’s organization. To do this, use the same credentials as the distributor organization and provide the customer’sorg_id in the header:
403.
Important: access to the organization is configured at the organization level and must be enabled for the integration.
10. Complete flow
The complete flow can be understood as follows:11. Integration recommendations
Save the identifiers
AfterPOST /onboarding, store at least the following in your system:
external_id;org_id;entity_id;company_id;tax_number;- current status.
Use external_id as your system’s reference
The external_id should be a reference that lets you easily identify the customer within your application.
Example:
Only enable operations after approval
Keep the customer in an onboarding state while Compliance is analyzing the entity. After receiving:Handle rejections
When you receive:reason returned by the webhook so the customer’s case can be handled appropriately.
References
Retrieving the bank account after approval
Once the entity is approved (entity.approved), the customer’s bank account is typically made available within a few minutes. It is not created at the exact same instant as the approval event, so you should not assume the account identifier is available immediately.
To retrieve it, call the list virtual accounts endpoint, passing the customer’s org_id in the header:

