Ghost webhook retries lack idempotency keys — how to reliably deduplicate duplicate deliveries?

Short answer

You cannot reliably distinguish a Ghost retry from a new event using only the exposed webhook fields. Ghost v5.x does not transmit the internal event.id, so an identical payload may be a retry or a legitimate same-second event. The dependable fix is consumer-side idempotency: assume duplication, key processing on Ghost’s resource ID, and return 2xx only after the result is durably stored.

Why a reverse proxy cannot inject the missing key

A reverse proxy cannot derive Ghost’s internal event.id because that UUID is never present in the HTTP request. It would need direct access to Ghost’s internal event queue or a core-code change that adds the ID to a header. A proxy can hash headers and body for logging, but that hash cannot separate a retry from a new event when both produce identical bytes within the same second.

Consumer-side deduplication steps

1. Accept the webhook and durably record the raw payload in a dedup table or queue keyed by event_type, resource_id, and a SHA-256 hash of the body.
2. Before applying side effects, check whether the same (event_type, resource_id, body_hash) was processed within a retention window, such as 24–48 hours to cover Ghost’s retry period. If it was, return 2xx without further action.
3. Make the downstream mutation idempotent by upserting on Ghost’s resource ID instead of inserting blindly.
4. Return 2xx only after the dedup record and the business write are committed. A crash between those writes may repeat the business write on retry, but the upsert keeps that safe.

Assumptions and verification

This method assumes Ghost v5.x self-hosted behavior; retry timing may differ on Ghost(Pro) or other versions. It can also drop a legitimate new event if it shares the same type, resource, and body as a recent delivery within the same second. Before relying on this design, verify:

• Whether your instance actually retries up to 10 times over roughly 24 hours.
• Whether any delivery header, such as X-Ghost-Event-ID, appears in a sample webhook; use it as the dedup key if present.
• Whether your downstream system can upsert by Ghost resource ID, or whether it requires true event-level exactly-once processing.

If the downstream system cannot tolerate dropped events and cannot upsert by resource ID, native idempotency requires exposing Ghost’s internal event.id. No standard Ghost release is known to include it in webhook payloads, so a feature request or core modification is the likely path.