What is the difference between a BaaS subaccount and a non-BaaS subaccount?

Understand when to use BaaS or non-BaaS subaccounts, which responsibilities change in each model, and how to follow the API creation flow.

Subaccounts allow you to create Asaas accounts for partners, customers, or establishments linked to a Parent Account. Each subaccount can have its own financial management, customers, charges, transfers, balance, and operational settings.

Choosing the Subaccount Model

Use this comparison to decide which model best fits your integration.

In the non-BaaS model, the subaccount accesses the Asaas interface with the features available to it. Subaccounts in this format originate from the Banking Correspondent format.

In the BaaS model, the Borrower — the customer responsible for the Parent Account — integrates Asaas into their own system using the API and the Asaas BaaS product. In this scenario, the end customer does not need to access the account in Asaas to manage or track information.

BaaS Integration Flow

Follow this flow when your operation is enabled for BaaS:

1. Request the release and alignment of the BaaS feature with your account manager.
2. Configure your sandbox account to validate subaccount creation before operating in production.
3. Create the subaccount via the API using the POST /v3/accounts endpoint.
4. Configure webhooks already at subaccount creation to track creation and update events without relying on later manual configuration.
5. Securely store the apiKey returned upon subaccount creation, as it will be used for authenticated calls on behalf of the subaccount.
6. Store the returned walletId if your integration uses features such as Payment Split or transfers between Asaas accounts.
7. Submit the subaccount's registration documents through the onboarding flow via document submission link.
8. Check the subaccount's registration status before enabling financial operations for the end customer.
9. Implement, within your own system, the screens, notices, and management tools that the end customer will use.

Create subaccount
↓
Receive apiKey and walletId
↓
Store credentials securely
↓
Configure webhooks and operational features
↓
Submit registration documents
↓
Check registration status
↓
Operate on behalf of the subaccount via API

Creation Example with Webhooks

Use the POST /v3/accounts endpoint to create a subaccount. See the full subaccount creation reference for all available fields, rules, and responses.

{
  "name": "Subaccount created via API",
  "email": "[email protected]",
  "cpfCnpj": "66625514000140",
  "birthDate": "1994-05-16",
  "companyType": "MEI",
  "phone": "11 32300606",
  "mobilePhone": "11 988451155",
  "address": "Av. Rolf Wiest",
  "addressNumber": "277",
  "complement": "Suite 502",
  "province": "Bom Retiro",
  "postalCode": "89223005",
  "webhooks": [
    {
      "name": "Webhook for charges",
      "url": "http://mywebsite.com/webhook/payments",
      "email": "[email protected]",
      "sendType": "SEQUENTIALLY",
      "interrupted": false,
      "enabled": true,
      "apiVersion": 3,
      "authToken": "5tLxsL6uoN",
      "events": [
        "PAYMENT_CREATED",
        "PAYMENT_UPDATED",
        "PAYMENT_CONFIRMED",
        "PAYMENT_RECEIVED"
      ]
    }
  ]
}

Configuring webhooks at subaccount creation helps avoid missing account creation or update events. The available events are described in the About Webhooks guide.

Fields and Data Requiring Attention

The API reference is the complete source for requirements, validations, and formatting of each field. During implementation, pay close attention to these data points:

Important Behaviors

When creating subaccounts, consider these behaviors in your integration journey:

• When a non-BaaS subaccount is created, Asaas sends a welcome email with a link to set the access password.
• In the Asaas BaaS model, no communication is sent by Asaas to the end customer. The Parent Account must handle communications and provide the necessary resources within its own system.
• Some settings need to be configured individually for each subaccount, such as webhooks, tax information for invoice issuance, and other operational settings.
• New subaccount creation operations via API initially enter the regulatory evaluation period for API services.
• During the regulatory evaluation period, there are limits on the number of subaccounts, the volume issued in charges per subaccount, and the validity period. See the Evaluation Period FAQ for up-to-date details.

Best Practices for BaaS Subaccounts

• Confirm that the BaaS model is enabled with your account manager before creating subaccounts via API.
• Configure webhooks at the time of subaccount creation to track events from the very start of operations.
• Store the apiKey securely as soon as it is returned, and never expose it in logs, administrative screens, or error messages.
• Internally link the created subaccount to the corresponding record in your system to avoid operational discrepancies.
• Inform the end customer about relevant journeys within your own system, since they will not receive automatic communications from Asaas in the BaaS model.
• Clearly identify Asaas as the Providing Institution at the points of contact required by the regulations applicable to the BaaS model.

Next Steps

Deepen your implementation with related content:

• BaaS with Asaas
• Creating Subaccounts with Asaas BaaS
• Reference: Create Subaccount
• Onboarding and Document Submission via Link
• About Webhooks
• Regulatory Evaluation Period FAQ