Ingest

Ingest is the first step of the webhook lifecycle in Hooksbase: accepting an event into the relay. Once an event is ingested, it's persisted, queued for delivery, and routed to the selected destination.

Hooksbase supports four ingest channels:

• HTTP webhooks — POST /v1/ingest/{webhook-id}, authenticated with the webhook's bearer ingest secret
• Email — each webhook gets a dedicated address hook_<id>@ingest.hooksbase.com
• HTML forms — POST /v1/form/{webhook-id} accepting multipart and CORS
• Scheduled cron — Starter+ per-webhook recurring trigger with a configurable static payload template

All four channels normalize to the same internal event shape, so downstream routing, transforms, retries, and observability work identically regardless of how the event arrived.

What happens during ingest

For every ingest:

1. Authentication — HTTP ingest checks the Hooksbase bearer ingest secret; configured provider signatures are verified after that; for other providers, verify before ingest in a forwarder if you need native provider signature checks
2. Idempotency check — for HTTP ingest, honor the Idempotency-Key header and refuse duplicates before quota admission
3. Quota admission — check ingest rate limit; reject with 429 if exceeded
4. Payload persistence — store the raw bytes for later replay
5. Delivery scheduling — create a delivery record for the resolved destination

Once these steps complete, the relay responds 2xx to the producer. Actual delivery to your endpoints happens asynchronously.

Why decoupling ingest from delivery matters

The producer (Stripe, your form, your cron) sees a fast 2xx as soon as ingest succeeds. Whether your destination is fast, slow, or temporarily down doesn't affect the producer's experience. Delivery is the relay's problem from that point forward.

For deeper reading: Event infrastructure for AI agents.