Configuration

jetpay webhooks offer flexible configuration to optimize delivery based on your needs batch size ( max batch size ) range 1 100 events per delivery default 10 events controls the maximum number of events included in a single webhook request higher batch sizes reduce the number of http requests but increase payload size and processing time per request considerations small batches (1 10) lower latency, more real time, more http requests medium batches (10 50) balanced approach, good for most use cases large batches (50 100) fewer requests, higher throughput, delayed delivery for low volume events wait time ( max wait seconds ) range 60 3600 seconds (1 minute to 1 hour) default 60 seconds specifies the maximum time to wait before sending a batch if max batch size hasn't been reached this prevents events from being held indefinitely during low activity periods considerations short wait (60 300s) more real time delivery, may send smaller batches medium wait (300 900s) balanced approach long wait (900 3600s) maximizes batch fullness, accepts higher latency how batching works webhook delivery is triggered when either condition is met batch size reached accumulated undelivered events reach max batch size wait time elapsed max wait seconds have passed since the oldest undelivered event this ensures both throughput efficiency and acceptable latency example scenarios high volume period events accumulate quickly, batches sent when max batch size is reached (e g , every few seconds) low volume period few events occur, batches sent after max wait seconds elapses (e g , every 60 seconds with 2 3 events) no events no webhook requests are sent (no empty batches) replay from event id or timestamp two options for replaying historical events replay from event id start delivery from a specific event id (inclusive) all events with id >= this value will be delivered use cases recovering from a known missed event reprocessing events after fixing a bug in your handler backfilling a new integration replay from timestamp start delivery from a specific iso 8601 timestamp (inclusive) all events created at or after this time will be delivered use cases time based recovery ("replay everything since yesterday") initial backfill for new webhooks reprocessing after downtime important notes replay is sequential and respects batch size and wait time settings large replays may take time to complete (events delivered in batches) only one replay parameter should be specified (id takes precedence if both provided) setting replay parameters via patch will restart event delivery from that point