Using Live Data in Journeys

Journey Live Data pulls temporary, real-time data from external services into a journey at the exact step where you need to make a decision, allowing you to personalize messages and route users based on what is true right now—not what was true at the last batch sync. This data stays in-memory for the duration of the user’s journey path and is only written to their user profile when you explicitly choose to do so. That means you can move faster, make more accurate decisions, and deliver more relevant customer experiences without bloating your user profile schema.

# In this article

# When to use Journey Live Data

Use Journey Live Data when a journey needs fresh external truth at decision time—data that changes frequently and lives outside Iterable—rather than pre-synced or profile-based data.

Journey Live Data is a strong fit when:

• An external system is the source of truth for the value you need.
• The relevant data changes frequently (for example, offer eligibility, inventory or loyalty status, or experiment variant).
• You need the value to decide the next journey step or personalize the next journey message.
• You want to avoid storing short-lived values on the user profile.
• You only need to persist a small subset of returned fields (if any).

Journey Live Data may not be the right fit when:

• The relevant data changes infrequently and can live on the user profile.
• You need to synchronize or warehouse data in bulk.
• You need a long-term system of record inside Iterable.
• The required data is already available in Iterable as user profile fields or events.

Use events and broader integrations when you need persistent data for reporting, segmentation, or bulk ETL. Use Journey Live Data for per-user, in-journey decisions based on frequently-changing external data.

# Common use cases

Journey Live Data helps you act on live context inside journeys. Common scenarios include:

# How it works

Journey Live Data works by calling an external API via a journey webhook and capturing selected fields and data types into a liveData object that you can reference downstream throughout the journey.

If the request succeeds, the user goes down the Success path to the next tile, and the data persists with them through the journey. If the request fails, the user follows the Live Data tile's Failure path, where you can route them to an appropriate next step. Users also follow the Live Data tile's Failure path if the selected live data payload exceeds the supported 50 KB size limit.

To learn more about how Iterable determines successful and failed webhook calls, see Journey Webhooks — Response Times, Retries, and Timeouts.

# Recommended architecture

The reusable pattern across partner APIs, internal services, and customer service systems is:

1. A journey triggers from an event, audience entry, or another standard entry condition.
2. A Live Data tile executes a journey webhook during journey runtime.
3. The webhook calls an external HTTPS endpoint.
4. Iterable parses the webhook response according to the Data Retrieval configuration and makes the selected fields available as live data.
5. Downstream filter and message tiles use the returned fields for routing and personalization.
6. A User Profile tile optionally persists only the fields that should remain available after the journey ends.

Live Data is journey-local and ephemeral by default. It exists for the user’s path within that journey unless you explicitly map values back to the profile.

# Connection types and requirements

Journey Live Data always connects through a journey webhook to an HTTPS endpoint that returns JSON. In practice, that endpoint can take a few shapes.

# Direct HTTPS endpoint

Call a stable external API that already answers a narrow, real-time question (for example, inventory, eligibility, or loyalty status).

Requirements:

• The endpoint must use HTTPS and return JSON.
• Configure a journey webhook with Data Retrieval enabled.
• The webhook must pass a successful test before you can save it.
• Select up to 50 Live Data fields from the response.
• Keep the selected live data payload at or under 50 KB.
• Configure authentication with the webhook’s built-in auth options or secure custom headers. Do not put API keys or secrets in endpoint URLs.

# Partner API

Use a partner’s evaluation endpoint when the vendor already exposes a usable HTTP API for journey-time lookups (for example, experiment assignment or feature gates). The same webhook and Data Retrieval requirements apply. You may need dynamic parameters or Handlebars in the URL or body to pass runtime values such as experiment IDs or user identifiers.

# Custom Edge API (recommended for complex systems)

For most integrations with complex partner platforms or internal systems, expose a thin service layer—or edge API—that gives Iterable a stable contract tailored to journey use cases, rather than connecting Live Data directly to a complex upstream API.

That service should:

• Accept the minimum user and journey context needed to evaluate the request.
• Call the underlying partner or internal platform.
• Normalize the response into a compact JSON shape.
• Return only the fields the journey actually needs.
• Handle business rules, retries, idempotency, and provider-specific quirks outside Iterable.

This pattern is especially useful when the partner does not expose a clean lookup endpoint, when schemas are unstable, or when sensitive credentials and issuance logic (such as unique coupons) should stay in your own system.

# Design principles

• Keep the contract small. Register only the fields needed for routing, personalization, and limited persistence.
• Normalize external complexity. Hide provider-specific details behind a stable response shape so journey builders can focus on decisions.
• Treat Live Data as decisioning context. Use it as a thin runtime layer, not a replacement for durable customer data architecture.
• Persist by choice, not by default. Leave values in Live Data when they matter only for the current branch or send; write to the profile only when they must outlive the journey.
• Build for failure. Configure rate limits and design safe Failure paths so timeouts or errors do not break the customer experience.

# Configuring Journey Live Data

