General
Quick start guideWhat is Webhook Watchtower?
Webhook Watchtower is a webhook monitoring and delivery platform. You point your webhook sources (Stripe, GitHub, Shopify, or any custom source) at a Watchtower ingest URL instead of directly at your application. We verify the signature, log the full payload, forward it to your destination endpoint, and handle retries if delivery fails. Every event is stored so you can inspect, replay, or debug it at any time.
Who is it for?
Any development team that relies on webhook integrations in production. That includes payments with Stripe, CI/CD events from GitHub, e-commerce events from Shopify, or any custom provider. It is especially useful if you have ever had a webhook silently fail, struggled to reproduce a bug because you could not see the original payload, or needed to replay events after a deployment.
Do I need to change my application code to use Webhook Watchtower?
Mostly no. The only change required is updating the webhook URL in your provider's dashboard to point at your Watchtower ingest URL instead of your application directly. If you want us to handle signature verification, you can remove that logic from your own endpoint. We verify on receipt and stamp each event as verified before forwarding. If you prefer to keep your own verification, that works too.
What webhook providers does Webhook Watchtower support?
Built-in presets cover Stripe, GitHub, and Shopify. Each preset handles the correct signature algorithm automatically and enables provider-specific duplicate event detection. Any custom HMAC-SHA256 source is also supported for internal services or providers not in the preset list. When creating a source, choose your provider from the picker to get the right defaults set up immediately. See the supported providers guide for a full breakdown.
How long does it take to set up Webhook Watchtower?
Most teams are up and running in under ten minutes. Create a workspace, add a source for your provider, copy the generated ingest URL, paste it into your provider's webhook dashboard, and add a destination URL pointing at your endpoint. No code changes required. Once the first event arrives you will see it in the dashboard with delivery status and payload details.
Is Webhook Watchtower suitable for production use?
Yes, with the right level of caution. It is designed to sit in front of real webhook integrations: events are stored durably, delivery is handled asynchronously with retries, and the ingest layer acknowledges requests immediately to avoid provider-side timeout failures. Today we recommend it as a strong fit for early production use and controlled rollout rather than as a fully battle-tested enterprise platform.
Sources and Destinations
Sources and destinations docsWhat is a source?
A source represents an incoming webhook feed, typically one provider or one application sending webhooks to you. Each source gets a unique ingest URL. You configure that URL in your provider's dashboard, and all events from that provider arrive through that source. You can have multiple sources per workspace, for example one for Stripe live, one for Stripe test, and one for GitHub.
What is a destination?
A destination is a URL in your own infrastructure that receives forwarded events. When an event arrives at a source, it is delivered to all destinations attached to that source. A single source can have multiple destinations, which is useful for fanning out to different services or environments.
Can one source fan out to multiple destinations?
Yes. Attach as many destinations as you need to a single source. Each event is delivered to all active destinations independently, so a failure to one destination does not affect delivery to the others.
Can I send the same webhook source to different environments (staging and production)?
Yes. Add multiple destinations to a single source, one pointing at your production endpoint and one at staging. Both receive every event independently. You can also disable a destination temporarily without removing it, which is useful for pausing staging delivery during a deploy without affecting production.
Can I use Webhook Watchtower in my local development environment?
Yes. Set your local dev server URL (exposed via a tunnelling tool like ngrok or Cloudflare Tunnel) as a destination, then point your provider at your Watchtower ingest URL. Events will be forwarded to your local machine. You can also replay past events directly from the dashboard, removing the need to trigger test events from your provider repeatedly during development.
Retries and Delivery
Retries and delivery docsWhat happens if my endpoint is unavailable when a webhook arrives?
The event is accepted immediately and acknowledged to your provider, so nothing is lost at the ingest layer. Delivery to your destination then happens asynchronously. If your endpoint returns a non-2xx status or times out, the delivery is marked as failed and retried according to your workspace’s plan and retry settings.
How does the retry logic work?
Retry waits are fixed: 1 minute, 5 minutes, 30 minutes, then 2 hours, with no random jitter. Current defaults include the first attempt: Scout 1, Guard 3, Sentinel 5, and Bastion 5. A workspace override can lower the plan ceiling. Scout has no automatic retries.
What happens when all retries are exhausted?
Once the final attempt fails, the delivery is marked permanently failed. Five consecutive exhausted deliveries open the destination circuit and trigger email and in-app alerts. On eligible plans, you can replay the payload while it remains within retention.
Can I manually replay a failed event?
On Guard, Sentinel, and Bastion, retained events can be replayed whether they succeeded, failed, or had no previous delivery. Choose active destinations, including new ones in the event’s project. In-flight deliveries are skipped and failed source verification blocks replay. Original provider signatures may fail freshness checks on delayed replay; use a receiver that verifies Watchtower authentication for historical processing.
How long are events stored?
Retention depends on your plan: 1 day on Scout, 7 days on Guard, 30 days on Sentinel, and 90 days on Bastion. The full payload, headers, delivery attempts, and response codes are available for any stored event throughout that window.
Can the same webhook event be delivered more than once?
Watchtower detects duplicate events automatically and does not forward them to your destinations. For Stripe, GitHub, and Shopify it uses the provider's own event ID headers (evt_xxx in Stripe, X-GitHub-Delivery in GitHub, X-Shopify-Webhook-Id in Shopify), so detection is exact regardless of payload content. For custom sources it falls back to a body hash within a 24-hour window. Duplicates are stored with a Duplicate label linking back to the original, and they do not count toward your monthly usage. Because Watchtower returns 200 to providers immediately, provider-side retries are rare. If they do happen, your downstream services won't see the same event twice.
How do I get alerted when a webhook delivery fails?
A notification is sent when all retry attempts for an event are exhausted. You receive it by email and as an in-app alert in your dashboard. Notification preferences can be configured per workspace. Transient failures that resolve within the retry window are handled silently, so you only hear about things that genuinely need attention.
What timeout does Webhook Watchtower use when delivering to my endpoint?
Delivery attempts time out after 10 seconds. If your endpoint does not respond within that window, the attempt counts as a failure and is retried. To avoid timeouts, your endpoint should return a 200 immediately and process the payload asynchronously. This is best practice for any webhook handler regardless of what tooling you use.
Debugging
Debugging guideHow do I debug a webhook that is not arriving?
Start in the dashboard. If the event appears in your source log with a delivery status, the ingest is working and the issue is between Watchtower and your destination endpoint. Check the delivery attempt details for the exact HTTP status or error returned. If the event does not appear in the source log at all, the issue is upstream. Check that the ingest URL in your provider's dashboard is correct and that your provider is actually firing the event. Common culprits are a stale URL, an incorrect environment (test vs live), or an event type that is not enabled.
My Stripe webhook is not being received. Where do I start?
Check the Stripe Dashboard under Developers, then Webhooks, then your endpoint. Stripe shows every delivery attempt with the response code and body your server returned. If Stripe shows a successful delivery (2xx) but nothing appears in the dashboard, the URL may be pointing somewhere else. If Stripe shows a failure, look at the status code: 401 or 403 usually means auth middleware is blocking the request; 400 often means signature verification is failing; timeout means your endpoint took longer than 30 seconds to respond. If the event arrived but was not forwarded, check the delivery status in the event detail view. For a full walkthrough, see our Stripe webhooks guide.
My GitHub webhook is not firing. How do I investigate?
In GitHub, go to your repository or organisation settings, then Webhooks, then your endpoint, then Recent Deliveries. GitHub shows each delivery attempt, the request payload, and the response. A 200 from the ingest URL means it arrived successfully. Check the event in your dashboard for forwarding status. If GitHub shows a non-2xx or timeout, verify that the ingest URL is correct and that no firewall or proxy is blocking inbound requests. If you see verification failures, double-check that the secret in your source settings matches the one configured in GitHub exactly, including any trailing whitespace. The GitHub webhooks guide goes through setup and verification step by step.
Can I inspect the full raw payload of a received webhook?
Yes. Every stored event includes the full raw request body, headers, source IP, timestamp, verification status, and the complete delivery history including response codes and response bodies from your endpoint. This is available from the event detail view at any time, including for events that were delivered successfully weeks ago.
Security
Security and data docIs my webhook payload data secure?
Yes. All data is encrypted in transit over HTTPS. Stored event payloads are encrypted at rest. Access to your workspace data is restricted to members you have explicitly invited. Signing secrets are stored encrypted and are never displayed in full after initial entry.
Does Webhook Watchtower support IP allowlisting?
Most webhook providers publish a list of IP addresses they send from. IP allowlisting at the ingest layer is not currently supported, but HMAC signature verification provides the same security guarantee: only requests signed with your shared secret are accepted, regardless of origin IP. If IP allowlisting is a hard requirement for your infrastructure, you can configure it at your own destination endpoint instead.
What happens to my data if I cancel my account?
Stored events, source configurations, and destination settings are retained for a short grace period after cancellation so you can export anything you need. After the grace period, all data is permanently deleted. If you need a specific export before deletion, contact hello@webhookwatchtower.co.uk.
Can I hide sensitive headers and payload fields in the event viewer?
Yes. Each source has a Data masking setting that hides sensitive values in the dashboard without affecting delivery. When masking is on, auth headers (Authorization, Cookie, X-Api-Key) and provider signature headers are replaced with [redacted]. You can add extra header names and dot-notation JSON field paths (e.g. data.card.number) to extend the list for that source. Raw data is always preserved for forwarding to your destinations.
Does masking affect what gets forwarded to my destination?
No. Masking is display-only. The original payload and headers are forwarded to your destination exactly as received. The only thing that changes is what gets rendered in the Watchtower event viewer. Your downstream handler sees the full, unmodified request.
HMAC Signature Verification
Signature verification docsWhat is HMAC signature verification and why does it matter?
Your webhook ingest URL is a public endpoint that accepts POST requests. Without verification, anyone who knows the URL can send fake events and trigger real actions in your application. HMAC signature verification solves this: the provider signs each request with a secret key shared only between you and them. On receipt, we compute the expected signature and reject any request that does not match before the event is forwarded to your endpoint. Our guide to webhook signature verification covers the HMAC pattern in more depth.
How does HMAC-SHA256 verification work?
The provider computes an HMAC-SHA256 hash of the raw request body using a shared secret and includes it in a request header. On receipt, the same hash is computed using your configured secret and the two values are compared using a timing-safe comparison. If they match, the request is stamped Verified. If they do not, it is stamped Failed. It is stored and only blocked from forwarding when Reject invalid signatures is enabled.
What providers does automatic signature verification support?
Built-in verification covers Stripe (timestamp-prefixed HMAC-SHA256), GitHub (sha256=hex format), and Shopify (base64-encoded HMAC-SHA256). For custom sources, you configure the header name and secret and standard HMAC-SHA256 hex signatures are verified.
What does the Verified / Failed / Skipped stamp mean?
Verified means the configured provider checks passed. Failed includes missing, mismatched, or stale signatures; forwarding is blocked only when Reject invalid signatures is enabled. Skipped means custom verification found no recognized signature header. Sources without configured verification may have no stamp; neither an absent stamp nor Skipped means trusted.
Why might a webhook fail signature verification even though I set the correct secret?
The most common cause is a mismatch between the raw bytes the provider signed and what is being verified. This can happen if a proxy or load balancer modifies the request body before it arrives. Verification is always performed against the exact raw bytes received. If you are seeing consistent verification failures for a provider you know is sending correct requests, check that no intermediate layer is re-encoding or modifying the body, and confirm that the secret in your source settings matches the one in your provider's dashboard exactly, with no extra whitespace.
Does Webhook Watchtower re-sign events when forwarding them to my endpoint?
No. Events are forwarded with the original headers intact, including the original provider signature header. Your endpoint can still verify the signature independently if you want a second layer of verification. Alternatively, you can rely entirely on the verification performed at ingest and skip it in your own code.
Account and Workspaces
Workspaces and teams docsWhat is a workspace?
A workspace is an isolated container for your sources, destinations, events, and team members. Most teams use a single workspace. Separate workspaces make sense if you manage webhook infrastructure for multiple clients or distinct projects that should not share access.
Can I invite team members to my workspace?
Yes. Invite team members by email from within your workspace settings. Invited members get access to the workspace's sources, destinations, and event logs.
How do I change my email address or password?
Both can be updated from your account settings. If you signed up using a magic link or OAuth, you may need to set a password separately before email and password login becomes available.
How do I delete my account?
Send a deletion request to hello@webhookwatchtower.co.uk. Deletion removes all associated data including stored events, source configurations, and destination settings.
Billing and Plans
Billing and plans docsHow does billing work?
Paid plans can be billed monthly or annually. Plans differ in the number of sources, destinations, events per month, and retention period. You can view and manage your plan from the billing section of your workspace settings.
What happens if I exceed my plan limits?
A warning notification is sent before you reach your monthly event limit. Once the limit is reached, new ingest requests receive HTTP 403 before storage. Upgrade or wait for the UTC calendar-month reset, then request provider resends as needed. Rejected events cannot be replayed from Watchtower; GitHub does not automatically redeliver failures.
Can I cancel at any time?
Yes. Cancel your subscription at any time from your workspace billing settings. Your plan remains active until the end of the current billing period, after which your workspace moves to the free tier. Stored events are retained for a short grace period after cancellation.
Do you offer a free trial?
Yes. You can get started without a credit card. The free tier includes a limited number of sources and events per month, which is enough to evaluate the platform on a real integration before committing to a paid plan.
Looking for more detail?
The help docs cover setup guides, provider-specific walkthroughs, debugging steps, and billing in full.