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
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.
Filling it in from a cURL command
Paste a cURL command into the Request URL field and the rest of the node fills itself: method, headers, body, query parameters, and auth. It is the fastest way in when you already have the call working somewhere else, from Postman, a browser's network tab, or a colleague's message.
What it reads: -X / --request for the method, -H / --header for headers,
-d and its variants for the body, -u and an Authorization header for auth (both
lifted into the Authorization setting rather than left as a raw header), -m /
--max-time for the timeout, and the URL's own query string, which is split out into
Query params. Transport flags such as -L, --compressed, -k and -s are
recognised and ignored. Multipart -F has no equivalent here and is reported rather
than silently dropped.
A plain URL pastes as a plain URL. Only text that starts with curl is treated as a
command.
Caching the response
Under Advanced, a GET node can reuse a recent response instead of calling again. Switch on Cache responses, pick the upstream variables that make one response distinct from another, and set how long an answer stays usable.
Two runs share a response when these variables resolve to the same values and the request is unchanged. Editing the URL, body or headers starts a fresh entry, so a change to the node never serves an answer fetched under the old settings. A rotating bearer token does not, so credentials that change hourly do not defeat the cache.
The cache is shared across the whole workspace and environment, not just one journey run, which is what makes it save real calls. A downstream node reads a cached response exactly as it reads a live one: declared response fields and nested arrays are republished either way.
Caching is GET-only on purpose. Reusing an answer to a POST or DELETE would mean the write silently never happens on the second run, with nothing in the journey to show for it.
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.
- A run that is missing one of the cache key variables calls the endpoint live rather than sharing an entry with every other run missing it. This is deliberate: a shared fallback entry would serve one person's response to another. It does mean a variable the trigger does not actually carry turns every run into a live call, so pick names the journey really has.
- Only a successful response is cached, so a failing endpoint is retried on the next run rather than having its error remembered.
- 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
Required: the connector.
Produces
One variable per declared response field. With none declared, only {{response}},
which no rule can test usefully.
Watch out
check_listanswers 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
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
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
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
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_USERresolves 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
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
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.