Security and Data

Webhook events often contain sensitive data: payment details, customer information, order contents. Knowing exactly what gets stored and who can access it matters, especially before you connect production integrations.

Encryption

All data is encrypted in transit using HTTPS/TLS. Stored event payloads are encrypted at rest. Signing secrets are stored encrypted and are never displayed in full after initial entry. The dashboard shows only the last few characters as a confirmation hint.

Access control

Access to workspace data is restricted to members you've explicitly invited. No one outside your workspace can view your event logs, source configurations, or destinations.

Support staff can access workspace data only when you've explicitly requested help and provided consent. Routine support queries are handled without accessing event payload data.

What's stored

For each event, the following is stored:

Raw request body (the full webhook payload)
Request headers (including the provider signature header)
Source IP address
Timestamp of receipt
Verification result (Verified / Failed / Skipped)
Delivery attempts: HTTP status, response body, timestamps

This data is retained for the duration of your plan's retention window (1, 7, 30, or 90 days depending on plan), then permanently deleted.

Sensitive data masking

Webhook payloads and headers can contain credentials, customer data, or provider signature values. Per-source data masking lets you hide those values in the event viewer without affecting delivery.

When masking is on for a source, sensitive headers (Authorization, Cookie, X-Api-Key, and provider signature headers) are replaced with [redacted] in the dashboard. You can also add custom header names and dot-notation payload field paths to redact. The raw data is never modified: the body is preserved for delivery, while forwarding uses the supported header allowlist.

See Data masking for setup and configuration details.

Ingest URL security

Your ingest URL is a public endpoint. Anyone with the URL can send a POST request to it. HMAC signature verification is the control that ensures only genuine provider events are accepted and forwarded. Requests that fail verification are logged as Failed. They are quarantined only when Reject invalid signatures is enabled; otherwise they may be forwarded.

A source without a configured vendor and signing secret is forwarded without verification and may have no stamp. For production integrations, configure verification and enable Reject invalid signatures deliberately.

Subprocessors

Webhook Watchtower uses a small number of infrastructure providers to run the service:

Supabase: database and storage (encrypted at rest, hosted on AWS)
Vercel: web application hosting
Stripe: payment processing (billing data only; no event payload data passes through Stripe)

Data residency

The service runs on EU-region infrastructure. If you have specific data residency requirements, contact hello@webhookwatchtower.co.uk before signing up to confirm the current configuration.

Account deletion

Deleting your account removes all associated data: stored events, source configurations, destination settings, and team membership records. Deletion is permanent and can't be undone. To request deletion, email hello@webhookwatchtower.co.uk.

Responsible disclosure

If you find a security vulnerability, email hello@webhookwatchtower.co.uk directly. Please don't file public issues for security problems.