Using Braze Connected Content for Personalized Campaigns

Braze Connected Content pulls live data from your own endpoint into a message while it renders, so every campaign that uses it depends on that endpoint at send time. Plan for more calls than sends, a two second response budget and a 1 MB cap. Decide what happens when a call fails before the first send goes out.

What does Braze Connected Content do when a message renders?

Connected Content makes a web request from Braze to your endpoint while the message renders, then inserts the response with Liquid. You write the call with the connected_content tag and save the response to a variable with :save.

The timing is the part to design around. Connected Content executes when the message is rendered, and for in-app messages that means at impression time. Calls inside one template run from top to bottom, so a later call can use a variable that an earlier call set.

The response shape matters too. If your endpoint returns JSON, Braze parses it into a variable. If it returns text, Braze inserts that text where the tag sits. A saved variable is only available inside the field that contains the call, so a title and a body each need their own call.

How do you pass user data to your endpoint safely?

Braze lets you put user profile attributes into the request URL. Attribute values must be surrounded by ${}, and Braze tells you to use the url_param_escape filter for values with special characters, such as the at sign in an email address.

Braze's own example puts an email address in the query string. That is worth a second look. Braze also records request metadata for troubleshooting, including the fully rendered request URL, and keeps those logs for up to 30 days. Assume that an identifier in the URL is stored in that log as well as reaching your server.

The safer habit is to send an identifier that is not itself personal data, such as an internal ID, and let your endpoint look up the rest. If your user IDs are email addresses or phone numbers, the same concern applies to them.

The response needs the same care. Braze states that it doesn't permanently log or store response bodies, and that it can hold them temporarily while rendering. The final rendered message is different. If Message Archiving is on, Braze may write the rendered message to your cloud storage bucket, and a Connected Content response inside it goes into the archived copy. After delivery, the rendered content can persist on user devices for an unknown amount of time. For Content Cards, Braze stores the rendered content in its database until the card expires. Personal data that your endpoint returns can therefore outlive the send.

Which identifiers and fields are acceptable depends on the rules that apply to your data. This post doesn't settle that, so check those rules before you decide what goes in a URL or a response.

Why does Braze make more Connected Content calls than sends?

Braze states that one send does not equal one Connected Content call, and that it does not guarantee a 1:1 ratio between sends and requests. Your endpoint has to handle more requests than the number of recipients.

Braze notes that recipients multiplied by two or three is often used as a conservative estimate for email. There is no separate Connected Content rate limit, because request volume scales with your message delivery speed rate limit. Lowering the delivery speed on a campaign is therefore the lever that protects your endpoint.

One consequence deserves a line in your design notes. Braze may call your endpoint more than once per recipient, so the endpoint should be safe to call twice. Keep counters, redemptions and any other side effect out of a Connected Content endpoint, and put them in a separate call that runs once.

What limits does your endpoint have to meet?

Braze documents a short set of hard edges. Check each one against your endpoint before you build the template.

The redirect rule catches people out. Braze notes that Postman and other clients often follow redirects automatically, so a URL can work in Postman and still render blank in Braze. Point the tag at the final URL.

What happens when a Connected Content call fails?

You have three documented ways to handle a failure, and they behave differently. Choose one per message, before you build it.

Canvas adds detail to retry. In a message step, recipients wait on the send queue while Braze retries, and if every attempt fails the message is aborted and the user moves to the next step. In Context and User Update steps, a failure after the retries makes the user exit the Canvas.

The choice follows from what the message is worth without its personalised part. A weekly digest can fall back to generic content. A message about an order should retry, because a generic version would mislead. A message that would be wrong or embarrassing without the data should abort.

Abort and retry interact. If a call uses abort logic for the same condition as its retry logic, the abort takes precedence and no retries happen. You can drop the abort check and the call still aborts after the final failed retry.

