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 storing your webhook data matters and how to get started.

Storing your own data offers several benefits.

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.

Resend retains email data for 30 days across all plans (with flexible retention for Enterprise). If you need access to historical email data beyond that window, storing events in your own database ensures you never lose important information.

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

While you can always build your own webhook handler, it requires development resources.

You can get started quickly with 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

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

The right database depends on your use case:

At minimum, store these fields for each webhook event:

• Event ID - The unique svix-id for deduplication
• Event type - What happened (for example, delivered, bounced, or opened)
• 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

Before storing webhook data, consider your retention requirements:

• 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

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

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

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