DiscordStatus
Guias / Guides

Webhooks logs

Webhook Logs allow you to track all delivery attempts made by Asaas, making it easier to identify communication failures, monitor integrations, and analyze the behavior of sent events.

This feature is especially useful for investigating errors, validating whether events were delivered successfully, and identifying situations that may lead to queue penalties or interruptions.

❗️

Important

Asaas keeps Webhook logs and events for up to 14 days.

If communication failures occur, an email will be sent to the address configured in the Webhook notifications.

If the queue remains interrupted for more than 14 days, pending events will be permanently removed and cannot be recovered.

Where to view Webhook Logs

You can view sent Webhooks and communication errors through the Webhook Logs page, available under the Integrations section.

It is also possible to manage Webhooks through the API using the documented endpoints. However, delivery logs are available only through the web interface.

What can be analyzed in the logs

The logs allow you to verify:

  • Sent event;
  • Date and time of the attempt;
  • Endpoint used;
  • HTTP status code returned by the application;
  • Communication errors;
  • Timeouts;
  • Number of attempts performed;
  • Situations that may lead to queue penalties or interruptions.

This information helps quickly identify integration issues and validate whether the endpoint is responding properly.

How to use logs to investigate issues

In a typical troubleshooting flow, we recommend:

Receive an alert or notice missing events
↓
Access Webhook Logs
↓
Identify the returned HTTP status code
↓
Investigate the error cause in the application
↓
Fix the issue
↓
Reactivate the queue, if necessary
↓
Validate that new events are being processed normally

Common errors found in the logs

Some common errors are:

  • 400 Bad Request — the endpoint received the request but returned an error due to processing or validation issues.
  • 403 Forbidden — usually caused by firewall rules, WAF, or blocking mechanisms.
  • 404 Not Found — the configured URL does not exist or is not accessible.
  • 408 Read Timed Out — the endpoint took longer than the expected timeout.
  • 500 Internal Server Error — internal application failure.
  • Connect Timed Out — communication failure or server unavailability.

Each of these scenarios has a dedicated troubleshooting page in the documentation.

Viewing Webhook logs from subaccounts

Webhook logs from subaccounts can also be accessed through the parent account.

In Integrations > Webhook Logs, use the Account Type filter.

When selecting Subaccounts, an additional field will be displayed to search by the subaccount identifier.

The identifier is descriptive, and the query is performed for one subaccount at a time.

Best practices

📘

Recommended

  • Monitor Webhook logs regularly.
  • Investigate HTTP status codes other than 200.
  • Fix failures quickly to prevent queue interruptions.
  • Implement asynchronous processing to reduce timeouts.
  • Use idempotency to handle possible retries.
  • Maintain monitoring and alerts for endpoint availability.
  • Reactivate the queue as soon as the issue is resolved.
  • Avoid leaving events pending for long periods.

Next steps

After reviewing the Webhook Logs, we recommend learning about: