nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Optimizing high-volume Connected Content/API calls: message templates vs Context steps vs caching?

Eray

Hi everyone,

I’d love to hear how you are handling Connected Content/API enrichment at larger scale, particularly when product data is not stored directly in Braze.

In our setup, product catalogs currently live outside Braze. We receive user/event data from Snowflake, including specific product IDs, and then need to enrich those products with the latest market-specific information before sending a message:

Product name
Image
Current price
Discount percentage/value
Availability and other product attributes

We currently retrieve much of this through Connected Content/API calls during message rendering.

On top of the main product enrichment, some of our reusable Content Blocks also make additional API calls, for example to retrieve categories, best-selling products, recommendations, etc.

As a result, some templates can contain up to ~4 API calls per user.

At our scale, with millions of users going through Canvases, this can translate into tens of millions of API requests per day, since the enrichment is evaluated as users are processed.

We’re now looking at how we could redesign this more efficiently.

A few approaches we are considering:

1. Moving enrichment earlier into a Canvas Context step

Instead of making the calls inside the message template, retrieve the necessary data earlier and store it as Context variables that can then be reused by subsequent message steps.

This would make the message templates much cleaner, but I’m wondering how much it actually reduces API load if the Context step is still processing the Connected Content call per user.

2. Making better use of Connected Content caching

Many users can reference the same product and market combination, so theoretically identical requests could benefit significantly from Braze caching.

I’m particularly interested in how others structure endpoints/request URLs to maximize cache reuse and what cache_max_age strategies you use when product information needs to remain relatively fresh.

3. Consolidating multiple calls into one enrichment endpoint

Instead of having multiple Content Blocks independently call different services, we could potentially have one API call return all the information required for the message — product data, category information, recommendations, etc.

4. Enriching the data before it reaches Braze

Another option would be doing more of this enrichment upstream, for example in Snowflake, and passing the enriched object into Braze with the triggering event rather than retrieving everything at send time.

The trade-off here is obviously freshness vs scalability especially for price and discount information, where we want the data as close as possible to send time.

I’d be very interested to hear from anyone operating a similar architecture:

How do you handle product enrichment when the product catalog itself isn't in Braze?
Do you perform Connected Content calls directly inside message templates or earlier in the Canvas?
Have Context variables helped you reduce repeated enrichment calls across a journey?
How aggressively do you use Connected Content caching at scale?
Have you built an aggregation/BFF-style endpoint specifically for Braze so that one request replaces multiple Connected Content calls?
Or did you eventually move toward Braze Catalogs / pre-enrichment instead?

Especially interested in experiences from teams handling high-volume product-driven messaging.

Thanks!

Find more posts tagged with

Catalogs

SDKs and APIs

Liquid

Accepted answers

All comments

Axel_Cordonnier

Hi Eray!

At Ornikar, we use a different approach: we don’t use Connected Content or Canvas Context for this.

Product, pricing and promotion data is stored in Braze Catalogs and updated when the underlying data changes via an API call. Our Content Blocks then mainly contain reusable Liquid logic to retrieve and filter the relevant catalog data to display the right pricing/promo for each user.

So in our case, we avoid making API calls per user at send time altogether. For data that doesn’t need true real-time enrichment, moving it into Braze Catalogs could be worth considering before optimizing the Connected Content layer itself.

Eray

Hi Axel,

Thank you for your answer. May I ask how large your catalog is and how frequently you update the product attributes?

At idealo, we’re dealing with millions of products, and prices change quite frequently. We also operate across six different markets, meaning that each product can have six different market-specific prices.

I’m trying to understand how scalable this approach would be for a setup of our size and complexity.

Axel_Cordonnier

Hi @Eray

Our catalog have 568 438 items and a size of 80.89MB. This one is updated every day but not each lines are updated, only the ones with an updated price.

Indeed, I could not guarantee that this approach would work for your use case that seems bigger

Eray

Thank you, @Axel_Cordonnier. This is very helpful.

I’ve also shared this with our CRM Tech team and data engineers. I’ll reach out if we have any further questions about your setup and architecture.

Hopefully, someone working with a larger catalog and a high volume of API calls can also share their experience. Otherwise, we may need to consider whether an architectural change would make more sense for our use case.

Nirnay

Post 1

Hi @Eray, splitting this into two posts so it fits. Part 1 is how we think about Context vs cache vs timeouts. Part 2 is two travel examples and how they map to your four options.

We are a travel company running a similar setup at scale: hotels, tours, cruises, flights. We have on the order of ~100k offers, we operate in about 30 countries, and we recently launched translations, so the same offer can render in more than one language. Those offers still live outside Braze. Snowflake/events send offer IDs (and search params like dates or occupancy), and we hydrate name / image / price / availability around send time.

The offer tile itself is the complicated part. It is not just name + image + a price. A single hotel tile can carry a public from-price and a member from-price, discount %, availability, urgency, and loyalty (earn points, and in some cases burn points to bring the price down). Same offer ID, different numbers depending on market, language, and whether the user is a member. That is why we do not want four Content Blocks each calling a different service, and why we also do not put user_id on the URL. Member vs non-member is a coarse cohort. A million members can still share one cached payload.

