Webhooks

Webhooks let JourneyFuse push data to other tools the moment something happens — a new lead comes in, a payment is received, a trip status changes. Instead of manually copying data between systems, webhooks do it automatically in real time.

Think of it as JourneyFuse tapping another tool on the shoulder and saying "hey, this just happened" — along with all the details.

What Are Webhooks?

When an event occurs in JourneyFuse, a webhook sends an HTTP POST request with a JSON payload to a URL you specify. That URL can be:

• A Zapier or Make.com webhook trigger (no coding required)
• A custom API endpoint you've built
• Any service that accepts incoming webhooks

Each delivery includes:

• The event type (e.g., lead.created)
• A timestamp of when it happened
• The event data (lead details, trip info, payment amount, etc.)
• An HMAC-SHA256 signature so you can verify it came from JourneyFuse

Supported Events

Registering From Your Own Dashboard

You can register a receiver without Zapier using POST /api/v1/webhooks, list subscriptions with GET /api/v1/webhooks, and remove one with DELETE /api/v1/webhooks/:id. Use a public HTTPS URL and your JourneyFuse API key. The signing secret is returned once when creating the subscription. See the API reference for request and response examples.

The new document event covers generated invoice, payment_receipt, and signed_agreement resources, not arbitrary file uploads. Follow data.download_url using your API key to download the document. The authorization event contains status and record IDs, never full card credentials. Delivery can be retried; make your receiver idempotent and reconcile through the read API.

Setting Up a Webhook

1. Go to Settings → Webhooks
2. Click Add Webhook
3. Enter the Endpoint URL — this is where JourneyFuse will send data
4. Optionally add a Description so you remember what it's for
5. If the receiving tool needs its own key on every request, click Add header under Custom headers and enter it (for example Api-Token for ActiveCampaign)
6. Select which events you want to subscribe to (or click "Select All")
7. Click Add Webhook

Your webhook is now active. Use the Send test payload button to verify your endpoint is receiving data correctly.

Custom headers

Custom headers are sent with every delivery and every test, alongside JourneyFuse's own signature headers. Header values are treated like passwords: once saved, Settings shows only the last four characters. To keep a value when editing, leave its field blank; to change it, type the new value. Content-Type, User-Agent and any X-JourneyFuse- header are set by JourneyFuse and cannot be overridden.

Advisor webhooks and API keys

In a team workspace, advisors can create their own webhooks and API keys, which only ever see their own clients, leads and trips. An owner or admin can turn this off under Settings → API Keys → Advisor integrations. While it is off, advisors cannot create new ones, their API keys are refused, and their webhooks receive nothing. Nothing is deleted, so turning it back on restores them as they were.

What Your Webhook Receives

Scope follows whoever created the webhook, which matters most at a host agency where many advisors share one workspace.

So an advisor's Slack channel or Zap never sees a colleague's leads, and the agency's own reporting webhook still sees the full picture. Owners and admins see every webhook in the workspace on this page; advisors see only their own.

Example: New Leads to Slack via Zapier

Easier with the Zapier app. The JourneyFuse Zapier app has a New Lead trigger built in, so you can skip the Catch Hook setup below. The webhook route still works and is handy for events the app doesn't offer.

Want a Slack message every time a new lead comes in from your website?

1. In Zapier, create a new Zap with Webhooks by Zapier as the trigger → choose "Catch Hook"
2. Copy the webhook URL Zapier gives you
3. In JourneyFuse, go to Settings → Webhooks → Add Webhook
4. Paste the Zapier URL and subscribe to Lead Created
5. Click "Send test payload" to send sample data to Zapier
6. Back in Zapier, add a Slack action → choose your channel → map the fields:
   • Message: New lead: {{data__first_name}} {{data__last_name}} ({{data__email}}) — Source: {{data__source}}
7. Turn on the Zap

Now every website form submission instantly notifies your team in Slack.

Example: Payments to Google Sheets via Make.com

Track every payment in a shared spreadsheet automatically:

1. In Make.com, create a new scenario with Webhooks → "Custom webhook" as the trigger
2. Copy the webhook URL
3. In JourneyFuse, add a webhook subscribed to Payment Received
4. Send a test payload so Make.com can learn the data structure
5. Add a Google Sheets module → "Add a Row"
6. Map the fields: amount, payment type, paid date, trip ID
7. Activate the scenario

Every time a payment is marked as paid, a new row appears in your spreadsheet — no manual entry.

Example: Booking Confirmations to QuickBooks

Automatically create draft invoices when bookings are added:

1. Set up a Zapier webhook trigger subscribed to Booking Created
2. Add a QuickBooks Online action → "Create Invoice"
3. Map: supplier name, total price, confirmation number, dates
4. Any new booking with a price automatically generates a draft invoice in QuickBooks

Example: Task Completion to ClickUp

Keep your project management in sync — when a task is completed in JourneyFuse, automatically update ClickUp:

1. In ClickUp, go to Settings → Integrations → Webhooks or use a Make.com/Zapier connection
2. In JourneyFuse, add a webhook subscribed to Task Completed
3. In your automation tool, add a ClickUp action → "Update Task Status" or "Create Comment"
4. Map the task title and completion status

Your ClickUp board stays up-to-date without anyone switching between apps.

Example: Trip Status to HubSpot CRM

Automatically move deals through your CRM pipeline when trip stages change:

1. Set up a Zapier webhook trigger subscribed to Trip Status Changed
2. Add a HubSpot action → "Update Deal Stage"
3. Map the trip status to your deal stages: lead → qualified → booked → won
4. Every status change in JourneyFuse automatically updates the CRM

Your sales pipeline stays accurate with zero manual entry.

