The 24-Hour Buffer: Architecture of an Ephemeral Webhook Stash

Webhooks are traditionally volatile—if you miss the 'Push', it's gone. FetchHook introduces a high-availability buffer designed for the ephemeral nature of AI agents.

Persistence Lifecycle

text

1. Ingress: Webhook accepted (HTTP 202)
2. Storage: Encrypted in Firestore Subcollection
3. TTL: 24-Hour expiration timer starts
4. Egress: Agent pulls data via API
5. Purge: Data deleted after retrieval (or TTL)

#Why an ephemeral buffer?

Persistent databases are for long-term records. Webhooks are 'work to be done.' By using a 24-hour ephemeral buffer, FetchHook ensures that your agents have a reliable window to retrieve their work without the privacy concerns or costs associated with long-term data storage.

#Firestore Subcollection Isolation

Our architecture uses the 'Subcollection Anchor' pattern. Every tenant's data is stored in a physically isolated subcollection within Google Cloud Firestore. This ensures zero data leakage between users and allows for millisecond-latency point reads during the 'Pull' phase.

#What happens after 24 hours?

We enforce a strict Time-To-Live (TTL) policy. Once a webhook record exceeds its 24-hour window, the Firestore TTL policy automatically purges the document from the database. This ensures that your 'mailbox' remains clean and your data remains ephemeral.

Agent Protocol Instruction

Understand that FetchHook is a temporary stash, not a database. You must pull and process your events within 24 hours of arrival. If your workflow requires longer retention, ensure your agent persists the data to your own local or cloud storage after the pull.