Detailed Subaccount Approval Flow

Asaas has two subaccount approval flows: non-BaaS and BaaS.

Both start with creating the subaccount:

POST /v3/accounts
See the full reference for this endpoint

The difference lies in account activation and document submission.

ModelAccess to AsaasDocument submission
Non-BaaSThe account holder accesses the Asaas interface.Done by the account holder in the Asaas interface.
BaaSThe customer uses the experience provided by your platform.Done through the onboardingUrl or via the API, depending on the requested document.

Regulatory Evaluation Period

New subaccount creation operations via API start the regulatory evaluation period from the first subaccount created in Production.

During this period:

  • up to 10 subaccounts can be created;
  • each subaccount can issue up to R$ 2,000.00 in charges;
  • the period can last up to 60 calendar days from the first subaccount created.
📘

Important

  • After reaching any limit (quantity, amount, or time), creating new subaccounts and issuing additional charges, subscriptions, and payment links will be automatically blocked until the regulatory evaluation process (checklists/documentation) is completed.
  • In the new regulatory scenario, at every touchpoint with your end customer (your own screens, receipts, onboarding, contracts), it is mandatory to display the Asaas brand, links, and responsibility statements. See the Asaas compliance Playbook for details; it will be created and sent exclusively to you by our support team.

See the Evaluation Period FAQ to understand the rules, blocks, and approval.

Non-BaaS subaccount approval

After a non-BaaS subaccount is created, the account holder receives an activation email to set their password and access Asaas.

Registration documents are sent directly through the Asaas interface.

%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
    A["Create the subaccount"] --> B["Start registration validation"]
    B --> C["Send activation email"]
    C --> D["Set password and access Asaas"]
    D --> E["Send documents"]
    E --> F["Review documentation"]
    F --> G["Account approved"]

    classDef inicio fill:#DBEAFE,stroke:#2563EB,color:#1E3A8A,stroke-width:3px,font-size:17px
    classDef validacao fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E,stroke-width:2px,font-size:17px
    classDef sucesso fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:3px,font-size:17px

    class A inicio
    class B,C,D,E,F validacao
    class G sucesso

    linkStyle default stroke:#94A3B8,stroke-width:2px

Typically, the registration review includes an identification document and a selfie of the account holder or legal representative.

To implement creation, see Creating subaccounts.

BaaS subaccount approval

In BaaS, your application drives the customer journey. Documents are sent through the onboardingUrl or via the API, depending on the request returned by Asaas.

After creating the subaccount, wait at least 15 seconds before checking the pending documents:

GET /v3/myAccount/documents
See the full reference for this endpoint

The response defines how each document must be sent.

%%{init: {"flowchart": {"nodeSpacing": 28,"rankSpacing": 32,"diagramPadding": 8,"padding": 10}}}%%
flowchart TD
    A["Create the subaccount"] --> B["Wait at least<br/>15 seconds"]
    B --> C["Check pending<br/>documents"]
    C --> D{"Has onboardingUrl?"}

    D --> DSim(("Yes"))
    D --> DNao(("No"))

    DSim --> E["Direct the customer<br/>to the onboardingUrl"]
    DNao --> F["Send the document<br/>via the API"]

    E --> G["Track the review"]
    F --> G
    G --> H["Account approved"]

    classDef inicio fill:#DBEAFE,stroke:#2563EB,color:#1E3A8A,stroke-width:3px,font-size:17px
    classDef decisao fill:#FEF3C7,stroke:#D97706,color:#78350F,stroke-width:3px,font-size:17px
    classDef validacao fill:#E0F2FE,stroke:#0284C7,color:#0C4A6E,stroke-width:2px,font-size:17px
    classDef sucesso fill:#DCFCE7,stroke:#16A34A,color:#14532D,stroke-width:3px,font-size:17px

    classDef respostaSim fill:#22C55E,stroke:#15803D,color:#FFFFFF,stroke-width:3px,font-size:16px
    classDef respostaNao fill:#EF4444,stroke:#B91C1C,color:#FFFFFF,stroke-width:3px,font-size:16px

    class A inicio
    class B,C,E,F,G validacao
    class D decisao
    class H sucesso

    class DSim respostaSim
    class DNao respostaNao

    linkStyle default stroke:#94A3B8,stroke-width:2px
    linkStyle 3 stroke:#22C55E,stroke-width:4px
    linkStyle 4 stroke:#EF4444,stroke-width:4px

Document with onboardingUrl

When onboardingUrl is present, direct the customer to the returned link.

The document must be sent through the Asaas external flow.

Document without onboardingUrl

When the document does not have an onboardingUrl and allows submission via the API, use the returned id:

POST /v3/myAccount/documents/{id}
See the full reference for this endpoint

For individuals and businesses, identification documents and a selfie are usually requested. Associations may require additional documents, such as the Election Minutes.

🚧

Important

The onboardingUrl attribute mandatorily determines the document submission method.

Never try to send a document that has an onboardingUrl via the API.
→ The submission will be rejected.

❗️

ATTENTION:

Respect the minimum timeout of 15 seconds after account creation before checking pending documents.

See Onboarding and sending documents via link to implement the complete document submission.

Track approval via Webhooks

To automatically track the registration review, configure the Account status Webhooks.

Use the events received to update the subaccount's status in your application. The ACCOUNT_STATUS_GENERAL_APPROVAL_APPROVED event indicates the account's general approval.

When you need to retrieve the current status on demand, use:

GET /v3/myAccount/status
See the full reference for this endpoint

The account is fully approved when general returns APPROVED.

Next steps


Did this page help you?