Store Webhook Payloads Without Violating GDPR, HIPAA, or Your Own Privacy Policy

Your Twilio webhooks contain patient callback requests. Your Stripe webhooks contain billing addresses. Your in-house user events contain names, emails, and account details. The data that makes your webhooks useful for debugging is exactly the data that your compliance team, your privacy policy, and in many cases the law say you should not be storing in a third-party tool.

This is a real constraint that most webhook debugging tools handle the same way: they do not handle it. Webhook.site stores everything with no controls. ngrok's inspect window stores events in memory until your session ends and then discards them. Neither gives you per-hook granularity over what is stored and how.

The result is an uncomfortable binary: either you use a webhook inspection tool and accept that PII enters a third-party storage system, or you avoid the tool and lose the debugging surface you need.

HookTunnel's payload storage modes break that binary. You choose — per hook — what gets stored. You can have full debugging capability on the hooks that do not touch PII, and compliance-safe behavior on the ones that do.

The three storage modes

Every HookTunnel hook has a payload storage mode setting. You set it when you create the hook, and you can change it at any time. Changing the mode applies to new events going forward; existing stored events are not retroactively deleted or re-processed.

Mode 1: None

No payload is stored. When an event arrives, HookTunnel captures the metadata — timestamp, HTTP method, headers, delivery status, response code — but discards the request body immediately after delivery.

What you retain: delivery history, response codes, latency, the event count, the timestamp sequence.

What you do not retain: any payload field.

This mode is appropriate when your webhook payloads are classified at a level that prohibits third-party storage under any condition. Healthcare providers operating under strict HIPAA interpretations, financial services handling payment card data under PCI-DSS constraints, or organizations whose privacy policies explicitly prohibit third-party storage of personal data will commonly use this mode for their most sensitive hooks.

You lose payload-level debugging capability, but you retain the operational picture: you can see that events are arriving, that delivery is succeeding or failing, and what response codes your handler is returning. For hooks where you have strong confidence in your handler and just need delivery monitoring, none mode is the right choice.

Mode 2: Redacted

The payload is stored, but PII fields are replaced with [REDACTED] before storage.

Redaction targets the following field patterns automatically:

• Email addresses (fields named email, email_address, or values matching the email format)
• Phone numbers (fields named phone, phone_number, to, from, callerNumber, or values matching E.164 format)
• Physical addresses (fields named address, street, city, state, zip, or nested address objects)
• Personal names (fields named name, first_name, last_name, full_name)
• Payment card metadata (fields named card_last4 remain; fields like card_number or cvv are redacted, though these should never appear in a webhook payload in the first place)

Non-PII fields are stored intact. Event types, status codes, IDs, amounts, timestamps, provider-specific metadata, and any field that does not match the PII patterns above are all preserved.

This gives you the debugging surface for most common webhook issues — wrong event type, unexpected status code, missing field, schema mismatch — without storing the customer data that triggers compliance review.

Redacted mode is appropriate when you need to debug your handler logic but cannot store raw customer data. It covers most regulatory concerns for GDPR (Article 5 data minimization principle), HIPAA (minimum necessary standard for PHI), and SOC2 (least-privilege data handling).

Mode 3: Raw Encrypted

The full payload is stored with AES-256 encryption at rest.

Nothing is redacted. The complete request body — every field, every value — is stored encrypted in the HookTunnel database. The encryption key is managed by HookTunnel using per-account key isolation: your encrypted payloads cannot be decrypted using another account's key.

When you view an event in the inspector, HookTunnel decrypts the payload for your session on retrieval. The decrypted payload is never written back to disk; it exists only in memory during your active session.

Raw encrypted mode is appropriate when you need full payload debugging capability and your compliance requirements are satisfied by encryption at rest rather than by redaction or non-storage. Many SOC2 Type II requirements and some GDPR interpretations permit full storage with encryption controls. Your compliance counsel should confirm whether encryption at rest satisfies your specific requirements.

Changing storage mode

You can change the storage mode for any hook at any time from the hook settings panel.

Important behavior to understand when changing modes:

• Changes apply to new events from the point of the mode change forward
• Existing stored events are not affected by mode changes — they remain stored under the mode that was active when they were captured
• Changing from raw_encrypted to redacted does not retroactively redact existing stored payloads
• Changing from redacted or raw_encrypted to none does not delete existing stored events

If your compliance requirement is retroactive — you need to ensure that previously stored events are deleted — use the hook data deletion function, which permanently deletes all stored events for a hook regardless of storage mode.

The healthcare startup scenario

Meridian Health is a startup building a patient communication platform. Their product integrates Twilio (for patient callback requests and appointment reminders) and Stripe (for subscription billing on their provider accounts).

