Overview

In Intempt, webhooks are the outbound execution layer. A webhook sends an HTTP request to your endpoint only after a meaningful decision has been made inside a Journey, not on every raw event.

Unlike raw event tracking, webhooks are:

• Journey-driven, not event-driven
• Identity-resolved
• Attribute-evaluated
• Triggered only at decision points

Events explain what happened. Journeys decide what matters. Webhooks make something happen.

What is a webhook in Intempt

A webhook is an outbound request sent by Intempt when a user reaches a specific Journey block. Webhooks enable:

• CRM synchronization
• Billing updates
• Internal backend notifications
• Subscription lifecycle handling
• Consent enforcement
• Custom workflow automation

Webhooks are push-based and sent once when the Journey block is reached.

📘 Good to know

Webhooks are configured inside Journey blocks, not as global destinations. This keeps every outbound call tied to a resolved identity and finalized attributes, instead of firing on every click or partial event.

HTTP methods

Intempt's webhook block supports three HTTP methods: POST, PUT, and DELETE.

POST: Create or notify

Use cases: Create a CRM lead, notify an internal backend, log a conversion, send signup data.

Example: CRM lead creation

Journey trigger: user completes signup.

{
  "eventTitle": "Signup Completed",
  "timestamp": "2026-01-26T10:12:45Z",
  "profile": {
    "profileId": "usr_12ab45c99d77",
    "email": "user@example.com",
    "firstName": "Alex",
    "plan": "free"
  }
}

Receiving system: creates a new CRM lead, responds 200 OK.

PUT: Update or sync state

Use cases: Update a subscription plan, sync entitlement changes, modify account metadata.

Example: Subscription upgrade sync

Journey trigger: user upgrades plan.

{
  "eventTitle": "Plan Upgraded",
  "timestamp": "2026-01-26T11:02:19Z",
  "account": {
    "accountId": "acc_a9213fbb892",
    "previousPlan": "starter",
    "currentPlan": "pro"
  },
  "profile": {
    "profileId": "usr_12ab45c99d77",
    "email": "user@example.com"
  }
}

Receiving system: updates billing tier, adjusts entitlements, responds 200 OK.

DELETE: Remove or revoke

Use cases: Unsubscribe users, remove contacts, revoke access, enforce consent revocation.

Example: Consent revocation

Journey trigger: user revokes marketing consent.

{
  "eventTitle": "Consent Revoked",
  "timestamp": "2026-01-26T11:45:10Z",
  "profile": {
    "email": "user@example.com"
  },
  "consent": {
    "category": "marketing",
    "action": "decline"
  }
}

Receiving system: removes the email from mailing lists, responds 204 No Content.

Choosing the right method

Choose the method based on what the receiving system expects, not the Journey name.

Configuration

A webhook block sends to a webhook destination. The destination config has these fields:

Intempt always sends Content-Type: application/json.

Authentication

Authentication is configured on the webhook destination.

📘 Good to know

Intempt does not sign outbound webhook payloads with an HMAC secret. If your endpoint needs to verify the request came from Intempt, use the Basic or Bearer credentials configured on the destination, not a signature header.

Delivery, retries, and failures

When your endpoint responds, Intempt maps the status code to one of these outcomes:

For a 429 or a 5xx response, Intempt retries the delivery. Each retry waits longer than the last, up to 5 attempts. After the 5th failed attempt, the delivery is marked failed and isn't retried again.

📘 Good to know

A 4xx response other than 429 is treated as a permanent failure and isn't retried, since it usually means the payload or credentials need to change, not that the request should be sent again unmodified.

Payload rules

• All payloads are JSON.
• Generated at execution time, using the Liquid variables in your configured payload template.
• Identity is already resolved.
• Attributes are finalized.

Payloads represent decisions, not raw events.

Your endpoint should:

• Respond quickly with a 2xx status.
• Be idempotent, since a retried delivery can arrive more than once.
• Enqueue the payload for async processing instead of doing long-running work inside the request.

Common mistakes

• Triggering webhooks on every event instead of Journey outcomes.
• Using webhooks as an event stream instead of a decision signal.
• Assuming the webhook block checks consent automatically. Unlike the email, SMS, and push blocks, Send Webhook has no built-in consent category -- gate it with a condition block earlier in the Journey if consent should stop the payload.
• Assuming a retried delivery is a duplicate detector on Intempt's side. Your endpoint still needs its own idempotency check.
• Expecting a signed request when no auth or signature verification is configured on the destination.

Use cases

1. Real-time lead notification. Notify a sales team the moment a new lead signs up, so follow-up starts immediately.
2. CRM synchronization. Push a new lead, contact update, or lifecycle-stage change into a CRM as soon as a Journey confirms it.
3. Subscription lifecycle sync. Update billing tier and entitlements in an external system when a user upgrades, downgrades, or cancels.
4. Consent enforcement. Remove a contact from downstream mailing tools the moment marketing consent is revoked.
5. Event registration follow-up. Trigger a fulfillment or confirmation flow in another system right after someone registers for an event.
6. Referral program tracking. Notify a referral platform when a user refers another customer, so rewards can be applied.
7. Internal backend notification. Alert an internal service or on-call tool when a Journey reaches a business-critical step.

Where to go next

• Journey blocks: how to add a Send Webhook block inside a Journey.
• Creating a journey: build the Journey a webhook block lives in.

Webhooks aren't a tracking tool. They're decision executors: they fire only after Journey logic resolves, represent meaningful business moments, carry clean and validated signals, and act as the bridge between Intempt and the rest of your stack.