Architecture and Processing

Database Design for Storing Webhook Events

Reliable webhook systems store incoming events before processing them. This enables retries, debugging, and replaying failed deliveries.

Why persist webhook events

Processing webhook events directly inside the request makes debugging difficult. Persisting events creates an audit trail.

Basic webhook events table

                    
webhook_events
--------------
id
provider
event_id
event_type
payload
received_at
processed_at
status
                    
                

Enforce event uniqueness

Many providers deliver duplicate events. A unique constraint prevents duplicate processing.

                    UNIQUE(provider, event_id)
                

Store raw payload JSON

Always store the original payload exactly as received. Do not transform the data before persisting.

Track processing status

Adding a status column allows background workers to track progress.

                    
pending
processing
completed
failed
                    
                

Enable replay support

Stored events can be replayed safely if processing fails. This is critical for payment systems and subscription updates.

Related guides:

Start monitoring your webhook endpoints →