A data driver fetches something and publishes it as variables, which is what makes a decision possible further down. When a rule cannot test what you want, the answer is almost always a data driver above it.

Two of them, Contentful Data and Content Cloud Data, resolve content rather than customer facts. They make messages richer; they make no new branch possible.

API Request

Calls any HTTP endpoint and reads the response into the journey. Use it when the fact you need lives in a system Xenia has no connector for, or when something outside needs telling and no integration node covers it.

Configure

Setting	What it does
HTTP method	`GET`, `POST`, `PUT`, `PATCH`, or `DELETE`. Unset behaves as POST
Request URL	The endpoint to call. Tokens may be interpolated into it
Authorization	`none`, `bearer`, `basic`, or `apiKey`
Headers	Request headers, as JSON
Query params	Query-string parameters, as JSON
Body	Request body
Timeout	Milliseconds to wait, capped at 30000
Response type	Whether the response is a single object or an array
Response fields	Fields to read from an object response. Each becomes a variable
Response schema	Fields to read from each item of an array response

Required: the URL. Bearer auth also asks for the token, basic auth for a username and password, and API key auth for a key name, a key value, and whether it travels in the header or the query string.

Produces

For an object response, one variable per declared response field, named as you named it. For an array response, {{response}} plus one response. prefixed variable per declared schema field.

Watch out

Undeclared fields are not testable, however the API answers.
Put an Iterate node after it to walk an array response item by item.
Prefer a connector node when one exists. Those carry auth and error handling; this node makes both your problem.

Klaviyo Data

Reads a Klaviyo profile, checks list membership, or pushes an event. Useful while Klaviyo is still the system of record for engagement.

Configure

Setting	What it does
Klaviyo connector	The connected Klaviyo account
Operation	`get_profile`, `check_list`, or `track_event`. Unset behaves as `get_profile`
Lookup by	Whether the profile is found by email or by phone
Email / Phone	The value to look the profile up by
List	Which list, for `check_list`
Event name	The event to send, for `track_event`
Event properties	Properties sent with the event, as JSON
Response fields	Fields to read from the response. Each becomes a variable

Required: the connector.

Produces

One variable per declared response field. With none declared, only {{response}}, which no rule can test usefully.

Watch out

check_list answers about one named list, not whether the person is engaged in general.
For spend or order history, Enrich Customer or an Audience Lookup gets there without a second system.
Klaviyo does the reading and writing here. The send belongs on a Xenia channel node.

Contentful Data

Resolves a Contentful entry so later nodes can render it. Use it when the copy belongs in the CMS, so marketing can change it without touching the journey.

Configure

Setting	What it does
Contentful connector	The connected Contentful space
Entries	Which entries to resolve

Required: the connector.

Watch out

It resolves content, not customer facts. No branch becomes possible because of it.
Entries are named by id, so the journey renders whatever those entries say at send time. Editing an entry changes live sends.
If the copy belongs to this one journey and nobody else will edit it, writing it on the channel node is simpler.

Content Cloud Data

Resolves Content Cloud entries for later nodes to use, and names the base entry that an In-Entry Personalization node beneath it will swap sections of.

Not shown in Shopify-billed workspaces.

Configure

Setting	What it does
Content Cloud connector	The connected Content Cloud space
Entries	Which entries to resolve. The first is the base entry personalization acts on

Required: the connector.

Watch out

It resolves content, not customer facts.
Varying content is not branching. Everyone continues down one path and only sees different blocks. If the steps themselves should differ, use a Rule.

In-Entry Personalization

Swaps sections inside the CMS entry resolved upstream, so the page stays the same and one block inside it differs for this customer.

Not shown in Shopify-billed workspaces.

Needs upstream

A Personalization Resolve trigger, which supplies the content key.
A Content Cloud or Contentful data node, which supplies the connector and the base entry.

Configure

Setting	What it does
Swaps	Which section of the base entry to replace, what to replace it with, and whether the swap is `section` or `items` mode

Swaps are built in the node's panel and applied there, not typed.

Watch out

The node authors nothing but the swaps. The content key, provider, connector, base entry, traffic share, and any rule gating it are read live from the nodes above it, so rewiring the journey changes them.
Two Personalization Resolve nodes, two CMS nodes, or two splits reaching this one through a Merge leave the ancestry ambiguous. It still saves, but personalization will not apply until the wiring leads back to one of each.
The journey has to have been saved once, so this node has a real id to bind against.
Section mode replaces the whole matched entry. Items mode keeps it and replaces only same-named list fields.

Enrich Customer

Loads the customer's stored Shopify profile, order history, and engagement metrics. This is the node that makes value, frequency, and recency testable, so it is the usual answer to "the journey has no way to know that".

Configure

Setting	What it does
Shopify shop	The connected store to read from

It acts on whoever is in the run, so there is nothing else to configure.

Produces

{{customerEmail}}, {{customerPhone}}, {{customerFirstName}}, {{customerLastName}}, {{customerCountry}}, {{customerLanguage}}, {{customerSubscribedEmail}}, {{customerOrderCount}}, {{customerTotalSpent}}, {{customerAvgOrderValue}}, {{customerLastPurchaseAt}}, {{customerEmailOpens30d}}, {{customerEmailClicks30d}}.

Watch out

A customer with no paid orders has no computed traits at all, so spend and order count arrive absent rather than zero. A rule testing them will not match: branch on the absence, or put that customer on a path that does not need them.
{{customerOrderCount}} counts the last 90 days, not the customer's lifetime.
An order.* trigger already carries the order and its value, so a second read after one adds nothing.
With no Shopify store connected, an Audience Lookup set to ENRICH_USER resolves the same kind of profile.

Check Shopify Order

Checks whether the customer bought since a point in time, so a recovery or reminder sequence can stop chasing someone who already purchased.

Configure

Setting	What it does
Shopify shop	The connected store to read from
Require paid	Count only paid orders, rather than any order
Lookback hours	How far back to look, used when the run carries no checkout timestamp

Produces

{{purchased}}, {{notPurchased}}, {{orderCount}}, {{checkedEmail}}, {{emailSource}}, {{sinceIso}}, {{checkSkipped}}.

Watch out

It only reports. Without a Rule reading {{purchased}}, the journey carries on regardless and the buyer still gets the next nudge. The correct shape for abandoned-checkout recovery is: wait, check, rule, then send.
With no email to check it sets {{checkSkipped}} rather than failing. Branch on that if the outcome matters.
It answers whether an order happened, not what was in it. Enrich Customer carries the detail.

Shopify Discount

Makes the customer eligible for a discount and hands the code back as a variable, so a message can carry a code only that customer can use.

Configure

Setting	What it does
Shopify shop	The connected store
Discount mode	`existing` uses a price rule that already exists, `create` makes one
Price rule	Which price rule, for existing mode
Discount code	The code to hand out, for existing mode
Discount type	Percentage off or a fixed amount, for create mode
Discount value	How much off
Code prefix	Prefix for the generated code, for create mode
Usage limit	How many times the code may be used
Once per customer	Limit each customer to one use
Start	`now`, or a fixed start date
End	`never`, a fixed end date, or a duration in days
Customer eligibility	Who the discount applies to

Required: the mode. Existing mode also requires the price rule and the code; create mode also requires the value.

Produces

{{coupon_code}}.

Watch out

It must come before the message that uses the code, since {{coupon_code}} is available to later nodes only.
Prefer existing mode when the operator already set a promotion up, so reporting stays in one place.
Set an expiry that matches the journey's own timing. A code that outlives the sequence gets shared.

Data Drivers