{% connected_content https://api.example.com/recommendations?user_id={{${user_id}}} :save connected :retry %}
{% if connected.recommendations.size < 5 %}
  {% abort_message('Could not get enough recommendations') %}
{% endif %}

The tag options in this example come from Braze's pages. The URL and the field names are placeholders for your own endpoint.

Braze also protects hosts that struggle. When a host shows a high rate of failures in one minute, Braze halts requests to it for one minute and simulates a failure response. The count includes 408, 429, 502, 503, 504 and 529 status codes. If you want halted calls retried, use :retry.

How should you cache Connected Content responses?

Braze caches get requests by default and does not cache post requests by default. The default cache age is five minutes. You can lengthen it with :cache_max_age, up to four hours, and you can switch caching off for a call with :no_cache. Responses larger than 1 MB are not cached.

Braze keys the cache on the workspace, the request URL, the content type and the request body. It is not keyed on a user ID or a campaign. A cached response can be reused across users, campaigns and Canvases in a workspace when those four match. Cache times are also only suggestions. The cache is volatile and Braze may evict data early, so you may see more calls than the cache time implies.

That has a security consequence. If your endpoint tailors its answer to the user, the URL or the body must carry what makes the answer differ. A header or a credential is not on Braze's key list. An endpoint that works out who the user is from one of those could see one user's cached response reused for another. Put the user identifier in the URL or body, or switch caching off with :no_cache.

Braze says caching may be skipped when the tag includes high-cardinality snippets. It lists six: the user ID, the Braze ID, email, email address, phone number and date of birth. Size a call built on one of them as uncached.

Switching caching off has its own cost. For an endpoint outside Braze infrastructure, :no_cache keeps the response body out of Memcached. It then lives only in worker memory for the rendering job, up to about 11 minutes. Braze warns that your endpoint then receives a request for every message, and that send latency will likely rise if it can't handle the bursts.

How do you test Connected Content before launch?

The Connected Content debugger shows the live request and response for each call in Preview and Test. Braze made it generally available on 17 September 2026, after an early access period that began on 20 August 2026. It shows the URL, method, status, headers, payload, duration and whether the response came from cache.

Check that your channel is covered. Braze says the debugger is not yet available for every channel, KakaoTalk among them, or for composition surfaces such as Content Blocks and the Canvas User Update step.

Retry needs a different test. Retry logic applies only to live sends, including test sends, and not to previews. A failed retry in a preview may show a message saying the content would not have been shown. To exercise retry, send a test.

What should you decide before the first call goes live?

As a Braze implementation partner, CustomerIK recommends writing down four decisions before the first template is built.

1. Who owns the endpoint, and how it is sized for recipients multiplied by two or three on email.
2. Which failure policy each message uses: fallback, retry or abort.
3. Which identifiers may appear in a request URL or a response, and where the rendered message is archived or stored.
4. Whether each call is cached, for how long, and what in the URL or body makes the response specific to one user.

Agreed once, those four lines turn Connected Content from a template trick into a service with an owner.

Frequently asked questions

Does Connected Content count toward data points?

Braze states that it does not charge for API calls and that they don't count toward your data point usage.

How long can my endpoint take to respond?

Braze requires a response in under two seconds. If the server takes longer, the content is not inserted.

Can I use retry in an in-app message?

Braze states that :retry is not available for in-app messages or Banners.

Why do my logs show more calls than recipients?

Braze may make the same call more than once per recipient, for example for each part of an email, and it doesn't promise a 1:1 ratio with sends.

Does Braze store the response from my endpoint?

Braze states that it doesn't permanently log or store response bodies, though it can hold them briefly for rendering and caching. The final rendered message can be stored, for example by Message Archiving or for Content Cards. Braze also keeps request metadata, including the fully rendered URL, for up to 30 days.

Can Braze reuse one user's cached response for another user?

Braze caches on the workspace, URL, content type and request body, not on a user ID, so a cached response can be reused across users when those match. Put whatever makes the response user-specific in the URL or body, or use :no_cache.

Sources

• Braze, Make a Connected Content API call. Retrieved 01 Oct 2026. braze.com/docs/user_guide/messaging/design_and_edit/personalize/connected_content/making_an_api_call
• Braze, Cache Connected Content responses. Retrieved 01 Oct 2026. braze.com/docs/user_guide/messaging/design_and_edit/personalize/connected_content/caching_responses
• Braze, Use retry logic for Connected Content. Retrieved 01 Oct 2026. braze.com/docs/user_guide/messaging/design_and_edit/personalize/connected_content/connected_content_retries
• Braze, Abort Connected Content. Retrieved 01 Oct 2026. braze.com/docs/user_guide/messaging/design_and_edit/personalize/connected_content/aborting_connected_content
• Braze, Local Connected Content variables. Retrieved 01 Oct 2026. braze.com/docs/user_guide/messaging/design_and_edit/personalize/connected_content/local_connected_content_variables
• Braze, Connected Content Debugger. Retrieved 01 Oct 2026. braze.com/docs/user_guide/messaging/design_and_edit/personalize/connected_content/debugger
• Braze, What's new in Braze. Retrieved 01 Oct 2026. braze.com/docs/releases/home/

Related reading on this site: hyper-personalisation in Braze campaigns, dynamic content delivery, tracking user events, CRM data in Braze, in-app message triggers.