How to Store Webhooks Data

When you send emails with Resend, you can receive real-time notifications for each message:

• Was it delivered?
• Did the recipient open it?
• Did they click a link?
• Did it bounce?

These events contain valuable data, however, by default webhooks are ephemeral. To make the data persistent, you can store the data in your own datasource. This guide explains why you should store your webhook data and how to get started.

​

Why Store Webhook Data?

Storing your own data offers several benefits.

​

1. Meet Compliance Requirements

Many industries have regulations around data retention and audit trails:

• GDPR - You may need to demonstrate what communications were sent to users and when
• SOC 2 - Audit requirements may include email delivery verification
• Financial regulations - Transaction-related emails may need to be retained for years

Storing your own webhook data gives you full control over retention periods and access controls.

​

2. Enable Long-term Retention

Resend retains email data for a limited period. If you need access to historical email data beyond that window, storing events in your own database ensures you never lose important information.

​

3. Power Automated Workflows

With webhook data in your database, you can build powerful automations:

• Automatically suppress bounced addresses from future sends
• Trigger follow-up emails based on open/click behavior
• Alert your team when delivery issues spike
• Re-engage users who haven’t opened recent emails

​

How to Store Webhook Data

While you can always build your own webhook handler, it requires development resources. To help our customers get started quickly, we’ve built the Resend Webhook Ingester. It’s an open-source, ready-to-deploy solution that handles all the complexity for you:

• One-click deployment to Vercel, Railway, or Render
• Signature verification built-in using Svix
• Idempotent storage that handles duplicate deliveries
• 8 database connectors including PostgreSQL, MySQL, MongoDB, and data warehouses

Webhook Ingester

Deploy a production-ready webhook storage solution in minutes

​

Data Storage Considerations

Whether using the Webhook Ingester or your own handler, you’ll need to consider the following:

​

Choosing a Database

The right database depends on your use case:

​

What Data Should You Store?

At minimum, store these fields for each webhook event:

• Event ID - The unique svix-id for deduplication
• Event type - What happened (delivered, bounced, opened, etc.)
• Timestamp - When the event occurred
• Email ID - Links the event back to the original send

For deeper analytics, also consider storing:

• Recipient addresses - For per-user engagement tracking
• Subject lines - To analyze performance by content
• Tags - If you use tags to categorize emails
• Bounce details - To understand delivery issues
• Click URLs - To track which links perform best

​

Data Retention Considerations

Before storing webhook data, consider your retention requirements:

​

How Long to Keep Data

• Operational use - 30-90 days is often sufficient for debugging and recent analytics
• Compliance requirements - Check your industry regulations (often 1-7 years)
• Historical analysis - Consider aggregating old data rather than keeping raw events

​

Privacy Considerations

Webhook data may contain personal information (email addresses, IP addresses from opens/clicks). Ensure your storage approach complies with privacy regulations:

• Implement appropriate access controls
• Consider data anonymization for long-term retention
• Have a process for handling data deletion requests

​

Storage Costs

High-volume senders can generate significant data. Plan for:

• Database storage costs
• Query performance as data grows
• Archival strategies for old data

​

FAQ

​

Learn More