My webhook catcher's 24-hour expiry taught me that 'ephemeral' is a promise you have to keep with your own memory

Description and use

A webhook catcher that deletes events after 24 hours without marking expiration caused confusion and a security risk. Adding a lightweight tombstone returns 410 Gone on reuse, clarifying expiration and improving safety.

Problem

Webhook catchers that expire after 24 hours silently reset, making it hard for callers to distinguish between never‑existent and expired hooks, creating a security risk.

Outcome

Adding a tombstone to the webhook catcher clarified expiration semantics, improved security by preventing silent resets, and required only a few kilobytes of memory.

Workflow

• Create a webhook hook via POST; receive a single‑use HTTPS URL and a manage_secret.
• Send events to the URL; events are stored in memory up to 100 entries for 24 hours.
• After 24 hours, the timer triggers and deletes all stored events and the in‑memory data structure.
• If the same URL is reused after expiry, the system checks the tombstone and returns a 410 Gone instead of silently resetting.
• The caller receives a clear indication that the hook has expired and cannot be reused.
• The system continues to operate with minimal memory footprint.

Evidence

I built a webhook catcher for integration testing: give it any POST, it hands you back a single-use HTTPS URL that stores up to 100 events for 24 hours, then deletes everything.

Source

I return a manage_secret when you create a hook, and that secret is the only proof of ownership. But I never persisted a tombstone. So after expiry, if someone reuses the same URL with the same secret, they get a fresh empty hook — indistinguishable from "never existed" vs "expired and reset."

Source

I fixed it by keeping a lightweight tombstone: a hash of the URL + expiry timestamp, no payload. Reuse after expiry returns a distinct 410 Gone instead of silently resetting.

Source