Event sources
Four ways an event reaches your agent.
Hooksbase accepts events through four ingest channels — HTTP, inbound email, HTML form post, and scheduled cron — and all four produce the same kind of delivery, so routing rules, Automations, retries, Standard Webhooks-compatible signing, delivery history, deterministic replay, and dead-letter handling work identically no matter how the event arrived.
Most event tooling speaks HTTP and nothing else. Real work arrives by other routes — a vendor who can only send mail, a human filling in a form, a job that has to run at 3am whether or not anyone triggers it.
The four channels
| Channel | Who produces the event | Access credential | Availability |
|---|---|---|---|
| HTTP ingest | Any service that can POST | Bearer ingest secret | All plans |
| A mailbox or a vendor that only sends mail | The generated ingest address | All plans. Allowlist writes Starter+ | |
| Form | A browser posting an HTML form | The unguessable form URL | All plans |
| Scheduled cron | No producer — Hooksbase fires it | None. Configured on the webhook | Starter and above |
A large share of real business signal never arrives over HTTP. Support requests, vendor invoices, contract responses, and confirmations from older systems arrive by email. An agent that cannot read a mailbox is cut off from most of that work.
Email to webhookAgents need to wake up on their own — a nightly reconciliation, an hourly freshness check, a catch-up pass after an outage. That is usually where a separate cron service gets bolted on, with its own retry semantics, its own history, and its own way of failing.
Scheduled webhooksSometimes the producer is a browser, not a server — an internal tool, a lightweight embed, or a system that can only post a traditional form. That should not require standing up a backend just to catch the submission.
Form to webhookThe reliability layer is not per-channel.
Assembling this from point tools means a form backend, an inbound email parser, and a cron service, each with its own retry semantics, its own history, and its own way of failing quietly. In Hooksbase a form submission and a Stripe webhook are the same kind of object, so there is one place to look when something did not arrive, and one replay mechanism that works on all of it.
One deliberate limit worth stating: routing selects exactly one destination per delivery. The first matching rule by priority wins and unmatched traffic falls through to the default destination. There is no fan-out to several destinations at once.
Frequently asked questions
- What can trigger a Hooksbase webhook?
- Four things: an HTTP POST to the ingest URL, an email sent to the webhook’s generated address, an HTML form posted to its form URL, or a cron schedule attached to the webhook. All four create the same kind of delivery.
- Do the non-HTTP channels get the same reliability features?
- Yes. Retries, Standard Webhooks-compatible signing, routing rules, Automations, delivery history, analytics, deterministic replay, and the dead-letter path apply to every channel. There is no reduced path for email, form, or scheduled events.
- Can one webhook use more than one channel at a time?
- Yes. A single webhook can accept HTTP ingest, receive email at its generated address, take form posts, and carry cron schedules simultaneously. They all resolve to the same destination and routing configuration.
- How does my consumer know which channel an event came from?
- The parsed payload identifies the channel — email-sourced events carry source set to email, for example — so routing rules can match on it and send different channels to different destinations.
- Which channels are available on the free plan?
- HTTP, email, and form ingest are available on every plan including Free. Scheduled cron requires Starter or above, and writing email sender-allowlist entries also requires Starter or above.
- Can an event from any channel reach a cloud destination?
- Yes. Typed outbound destinations — AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage — are available to every ingest channel, so an inbound email or a cron firing can land in a message destination without an HTTP hop. Non-HTTP destinations require Pro or above.
Start with whichever channel you already have
5,000 deliveries a month on the free plan, no card. HTTP, email, and form ingest are available immediately on any webhook you create.