# All about Webhooks

# Webhooks in Intempt

## Overview & Mental Model

In Intempt, **Webhooks are the outbound execution layer**.

They allow Intempt to send HTTP requests to external systems **only after a meaningful business decision has been made inside a Journey**.

Unlike raw event tracking, Webhooks are:

* **Journey-driven**, not event-driven
* **Consent-aware**
* **Identity-resolved**
* **Attribute-evaluated**
* **Triggered only at decision points**

A Webhook represents a **business outcome**, not a stream of user activity.

> **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 **exactly once** when Journey conditions are satisfied.

---

## Why Webhooks Are Journey-Driven (Not Event-Driven)

Webhooks are configured **inside Journeys**, not as global destinations.

This ensures outbound calls:

* respect consent rules
* use resolved identity
* include final attribute values
* represent meaningful business moments
* avoid noisy integrations

This design prevents:

* triggering on every click
* mirroring raw browser data
* sending unstable or partial payloads

---

## Webhook Configuration

### Where Webhooks Are Created

Webhooks are created **directly inside Journey blocks**.

* ❌ No global webhook list
* ❌ No reusable destinations
* ✅ One webhook = one business outcome

A Webhook fires **only when the user reaches that Journey step**.

---

## Request Type (HTTP Method)

Each Webhook is configured with **one HTTP method**.

Below are **real, end-to-end examples** of how each method is used in practice.

---

## POST — Create / Notify

### Typical Use Cases

* Create a CRM lead
* Notify an internal backend
* Log a conversion
* Send signup data

### Live Example — CRM Lead Creation

**Journey Trigger**
User completes signup

**Webhook Configuration**

* Method: `POST`
* URL: `https://api.crm.example.com/leads`

**Payload Sent by Intempt**

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

**Receiving System Action**

* Creates a new CRM lead
* Stores user attributes
* Responds with `200 OK`

---

## PUT — Update / Sync State

### Typical Use Cases

* Update subscription plan
* Sync entitlement changes
* Modify account metadata

### Live Example — Subscription Upgrade Sync

**Journey Trigger**
User upgrades plan

**Webhook Configuration**

* Method: `PUT`
* URL: `https://billing.example.com/accounts/{accountId}`

**Payload Sent by Intempt**

```json
{
  "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 Action**

* Updates billing tier
* Adjusts entitlements
* Confirms update with `200 OK`

---

## DELETE — Remove / Revoke

### Typical Use Cases

* Unsubscribe users
* Remove contacts
* Revoke access
* Enforce consent revocation

### Live Example — Consent Revocation

**Journey Trigger**
User revokes marketing consent

**Webhook Configuration**

* Method: `DELETE`
* URL: `https://email.example.com/subscribers/{email}`

**Payload Sent by Intempt**

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

**Receiving System Action**

* Removes email from mailing lists
* Stops future communication
* Responds with `204 No Content`

---

## Choosing the Right Method

| Method | Use When You Want To  |
| ------ | --------------------- |
| POST   | Create or notify      |
| PUT    | Update existing state |
| DELETE | Remove or revoke      |

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

---

## Webhook Authentication

Authentication is configured inside the Webhook block.

### Supported Methods

**Basic Authentication**

* Username + password
* Sent via `Authorization` header
* Suitable for internal systems

**Token / API Key Authentication**

* Bearer tokens or API keys
* Sent via headers
* Recommended for production

---

## Webhook Payload Rules

* All payloads are JSON
* Generated at execution time
* Identity is already resolved
* Attributes are finalized
* Consent has already been validated

Payloads represent decisions, not raw events.

---

## Failure Handling (Developer Responsibility)

Your endpoint should:

* respond quickly (`2xx`)
* be idempotent
* enqueue payloads for async processing
* handle retries safely

Avoid long-running synchronous work.

---

## Common Mistakes to Avoid

* Triggering webhooks on every event
* Using webhooks as event streams
* Skipping consent logic
* Encoding business logic downstream
* Treating webhooks as retry queues

---

## Final Takeaway

Webhooks are not tracking tools.

They are:

* decision executors
* Journey outcomes
* clean, validated signals
* the bridge between GrowthOS and your stack

Events describe behavior.
Journeys decide intent.
Webhooks execute outcomes.