A few things that matter more than “template vs Context vs cache” as slogans.

Context does not reduce API volume, and it can make load worse

If the Context step still does Connected Content per user, you have not cut calls. You have only moved them earlier.

The operational difference is bigger than that. Canvas rate limits apply to Message steps, not Context steps. A send-speed cap does not throttle Connected Content inside Context. Users can still be processed in parallel batches, so your origin can get a burst you never see on the Canvas rate-limit setting.

If you still want enrichment in Context (reuse one payload across email, push, a later resend), throttle it yourself. We use the same native pattern we already use for domain-level email pacing: random bucket number (0–9999) + a Context variable for the wait + a personalised Delay step. Write-up with Liquid is here: One of my Linkedin Articles

For email, Context Liquid looks at the domain and ${random_bucket_number}, sets wait_minutes, then the Delay step uses {{context_variable.${wait_minutes}}}. Microsoft users spread over a few hours; Gmail/Yahoo go through on the Canvas rate limit. For API enrichment it is the same idea without the domain check: bucket groups map to a delay so Connected Content in Context (or a heavy job kickoff) trickles instead of bursting. You are not replacing the Canvas rate limit. You are adding a distribution layer in front of a step that the rate limit does not cover.

When Context actually helps: one fetch, then later Message steps read context.* and do not call the API again. That is reuse across a journey, not fewer users hitting the endpoint. You also accept freshness as of the Context step, not as of the send. For us that matters: a hotel rate or member price from yesterday’s Context step is often the wrong rate for tonight’s email.

For a single high-volume message, Context is usually not the scale lever. Caching, URL shape, and not doing slow work in Connected Content are.

Connected Content has a ~2 second timeout

Braze expects each Connected Content call to respond in under 2 seconds. If it does not, the content is not inserted. That is per call, not 2 seconds for the whole email. Four sequential calls is four chances to miss the window.

That constraint drives the design more than where in the Canvas the call lives:

Do not fan out hotel content + public price + member price + points/burn + recs as separate template calls.
Prefer one aggregated response so Braze waits on one hop (name, image, both price lanes, discount, availability, points, burn, translated copy).
Cache shared offer+market+language+membership payloads so origin work stays cheap.
If an enrichment can regularly miss 2 seconds (live flight search, heavy occupancy quotes), do not call that API from the template. Compute it earlier, store it, and fetch the stored result.

:retry covers a blip. It does not make a slow endpoint safe.

Caching is what reduces tens of millions of calls (when URLs are shareable)

Braze caches on the full request URL. Same hotel offer + same market + same language + same member flag → same URL → shared cache across users in a send.

Keep cacheable URLs to shared dimensions only: offer ID, market/region, language, member vs non-member (if that changes the tile). Leave off user_id, timestamps, and unique tokens. The moment every user has a unique URL (because you passed their points balance into the query string), cache hit rate collapses and every render must finish from origin in 2 seconds. If burn is truly 1:1 to that user’s balance, that piece cannot live on the cacheable tile URL. Either keep burn off the shared GET, or accept :no_cache for that path.

~100k offers × ~30 countries × languages × member/non-member sounds scary as a matrix. You do not hydrate the full matrix on every send. You hydrate the offers that are actually in that morning’s schedules, in that market, in that language, for that membership cohort. Unique keys grow, but they are still far smaller than user count. The same Bali hotel in AU/en/member is one cached URL for a huge cohort.

What we use in practice:

Shared offer tile (property name, image, public and member from-price, discount, availability, points, translated fields): about 15 minutes, sometimes 30 minutes on large broadcasts.
Market-level lists (destination bestsellers, category lists): shorter, e.g. 5 minutes.
Truly 1:1 (a dated hotel quote, a flight search, a personal burn calc, generated codes, stored job lookups): :no_cache.

GET is cached by default (min ~5 min unless you :no_cache). POST is not, unless you set :cache_max_age. Cache is a hint, not a guarantee. A second cache on your side (keyed the same way: offer + market + language + member flag) absorbs Braze misses during a big send.

Our API + Redis (the second cache)

Braze does not call offer, pricing, or loyalty services directly. It hits a comms API we built for this: one GET by offer ID, with query params for market, language, and member vs not. That service assembles the fat tile (both price lanes, discount, availability, points, images, links) and is what has to stay under 2 seconds.

Behind it we Redis-cache the formatted payload, keyed the same way (offer + market + brand, and the member/locale flags on the request). In prod the offer TTL is about 30 minutes. HTTP cache on some responses is about 10 minutes. So a Braze cache miss during a million-user send is often still a Redis hit, not a stampede into the core offer/pricing services.

We also rate-limit that offer endpoint (we cap it on the order of 100 req/s) so a bad template or a :no_cache loop cannot take the origin down. Flights are a different path: async job, result stored, Braze only GETs the stored job.

One enrichment endpoint

