Webbu Docs

How Buffering Works

How Webbu groups webhooks and delivers them as batches.

The problem

Webhook senders make one HTTP request per event. At volume this means:

  • High request volume: thousands of requests hitting your app or automation tool
  • Per-event costs: automation platforms bill per task, operation or execution
  • Scattered processing: related events (all events of one customer or conversation) are handled one by one

The solution

Webbu sits between the sender and your application:

Sender → Webbu ingest → group buffer → batch delivery → your endpoint
  1. Ingest: each webhook is accepted with 202 and stored
  2. Group: the payload is assigned to a group using the buffer's group key, e.g. $.customerId
  3. Buffer: items accumulate in the group until a flush condition is met
  4. Deliver: the group's items are sent to your destination in one request, with retries and a dead letter queue

Building blocks

EntityWhat it is
ProjectA container for buffers, e.g. one per environment or application
BufferOne webhook source: group key rule, flush conditions, destination and retry settings. Its ingest URL is https://webbu.dev/api/v1/ingest/{projectId}/{bufferId}
GroupThe pending items of one group key in one buffer
SegmentA group is split into numbered segments when it exceeds its overflow limits; see Segments & Overflow
ItemOne accepted webhook payload

Example

With a buffer grouped by $.customerId, an idle timeout of 5 seconds and the other settings at their defaults:

TimeWebhookGroup
0 s{"customerId": "cus_1", "event": "order.created"}cus_1 (1 item)
1 s{"customerId": "cus_2", "event": "order.created"}cus_2 (1 item)
2 s{"customerId": "cus_1", "event": "order.paid"}cus_1 (2 items)

Around 6 s, cus_2 has been idle for 5 s and is delivered with 1 item. Around 7 s, cus_1 is delivered with 2 items. Your endpoint received 2 requests instead of 3; with real traffic the reduction is usually much larger. The dashboard shows it as the compression ratio (webhooks received per delivery).

On this page