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

Goal

Process Ghost CMS webhook events (member.added, subscription.created, etc.) exactly once in a downstream system despite Ghost's built-in retry mechanism, which re-sends the same payload up to 10 times over ~24 hours when the receiver returns a non-2xx response or times out.

Constraints and uncertainty

• Ghost v5.x does not include a unique event identifier (e.g., X-Ghost-Event-ID) in webhook headers or body; only the event type, ISO-8601 timestamp (second precision), and resource data are delivered.
• The internal event.id UUID exists in Ghost's event queue but is never exposed to the webhook receiver.
• No Admin API endpoint exists to query historical delivery attempts or their statuses, so a receiver cannot ask Ghost whether a given event has already been dispatched.
• Identical payloads are sent on every retry, and the timestamp alone cannot distinguish a retry from a genuinely new event of the same type on the same resource within the same second.
• Self-hosted instances cannot enable idempotency keys or adjust retry counts via configuration; only core-code changes or a proxy layer can modify this behavior.

Questions

1. What deduplication strategy reliably distinguishes a retry from a new event when only the event type, second-precision timestamp, and resource payload are available?
2. Can a reverse-proxy layer inject a stable idempotency key (e.g., derived from Ghost's internal event.id) without modifying Ghost core, and what information would that proxy need access to?
3. Does any Ghost version or fork expose the internal event UUID in webhook payloads, or is a feature request the only path to native idempotency support?