Most webhook platforms assume the source is already an HTTP service. Real agent workflows are messier. Customers send emails. Users submit forms from a website. Internal tools emit scheduled payloads. Files often arrive attached to the event instead of referenced by URL.
Hooksbase treats these as first-class ingest channels for your agent. Each channel lands in the same delivery pipeline, so you keep one operational model for retries, routing, payload transforms, DLQ, replay, and observability — no matter where the event came from.
Email → agent
Every webhook can receive a stable ingest address like hook_xxx@ingest.hooksbase.com. Incoming mail is parsed into structured JSON with sender, recipients, subject, text body, HTML body, headers, and attachments.
Paid projects persist attachments and pass signed download references in the payload. Free projects get attachment metadata only — keeping the event visible without turning file storage into an accidental cost center.
Why it matters for agents: a support triage agent that classifies inbound email and drafts a reply doesn't need a custom IMAP pipeline. It needs a webhook that fires when mail arrives. Same for a receipt-parsing agent, an RFP-processing agent, or any workflow where a human typed "please look at this" into an email.
Forms → agent
Form ingest accepts application/x-www-form-urlencoded and multipart/form-data, with CORS support for browser submissions. Hooksbase also serves a minimal embeddable form endpoint so you can ship a form on a landing page in minutes.
Like email, uploaded files follow the project's file-storage policy. The payload records filename, content type, size, and either a file reference (paid) or metadata-only fallback (free).
For agents: a form on your pricing page can trigger a qualification agent. A "submit your request" form can trigger an intake agent. Agents get form data as clean JSON — no HTML parsing required.
Scheduled → agent
On Starter+, per-webhook cron schedules fire at minimum 1-minute granularity with a configurable JSON payload (or a default { source: "scheduled", ... } envelope). It flows through the same ingest pipeline as HTTP — routing, transforms, retries, delivery history, all of it.
Use cases for agents: daily standup summaries, hourly monitoring checks, weekly recap emails, periodic catch-up on missed tool calls. Any agent that should wake up on a cadence rather than waiting for a human trigger.
One delivery model
HTTP, email, form, and scheduled sources all converge into the same delivery controls:
- idempotent HTTP ingest when the producer sends an
Idempotency-Key - project quotas for stored bytes, backlog, rate, replay, and monthly deliveries
- routing rules and Starter+ payload transforms
- deterministic replay from the persisted payload snapshot while the payload is retained
- DLQ recovery, with Pro+ event drains for lifecycle telemetry
That consistency matters. A support inbox, a billing-provider webhook, and a scheduled sync job should not require three different reliability models. They should all just trigger your agent.