The Twilio webhooks contain patient names, phone numbers, and callback reason fields. These are PHI under HIPAA. Storing raw PHI in a third-party system without a Business Associate Agreement creates compliance liability.

The Stripe webhooks contain billing contact names, addresses, and plan details for their SaaS subscribers. These are personal data under GDPR. Storing them in a third-party system without appropriate controls requires either a Data Processing Agreement or compliance with the GDPR standard contractual clauses.

Meridian's initial approach: avoid webhook inspection tools entirely. Debug by reading CloudWatch logs directly. Incidents that could be diagnosed in 8 minutes from a webhook inspector instead take 35-45 minutes from raw logs.

After evaluating HookTunnel:

• Twilio patient-facing hooks: set to redacted mode. Patient names and phone numbers are masked before storage. Event types, call status codes, and delivery metadata are preserved. The engineering team can debug IVR flow issues without accessing PHI.
• Stripe provider billing hooks: set to raw_encrypted mode. Full payloads stored with AES-256 encryption. HookTunnel is covered under a Data Processing Agreement that Meridian's legal team reviewed and approved.
• Internal event hooks (non-PII): set to default raw_encrypted mode for full debugging capability.

The compliance team approved the configuration. The engineering team has the debugging surface they need. The two requirements are not in conflict.

Debugging effectiveness per mode

This is the honest comparison of what you can and cannot debug in each mode:

| Debugging scenario | None | Redacted | Raw Encrypted | |---|---|---|---| | Is the event arriving at all? | Yes | Yes | Yes | | What HTTP status did my handler return? | Yes | Yes | Yes | | What was the event type? | Yes | Yes | Yes | | Is a specific field missing from the payload? | No | Yes (if field is non-PII) | Yes | | What is the exact value of a specific field? | No | Yes (if field is non-PII) | Yes | | What were the customer contact details in the payload? | No | No (redacted) | Yes | | Semantic search across payload content | No | Partial (non-PII fields only) | Yes | | Replay the exact original payload | No | No (PII is gone) | Yes |

The replay limitation for redacted mode is worth understanding clearly. When a payload is stored in redacted mode, the PII fields contain [REDACTED] in storage. If you replay that event, the replayed payload contains [REDACTED] in those fields — not the original values. For handlers that process PII fields, the replayed event will not accurately reproduce the original behavior. Replay from redacted mode is useful for testing handler logic that does not depend on the redacted fields. For full-fidelity replay, raw_encrypted mode is required.

Comparison with alternatives

| Feature | HookTunnel | Webhook.site | ngrok inspect | RequestBin | |---|---|---|---|---| | Per-hook storage mode control | Yes | No | No | No | | PII field redaction before storage | Yes | No | No | No | | AES-256 encryption at rest | Yes | No | No | No | | Compliance-documented DPA available | Yes | No | No | No | | Change storage mode without recreating hook | Yes | N/A | N/A | N/A | | None mode (capture metadata only) | Yes | No | No | No |

Frequently asked questions

Does redacted mode cover all PII types, or only common ones?

Redacted mode covers the most common PII field patterns found in webhooks from major providers: email, phone, name, and address fields. It does not perform semantic analysis of arbitrary field values — it relies on field names and value format patterns. If your payloads include PII in non-standard field names (for example, a field named billing_contact that contains a full name), those fields may not be automatically redacted. You can request custom redaction rules for additional field patterns via support.

Can I audit which fields were redacted in a stored event?

Yes. When a payload is stored in redacted mode, HookTunnel records the list of field paths that were redacted. In the event detail view, redacted fields are shown as [REDACTED] with a tooltip indicating that the field was redacted before storage.

Is HookTunnel a HIPAA Business Associate?

HookTunnel offers Business Associate Agreements for customers on Pro and Enterprise plans who use HookTunnel to process webhooks containing PHI. The BAA covers HookTunnel's data handling obligations under HIPAA. Contact support to request a BAA before routing PHI-containing webhooks through HookTunnel.

Does GDPR apply to HookTunnel?

HookTunnel processes data on behalf of its customers (as a data processor under GDPR). Customers who are subject to GDPR and route personal data through HookTunnel should execute a Data Processing Agreement. HookTunnel provides a standard DPA for customers on Pro and Enterprise plans.

Can I switch from raw_encrypted to none to delete stored payloads?

Switching storage modes does not delete previously stored events. To delete stored payloads, use the hook data deletion function, which permanently removes all stored events for the hook from HookTunnel's database. Data deletion is irreversible and takes effect within 24 hours per your data retention policy settings.

How is the AES-256 encryption key managed?

HookTunnel uses per-account encryption key isolation. Your account has a dedicated encryption key stored in a separate key management system from the event database. Access to the encryption key requires your session authentication. HookTunnel operations staff cannot decrypt your payloads without your account credentials.