Overview

Journey Builder 2.0 introduces Webhook as a new channel option, allowing you to integrate your customer journeys with external systems and services. This feature enables you to trigger HTTP requests to third-party APIs as part of your customer journey workflows.

📘

Availability and access

The Webhook channel is exclusively available in Journey Builder 2.0. Users who already have permission to use webhooks in single-stage campaigns will automatically have access to Webhooks in Journey Builder 2.0 without any additional setup requirements.

Adding a Webhook to Your Journey

To add a webhook action to your journey:

1. Open your journey in Journey Builder 2.0
2. Locate the Engagement section in the left panel
3. Find the Webhook icon in the engagement options
4. Drag the webhook icon from the left panel and drop it onto your journey canvas
5. Position it where you want this action to occur in your customer journey

Once placed in your journey, you can configure the webhook details by clicking on the node.

To learn how to create webhook content, please refer to our comprehensive Webhook documentation.

Webhook Analytics

After deploying a journey with webhook actions, you can monitor performance through various analytics views:

1. Webhook Action Node Statistics:

View counts for "Arrived" and "Sent" directly on the webhook action node within the journey

2. Detailed Webhook Analytics:

Access comprehensive metrics including "Arrived," "Sent," and "Delivered"
View line graph visualisations of webhook performance over time.

3. Journey Analytics:

Webhook channel metrics are fully integrated into the overall journey analytics

Using Webhook Responses in Decision Nodes

A powerful feature of webhooks in Journey Builder 2.0 is the ability to use webhook responses as criteria in decision nodes, enabling dynamic path selection based on API responses.

Available Webhook Response Criteria

You can create branching logic based on the following webhook response elements:

• Sent Status
  • Options: IS, IS NOT
    Description: Routes users based on whether the webhook was successfully sent
    Use Case: Separate users where an API call succeeded vs. failed to initiate
• Successful Status
  • Options: IS, IS NOT
    Description: Routes users based on whether the webhook received a 2XX response code (200-299)
    Use Case: Create different experiences based on successful/unsuccessful API responses
• Response Code
  • Options: IS, IS NOT
    Description: Routes users based on specific HTTP response codes
    Input Required: HTTP status code value (e.g., 200, 404, 500)
    Use Case: Create specific handling for different API response scenarios
• JSON Response
  • Options: IS, IS NOT
    Description: Routes users based on specific values in a JSON response
    Input Required: JSON key and expected value
    Use Case: Branch journey based on data returned from external systems
• Plain Text Response Equals
  • Options: IS, IS NOT
    Description: Routes users based on exact text response matching
    Input Required: Expected text string
    Use Case: Create paths based on specific text responses from APIs
• Plain Text Response Contains
  • Options: IS, IS NOT
    Description: Routes users based on partial text matching
    Input Required: Text string to check for
    Use Case: Create paths based on the presence of specific text in API responses

Using Webhook Criteria in Decision Nodes

You can implement webhook response criteria in both standard Decision nodes and Multi-Decision nodes:

In Standard Decision Nodes:

Add a condition based on webhook response
Combine multiple webhook conditions using AND/OR operators
Mix webhook conditions with other journey data points

In Multi-Decision Nodes:

Create up to 5 different paths (A-E) plus an "else" path
Each path can use different webhook response criteria
Create complex routing logic based on various API responses

Validation

The system validates your webhook decision criteria configurations:

1. Empty fields in Code, JSON response, or Plain text inputs will trigger validation errors
2. These errors will be displayed in the workflow errors panel
3. Journeys with validation errors cannot be launched until the errors are resolved

Best Practices

• Test your webhooks thoroughly before deploying in production journeys
• Monitor webhook performance regularly through the analytics dashboards
• Set up fallback paths for cases where webhooks fail to send or receive expected responses
• Keep response parsing simple when possible to ensure reliable journey execution
• Consider rate limits of external APIs when designing high-volume journeys

Example Use Cases

1. Fetch real-time inventory data and route customers based on product availability
2. Check customer credit status from external systems to personalize offers
3. Validate data with third-party verification services before proceeding
4. Pull content from a CMS to dynamically personalise messaging
5. Trigger fulfilment processes in external systems as part of customer journeys