Integrations / April 19, 2026

Connect Make to Hooksbase

Channel map diagram showing HTTP, email, forms, and schedules feeding one delivery path

Make scenarios start with a webhook trigger module. That trigger does the bare minimum — accept POST, run the scenario. What Make doesn't ship: signature verification, deterministic replay, DLQ, email or form ingest as first-class triggers. Put Hooksbase in front and your scenarios inherit all of it.

Architecture

[Event sources]
   ↓ (HTTP, email, form, cron)
[Hooksbase]
   ↓ verifies supported providers after ingest auth, routes, transforms, retries
   ↓ (HTTP webhook to Make)
[Make scenario]
   ↓
[Scenario output]

Step 1: Get your Make webhook URL

In Make, create a new scenario and add a Custom webhook trigger. Copy the URL — it looks like:

https://hook.eu1.make.com/abcdef123456

(Region prefix differs by Make data center.)

Step 2: Create the Hooksbase webhook

  1. Sign in to Hooksbase, create a project
  2. Create a webhook with the Make URL as the destination
  3. (Optional) Configure a provider pack — Stripe / GitHub / Clerk / Slack / Resend — so signatures are verified before the scenario runs after the request passes Hooksbase ingest auth
  4. Save — Hooksbase gives you a public HTTP ingest URL, a form ingest URL, and an email ingest address

Step 3: Point your event sources at Hooksbase

Take the Hooksbase HTTP ingest URL and send generic HTTP producers to it with Authorization: Bearer <ingest secret>. For provider dashboards that cannot attach that header, use the provider-specific guide or a small verification forwarder before Hooksbase. For email triggers, use the generated hook_xxx@ingest.hooksbase.com address. For embedded forms, use the form ingest URL.

Step 4: Verify the flow

Send a test event:

curl -X POST https://hooks.hooksbase.com/v1/ingest/YOUR_PUBLIC_ID \
  -H "Authorization: Bearer whsec_..." \
  -H "Content-Type: application/json" \
  -d '{"event": "test.scenario", "data": {"from": "hooksbase"}}'

The Hooksbase delivery should land with status succeeded. The Make scenario history should show a fresh execution.

What your Make scenario receives

Hooksbase does not automatically wrap the body with provider metadata. With a provider pack configured, provider metadata is persisted on the delivery and available to routing/search/replay metadata, while Make receives the original provider payload unless you configure a payload transform over that payload.

Transforms do not currently inject the provider metadata object, so use provider fields that already exist in the payload or add enrichment inside the scenario if you need that metadata in Make modules.

Use a Starter+ JSON transform if your Make scenario needs a custom envelope.

What you get out of the box

  • Signature verification via Starter+ provider packs for supported providers — no need for a Make HTTP module that re-runs HMAC
  • Multi-channel ingest — your Make scenario can be triggered by email or form submissions
  • Deterministic replay — failed Make runs can be replayed with the exact same input bytes while the payload is retained
  • DLQ + Starter+ bulk re-drive — fix the scenario and bulk-replay the affected window
  • Custom retry policy (Starter+) — tighter retries when Make is rate-limited
  • Throttling (Pro+) — cap dispatch rate when a scenario can take 30+ seconds
  • Strict FIFO (Pro+) — for scenarios that must process events in order

Why route through Hooksbase even if Make has retries?

Make's built-in retries are scenario-level — they re-run the whole scenario if the trigger module is the failure point. They don't help when:

  • A signature was invalid (you don't want the scenario to run at all)
  • A downstream step in the scenario failed (Make doesn't retry from the trigger)
  • You want to re-process events from yesterday after fixing a bug
  • You want to route different event classes to different scenarios without putting all branching inside Make

Hooksbase handles all four cases at the layer above Make.

What next

Frequently asked questions

Why route through an event layer when Make already retries?

Because Make's retry starts after the scenario has been triggered. It does not verify a provider signature before the scenario runs, does not give you a dead-letter path for events that exhausted their attempts, and does not replay a past event deterministically. Those are properties of the ingest path rather than the scenario.

Does this replace a Make scenario?

No. The scenario keeps doing the work; the event layer in front of it handles verification, retries, replay, and ingest channels Make's webhook trigger does not cover, such as email and forms.

What is Hooksbase?

Hooksbase is event infrastructure for AI agents. It ingests events over four channels — HTTP, email, HTML form, and scheduled cron — verifies them, routes them by rule, runs versioned Automations in the event path, and delivers them to HTTP and cloud destinations (AWS SQS, AWS EventBridge, GCP Pub/Sub, and S3-compatible storage) with retries, strict ordering, Standard Webhooks-compatible signing, deterministic replay, and a dead-letter path. It is a hosted service, runs on Cloudflare Workers, is operated at hooksbase.com, and is not affiliated with — and shares no code or ownership with — other similarly named webhook, hook, or tunnelling tools.

Related guides