To use Journey Live Data:

1. Define live data fields in a journey webhook: First, create or edit a journey webhook in your project, enable Data Retrieval for the webhook, and identify specific data fields to be captured as live data from the endpoint.

2. Add a Live Data tile to a journey: To bring your desired live data into a journey, add a Live Data tile at the appropriate stage of the journey and configure it to call your desired webhook.

# Define Live Data fields in a journey webhook

Journey webhooks can sync data to and from external services. To use the returned payload as live data in a journey, enable the Data Retrieval option in the webhook's configuration and define up to 50 fields from the payload to make available as live data in journeys. To learn how to configure a journey webhook for use with Journey Live Data, see Creating Journey Webhooks.

# Add a Live Data tile to a journey

To fetch data from an external source at a given point in a journey, use a Live Data tile.

# Referencing live data fields

Once you've set up at least one Live Data tile in a journey to capture a liveData object, you can reference values from that object in later steps in the journey. These values can be referenced in Filter tiles and Message tiles.

Live data references use standard dot-notation and follow this naming convention:

# Filter tiles

You can use Journey Live Data fields in Yes/No Split tiles and Attribute Split tiles to make real-time decisions and route users to appropriate next steps in the journey.

# Configuring Yes/No Split tiles with live data

Add a Yes/No Split tile after a Live Data tile in a journey, then double-click the Yes/No Split tile to configure its details.

Under Filter by, select the Live Data tiles option. Then, under Split Criteria, click Live Data Fields, and configure your desired conditions for splitting users. When the journey is live, users who match the query conditions are sent down the Yes path, and users who don't are sent down the No path.

# Configuring Attribute Split tiles with live data

Add an Attribute Split tile after a Live Data tile in a journey, then double-click the Attribute Split tile to configure its details.

Under Split Based On..., select Live Data Field. Under Attribute, select one of the live data fields fetched in the preceding Live Data tile, then define the attributes by which you want to split users. For example, if you select the products.sku live data field, you could select the various product SKUs users have added to their cart and route users to different messaging accordingly.

# Message tiles

You can reference live data fields in journey campaign templates using Handlebars to render real-time values in your journey message sends. You can find a list of available fields and copy the merge tag to reference them in the configured Live Data tile.

# Testing message personalization

Like API-triggered events, live data is not stored. To test message personalization, use representative sample data and paste it into the preview inputs you already use, such as user profile or data feed fields. Structure the sample data under a liveData object so your Handlebars references match the liveData structure your journey provides at send time. If you test a journey webhook or Live Data tile with Data Retrieval enabled, you can also copy the sample response from the test result and reuse it here after wrapping it in the liveData structure. For example:

{
  "liveData": {
    "inventoryCheck": {
      "in_stock": true,
      "quantity": 12,
      "products": [
        { "sku": "SKU-123", "price": 29.99 },
        { "sku": "SKU-456", "price": 49.99 }
      ]
    }
  }
}

# Saving live data to user profiles

By default, live data only persists for the duration of a user's path through a journey—from the Live Data tile in which it's captured to the point at which the user exits.

However, you can write live data fields to permanent user profile fields when the data is worth saving (for example, if a user's verified loyalty tier or product preference has changed). To do this, add a User Profile tile and configure it to save your desired data.

# Sharing live data via webhooks

You can also send live data fields to external services via a Webhook tile. For example, you might send a combination of user profile, event, and live data to a connected app like Segment. To do this, add a Webhook tile and configure its payload to include your desired live data fields using Handlebars references.

# Recommendations and best practices

# Limits

The following limits are in effect to ensure performance at scale:

You can place multiple Live Data tiles in a journey that reuse the same context key. Each successful call overwrites that key with the latest response. This is useful when you stack Live Data calls and only need the most recent state for downstream personalization or routing—reusing the key means those tiles do not consume additional unique-key quota.

To maintain fast, reliable performance in your journeys, select only the specific data fields from a journey webhook payload that you need to orchestrate your Live Data use cases—and leave off any data fields that aren't needed. Smaller payloads are easier to test, faster to process, and less likely to hit performance guardrails.

To help external services handle journey volume, configure a default rate limit on the journey webhook and use a tile-level override only when a specific step needs different behavior. Rate limiting paces individual requests instead of batching users together. To learn more, see Journey Webhooks.

Before using Journey Live Data, confirm that:

• The external endpoint has a stable, normalized contract.
• The journey webhook test passes.
• Selected fields are limited to the minimum useful set.
• Live Data object naming is clear.
• Routing covers both Success and Failure outcomes.
• Rate limits are configured where needed.
• Persistence is used only for fields that must outlive the journey.

# Want to learn more?

For more information about some of the topics in this article, check out these resources. Iterable Academy is open to everyone — you don't need to be an Iterable customer!

Iterable Academy

• Product Bite: Journey Live Data

Support docs

• Journey Webhooks
• Integration Tiles
• Filter Tiles
• Message Tiles
• User Update Tiles