Notifications

Use this page to define whether customers created through your integration will receive standard Asaas notifications or customized notifications.

When to Use Each Setting

Use notificationDisabled when your application needs to control communications sent to the end customer. This setting is useful when you want to prevent the automatic sending of standard Asaas notifications or when you plan to configure specific notifications before issuing charges.

Choose one of the approaches:

• Disable standard notifications: send notificationDisabled as true when registering or updating the customer.
• Customize notifications: keep notifications enabled, retrieve the customer's notifications, and update the necessary events or channels.

Prerequisites

1. Define whether the customer should receive standard Asaas notifications or customized notifications.
2. Register the customer through the Create new customer route, or use an existing customer that will be updated.
3. For customization, retrieve the notification IDs through the Retrieve a customer's notifications route.

Main Parameter

Disabling a Customer's Standard Notifications

1. Create the Customer with Notifications Disabled

To create a customer with standard notifications disabled, send notificationDisabled as true in the payload.

{
  "name": "Sample Customer",
  "cpfCnpj": "12345678901",
  "notificationDisabled": true
}

Expected result: the customer is created with standard notifications disabled.

2. Update an Existing Customer

If the customer already exists, send an update with notificationDisabled set to true.

{
  "notificationDisabled": true
}

Expected result: after the API confirms the update, the customer's standard notifications are disabled.

Optional: Customizing a Customer's Notifications

Use this flow when you want to keep notifications active but adjust specific settings, such as enabling WhatsApp or modifying existing notifications.

1. Create the customer with notifications enabled.
2. Call the Retrieve a customer's notifications route to get the IDs of the notifications available for the customer.
3. Update the notifications using one of the following options:
   • Update an existing notification, when you want to change one notification ID at a time.
   • Bulk update existing notifications, when you want to apply changes to multiple notifications.
4. Run this configuration before issuing charges when your business rule requires the customer to start with a specific communication pattern from the beginning.

Best Practices

• Always use the boolean type for notificationDisabled.
• Log the final payload sent during customer creation or update to facilitate auditing and support.
• Before performing a bulk notification update, retrieve the customer's most recent notification IDs.
• When updating an individual notification, send only the ID of the notification to be changed.
• Consider the setting applied only after receiving a successful response from the API.
• Test the complete flow before issuing charges to customers in production.

Behaviors That Require Attention

• Invalid payload: sending "notificationDisabled": "true" uses a string instead of a boolean and may cause behavior inconsistent with what is expected.
• Existing customer: updating notificationDisabled changes the setting for the specified customer; confirm that the ID used in the update belongs to the correct customer.
• Customization by ID: to customize notifications, use the IDs returned when querying the customer's notifications. Do not reuse IDs from a different customer.
• Bulk update: validate the notification list before sending to avoid unwanted changes to multiple settings.

Related Content

• Create new customer
• Retrieve a customer's notifications
• Update an existing notification
• Bulk update existing notifications