Delivery Types
Before configuring a Webhook, you can define the delivery type that will be used. This setting directly affects the order in which events are received, processing time, and the integration behavior in high-volume notification scenarios.
Asaas Webhooks provide two delivery types:
- Sequential
- Non-Sequential
The choice of delivery type should take into account whether preserving event order is required and the processing capacity of your application.
What is the difference between the delivery types?
With Sequential delivery, events are sent respecting the order in which they occurred.
With Non-Sequential delivery, events may be sent simultaneously without guaranteeing their order, providing higher throughput and lower delivery times.
Regardless of the selected delivery type, Asaas Webhooks follow the at least once delivery model, meaning that the same event may be resent if communication failures occur. For this reason, your application should implement idempotency mechanisms to avoid duplicate processing.
Sequential Delivery
Sequential delivery is recommended when event order is important for the application logic.
A common example occurs with payments, where the same entity may go through multiple states during its lifecycle.
PAYMENT_CREATED
↓
PAYMENT_OVERDUE
↓
PAYMENT_CONFIRMED
↓
PAYMENT_RECEIVEDIn this scenario, maintaining the event order is important to ensure processing consistency.
In the example above, events related to the same payment are sent in the sequence in which they occurred. This allows the application to correctly identify that the payment was completed after its due date.
When to use Sequential delivery
Sequential delivery is recommended for:
- Payments;
- Subscriptions;
- Flows that depend on event order;
- Integrations that execute different business rules for each status;
- Processes that require complete traceability of an entity's lifecycle.
Non-Sequential Delivery
With Non-Sequential delivery, events are sent without waiting for previous events to complete.
This allows greater parallelism and faster notification delivery.
Since events can be processed simultaneously, there is no guarantee regarding the order of different notifications.
This mode is recommended when the application receives few events per entity or when the sequence of events does not affect the business logic.
For example, a Webhook used only to track completed or canceled transfers usually receives only one relevant event per operation, making event ordering unnecessary.
When to use Non-Sequential delivery
Non-Sequential delivery is recommended for:
- Independent events;
- High-volume integrations;
- Scenarios where event order is not relevant;
- Asynchronous processing;
- Applications using multiple workers or parallel queues.
Important behaviors
Regardless of the chosen delivery type:
- Events may be resent in case of communication failures;
- The same event may be received more than once;
- The application should return HTTP 200 after processing or persisting the event;
- Idempotency is recommended to prevent duplicate processing;
- Errors or timeouts may cause penalties or interruption of the synchronization queue;
- Asynchronous processing is recommended to reduce endpoint response times.
Operational impacts
Sequential Delivery
Advantages
- Preserves event order;
- Simplifies the implementation of state-dependent business rules;
- Improves auditability and traceability.
Disadvantages
- Lower throughput;
- A slow event may delay subsequent events;
- Higher sensitivity to endpoint failures.
Non-Sequential Delivery
Advantages
- Higher throughput;
- Lower latency;
- Better use of parallel processing.
Disadvantages
- Does not guarantee event order;
- Requires additional care when implementing business logic;
- Makes idempotency even more important.
Best practices
Recommended
- Use Sequential delivery when event order matters.
- Use Non-Sequential delivery for high-volume integrations and independent events.
- Persist events before processing them.
- Process events asynchronously.
- Implement idempotency to avoid duplicates.
- Monitor endpoint failures and timeouts.
- Use Webhook Logs for auditing and troubleshooting.
Next steps
After choosing a delivery type, we recommend consulting:
- Receive Asaas events on your Webhook endpoint;
- How to implement idempotency with Webhooks;
- Webhook Logs;
- Queue Penalties;
- Paused Queue;
- Official Asaas IP addresses;
- Cloudflare Firewall Blocking.
