Hook Lifecycle
Schedule
You call
POST /hooks with a path, payload, and a time. The hook is immediately committed to a durable message queue before the API returns 201. This guarantees your hook is safely accepted even during traffic spikes or database maintenance.Persist
The hook is pulled off the queue and written to a high-availability PostgreSQL cluster for long-term tracking and dashboard visibility.
Deliver
The hook is picked up from the outgoing queue. Before making the HTTP request, a distributed lock is acquired to minimize duplicate deliveries. The request includes your payload, hook metadata, and cryptographic signatures.
Resolve
- 2xx →
completed. Delivery is done. - Non-2xx or timeout →
retry. Retries follow your retry configuration. After exhausting all attempts →failedand a notification is sent.
Hook Statuses
The API exposes four statuses. Internal states (like dispatching or in-flight) are abstracted intopending.
| Status | Meaning |
|---|---|
pending | Scheduled and waiting for delivery time, or currently in-flight. |
retry | Delivery failed. Waiting for the next retry attempt. |
completed | Delivered successfully (2xx response). Terminal. |
failed | All retries exhausted. Terminal. |
Multi-Zone Redundancy
All infrastructure runs across multiple availability zones within a region:- Compute — Kubernetes cluster with automatic rescheduling on zone failure.
- Messaging — Google Cloud Pub/Sub, a global service with no single zone dependency.
- Storage — PostgreSQL with synchronous replication and automatic failover.
- Caching and Locking — Valkey with replicas across zones for deduplication availability.