If templates and Content Blocks each call a different service, you multiply QPS, timeout risk, and Liquid complexity. That comms GET is the aggregation layer. Content Blocks consume its JSON; they do not each hit offer content, pricing, loyalty/burn, recs, and a translation service. That is the only way a “fat” tile stays inside 2 seconds.

Part 2: two examples (daily merch + flights) and how they map to your four options.

Nirnay

Post 2

Part 2 of 2 (daily merch + flights, then your four options).

Example 1: daily merch email (high volume, many schedules, cache still wins)

This is our “daily email” style hotel/tour/cruise newsletter. Merch is decided upstream. The user has country, state, segment, cadence, language, membership, not offer JSON.

The template makes one schedule call keyed by market + date + state + segment (plus a few other cohort flags). NSW vs VIC, or AU vs DE, or different segments, can get different hero/tail lists. Across a send we might hydrate on the order of ~1000 distinct offers that day, out of ~100k offers in our system, not a single global set of 8. Translations and member vs non-member add dimensions on the enrichment URL, so DE/de/member and AU/en/non-member are different cache keys for the same property, which is what you want. The tile then has a lot on it: public price, member price, discount, availability, earn, sometimes burn.

Then we loop those IDs through that one offer GET with :retry and a 15–30 min Braze cache. No user id on the URL. The same Bali hotel + same market + same language + same member flag reuses Braze cache, and if Braze misses, Redis still has the formatted tile for ~30 minutes.

It looks like “1 + N calls per user.” N is real, and the offer mix is not global. What collapses is the number of unique URLs: one schedule URL per country/state/segment bucket, one product URL per offer+market+language+member flag. Millions of users still map onto a few hundred or ~1000 origin keys once both caches are warm (more once you multiply markets, locales, and membership, still not user-count). If the schedule is empty or a required tile fails (missing price, etc.), we abort rather than send a broken tile.

Context would not reduce that load. It is still one message per user, and Context would still fire per user without the Canvas message rate limit. Caching the shared schedule and offer URLs (Braze + Redis) is what keeps origin traffic closer to “unique offers that morning, per market/language/membership,” not “users × tiles.”

Example 2: flights upsell (too slow for a live Connected Content search)

Post-purchase we often want to show return flights for the trip they just booked. Live flight search is too slow and too unique to run inside message render. If you call the provider from Connected Content, you will miss 2 seconds and ship empty tiles.

So we split it. A job is created with origin, destination, dates, pax, market. A worker searches, formats 1–3 fares, and stores that payload in our backend. Braze never talks to the search API at send time.

A Context step only stores a pointer (job id / URL, airport codes), not the full fare sheet. On render the email does a fast GET of that stored job (:no_cache, because each trip is unique). That is a store read, so it stays under 2 seconds. If the job is missing, empty, or prices are 0, we abort. The SMS step reads the same pointer, so we do not search twice.

If that Context step itself ran the live search, Canvas rate limiting would not protect the flights service. Search stays off the Connected Content path. If you ever did search-in-Context, spread it with the same RBN + Context wait + personalised delay pattern from part 1.

Pre-enrich vs send time

We do both, on purpose.

Upstream / async: offer IDs, merch selection, search params (dates, occupancy, airports). For anything that can miss 2 seconds, the computed payload is written to our DB/job store.
Send time: cacheable hotel/tour tiles via the comms GET (market + language + member flag), Braze cache + Redis, or a cheap GET of the stored flights job.

We do not stamp live nightly rate, member price, or points onto the triggering event for marketing Canvases with delays. Fully assembled payloads we keep for true transactional messages (booking confirmation, etc.).

Braze Catalogs we use for copy, banners, config, and some translation/config lookups. Not as the hotel/flight system of record when public price, member price, and burn can all move across 30 countries.

Direct answers to your four options

Context: cleaner templates, same or higher origin burst unless later steps skip the call. Rate limit on the Canvas will not protect you. Throttle with RBN + Context wait_minutes + personalised delay (same pattern as my throttling method article). Best use is storing a pointer or a payload you will reuse across steps (example 2).
Caching: main win for shared schedule and offer+market+language+member URLs, if you stay inside 2 seconds (example 1). Two layers: Braze Connected Content cache, then Redis on the comms API so a Braze miss is not a stampede into offer/pricing services. You do not need every user to get the same Bali hotel. You need unique keys (offer × market × language × member flag, and only the offers actually scheduled) to be much smaller than user count. ~100k offers in 30 countries with translations and two price lanes is the product complexity, not the per-send cache key count. Personal burn should not ride on that shared URL.
One aggregation/BFF endpoint: do this. Ours is a single offer GET that returns the fat tile. That is also how we keep the 2 second timeout.
Enrich before Braze: IDs and merch yes. Live hotel from-price / member price for broadcasts usually at send time with Braze cache + Redis. Anything slower than 2 seconds (flights search, heavy quotes): compute, store, fetch the stored result (example 2).

Hope this helps. Feel free to ask any questions.

Eray

Thank you @Nirnay This is very helpful! I’ve already shared this with our CRM Tech team and Data Engineers. I’ll reach out if we have any further questions after discussing it internally.