User Guide

Webhook Events

Your complete record of every event Webhook Guard has received from your platform. It is organized into three tabs: Events, Duplicate Events, and Invalid Events.

On this page

Events List

The main tab shows all webhook events in reverse-chronological order. Each row displays the event topic, platform event ID, received timestamp, and overall delivery status.

Webhook Events page showing the events list with topic, event ID, platform event ID, received timestamp, matched integrations, and delivery status
The Events tab listing all incoming events with their delivery status.

Filtering Events

Use the filter bar above the list to narrow down events by:

  • Topic — Filter by a specific webhook topic using the topic dropdown.
  • Delivery Status — Show only Delivered, Failed, Pending, or Partial events.
  • Date From / Date To — Restrict results to a specific date window.

After setting filters click Apply to reload the list, or Reset to clear all filters.

Bulk Retry

If you have multiple failed events, select them using the checkboxes and click Retry Selected to re-queue all selected events for delivery at once. There is no limit on manual retries.

Event Detail

Click any event row to open its detail page. This page is divided into three parts:

Event Information

The top section shows the raw event metadata: topic, platform event ID, store, received timestamp, payload size, and the full request headers (sensitive values are partially masked for security).

Matched Integrations

Below the event metadata you see a card for every integration that was subscribed to this event's topic. Each card shows the integration name, endpoint URL, and the overall delivery status for that integration.

Delivery Attempts

Expand an integration card to see a timeline of every delivery attempt: attempt number, timestamp, HTTP response status, response time, and whether the attempt was the initial delivery or an automatic retry. A Retry button lets you manually trigger a new attempt at any time.

Event detail page showing event metadata, raw payload, matched integrations with delivery status, and a View Attempts button
The event detail page — metadata, payload, and matched integrations.
Event detail page scrolled to the delivery attempts section showing a timeline of attempt number, timestamp, HTTP status, response time, and retry button
Expanding an integration card reveals the full delivery attempt timeline.
🔁 Webhook Guard automatically retries failed deliveries up to 11 times with increasing delays (1 min → 5 min → 30 min → 2 h → 4 h → 8 h → 16 h → 24 h → 32 h → 40 h → 48 h). You can also trigger a manual retry at any time.

Duplicate Events

The Duplicates tab lists events that your platform sent more than once within a short time window. This is a known platform behaviour — platforms occasionally re-deliver the same event to ensure it was received.

Webhook Guard detects duplicates using the platform's unique event ID and does not forward them to your integrations, preventing your server from processing the same order or action twice. The tab exists purely for visibility.

Duplicate Events tab listing events that arrived more than once with topic, platform event ID, duplicate count, and timestamps
The Duplicate Events tab listing events that your platform sent more than once.

Click a row to open the duplicate event detail page, which shows all the raw duplicate copies received and their timestamps.

Invalid Events

The Invalid tab shows events that failed HMAC signature validation. Webhook Guard verifies every inbound request against your platform credentials. If the signature does not match, the event is rejected and logged here — it is never forwarded to your integrations.

Invalid Events tab listing events that failed HMAC signature verification with topic, event ID, type badge, reason, and received timestamp
The Invalid Events tab — events rejected due to failed signature verification.
🛡️ A sudden spike in invalid events may indicate someone is sending forged requests to your intake URL. Webhook Guard blocks all such requests automatically — your integrations are never exposed to unverified payloads.