Example: Insurance Declination to an E-Signature Waiver

If your client agreements require a signed waiver whenever someone declines travel insurance, this fires the moment they decline so you are not watching for it by hand:

1. Add a webhook subscribed to Travel Insurance Answered
2. In Make.com or Zapier, filter on declined being true (or response equal to declined)
3. Add an action in your e-signature tool → "Send document for signature", addressed to signer_email
4. Map signer_name, trip_id, and responded_at onto the document

The payload carries the whole answer:

{
  "event": "insurance.responded",
  "data": {
    "acknowledgment_id": "a1b2c3d4-...",
    "trip_id": "c3d4e5f6-...",
    "client_id": "b2c3d4e5-...",
    "response": "declined",
    "declined": true,
    "signer_name": "Jamie Rivera",
    "signer_email": "jamie@example.com",
    "responded_at": "2026-09-01T18:22:10.000Z",
    "source": "proposal",
    "coverage_carrier": null,
    "coverage_policy_number": null,
    "coverage_expiration": null
  }
}

response is one of declined, quote_requested, or has_coverage. The three coverage_* fields carry the client's existing policy details on has_coverage and are null otherwise, so you can map them once and they will be there whichever answer comes through. source tells you where it was captured: proposal, invoice, or waiver_link for a waiver you sent directly.

JourneyFuse keeps its own signed record of the declination either way — name, timestamp, IP address, and a hash of the exact wording the client saw — on the trip and the client. The webhook is for driving your own paperwork on top of it.

Example: Form Submissions to Your CRM or Spreadsheet

Form Submitted fires each time a client submits one of your forms, so promo codes, referral codes and every other answer reach your other tools without a CSV export:

1. Add a webhook subscribed to Form Submitted (or pick it as the trigger in Zapier)
2. Filter on form_id (or form_name) to the one form you care about
3. Map submitter.email, submitter.name, submitted_at, and the answers you need

{
  "event": "form.submitted",
  "data": {
    "id": "d4e5f6a7-...",
    "form_id": "bdefdd50-...",
    "form_name": "Extra Perks",
    "submitted_at": "2026-10-03T18:22:10.000Z",
    "status": "new",
    "submitter": { "name": "Jamie Rivera", "first_name": "Jamie", "last_name": "Rivera", "email": "jamie@example.com", "phone": "+15555550100" },
    "answers": [
      { "field_id": "f1", "label": "Promo code", "type": "text", "value": "SPRING10" }
    ],
    "lead_id": null,
    "client_id": "b2c3d4e5-...",
    "trip_id": null,
    "source_tag": null
  }
}

Every question on the form appears in answers with its label, even when left blank (value is ""), so a mapping built from one submission holds for the next. Passport-style numbers are masked and a signature reads Signed. Submissions caught as spam never fire. To pull past submissions, use GET /api/v1/form-submissions (see the API article); it returns the same record.

Security: Verifying Webhook Signatures

Every webhook delivery includes an X-JourneyFuse-Signature header containing an HMAC-SHA256 hash of the request body, signed with your webhook's secret key. If you're building a custom integration, you should verify this signature to ensure the request actually came from JourneyFuse.

Your webhook secret is generated automatically when you create a webhook and is visible in the webhook settings.

Every delivery also carries:

• event_id in the body and an X-JourneyFuse-Event-Id header — one id per event, the same on every webhook that receives it and on any resend. If your receiver might see the same event twice, skip any event_id it has already handled.
• X-JourneyFuse-Timestamp — when the event happened. Rejecting deliveries older than a few minutes protects a custom receiver against a replayed request.
• X-JourneyFuse-Redelivery: true when the delivery was sent again with Resend.

Delivery History

Each webhook shows its recent delivery history — you can see:

• Which events were sent
• The HTTP status code from your endpoint
• Whether delivery succeeded or failed
• When each delivery was attempted

If a delivery fails (your endpoint returns a non-2xx status or times out), JourneyFuse records the failure. Each delivery is retried up to 3 times immediately for temporary problems — a timeout, a network error, or a 5xx from your endpoint.

Once you have fixed the receiving end, click Resend on any delivery in the history to send that exact event again. It keeps its original event_id, so a receiver that skips duplicates will not create a second record.

When an endpoint stops responding

A webhook is never switched off because it failed. If your endpoint rejects 15 deliveries in a row — usually because the Zap was turned off, or the URL was deleted or changed — the webhook stays on but goes into a cooldown, and you'll see a red Retrying badge with the time of the next attempt.

While it's in cooldown we keep trying on a widening schedule (starting a minute out, up to once an hour). The moment one delivery succeeds, everything resets and normal delivery resumes on its own — there's nothing to switch back on. If you've just fixed your endpoint and don't want to wait, hit Send test: a successful test clears the cooldown immediately.

Events that occur while a webhook is in cooldown are not queued or replayed. If your endpoint was down for a while, check the delivery history to see what you missed.

A burst of events is the usual culprit. A large import or bulk update can fire hundreds of events at once, and Zapier and Make.com will throttle or switch off a hook that gets flooded — that's the most common reason a working webhook suddenly starts failing. If one goes into cooldown right after a big change on your side, check whether the Zap itself is still turned on.

Tips

• Start with one event — get it working, then add more
• Use the test button before relying on a webhook in production
• Zapier and Make.com are the easiest way to connect webhooks without any coding
• Disable rather than delete — use the toggle switch to pause a webhook temporarily without losing your configuration. The toggle is now the only thing that turns a webhook off; we never do it for you
• If your endpoint is down, deliveries fail and the webhook backs off rather than switching off — check your delivery history if you suspect missed events