Hooksbase

Integrations / April 19, 2026

Connect Make to Hooksbase

Make scenario connected to Hooksbase

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

Related guides

Back to guides