Preference center landing page

Question

I've built a drag and drop preference center in braze to use in my emails, now the new requirement is I want to add the same preference center in my website so that data is sent directly to braze without any intermediate data pipelines. But braze doesn't give a public URL for preference center.

How can i achieve the above? Anyone from here tried it before?

arrone_braze · Answer

@stefanie.baldwin I appreciate the efforts you've put into writing such a detailed answer.

Web SDK is ruled out as the team is reluctant to do it so will try out other suggestions from you.

Thank you soooo much, from my heart not a formality.

stefanie.baldwin · Answer

Option C — API preference center POST /preference_center/v1 lets you supply your own page and confirmation HTML, using Liquid for subscription group names and each user's status, with {{preference_center_submit_url}} as the form action. The design would be yours, the page would still be Braze-hosted, and Braze would own the writes. It replaces the drag-and-drop build rather than extending it (API email preference center, POST: Create Preference Center). Choosing • A, generate URL and redirect — one center for email and web with identical behavior in both, users logged in. Fastest to ship, nothing to maintain. • B, self-hosted form — the page must live on your domain (SEO, nav, consent copy, accessibility audits), or you need to save non-subscription fields in the same submit. • C, API preference center — you want your own HTML but don't want to own the write logic or the identity problem. If anonymous visitors need access, say from a link in a non-Braze email, that argues for A, since Braze creates the user-scoped URL and you don't have to invent a token scheme. Identity and security If you build Option B and identify the user from ?external_id=user_84213, anyone can enumerate IDs and change other people's subscriptions. Braze's guidance is not to use guessable external IDs (auto-increment database IDs, usernames, emails, phone numbers), and if you hash an existing identifier, to implement SDK Authentication to prevent impersonation (SDK Authentication). • Derive identity from your session cookie, or a signed short-lived token you generate. Never from a raw ID in the URL. • Turn on SDK Authentication for the Web SDK: you'd sign an RS256 JWT server-side and Braze would validate it against the public key in your dashboard. The private key never touches the browser. • REST API keys must never be publicly exposed, so Option B's curl belongs in your backend, not in a fetch() from the page. You can also IP-allowlist a REST key (REST API Key Overview, API Overview). Worked example Say user_84213 hits yourbrand.com/account/preferences while logged in. • Option A — your route would read the ID from the session, request that user's URL, and redirect. They'd untick Promotions & Offers, hit Save, and that group would flip to unsubscribed. Weekly Digest and Product Updates would be untouched, since state lives per group and isn't shared between groups. • Option B — the same submit would post to your backend, which fires the curl above. The result on the profile would be identical. • Either way, if they also untick "Keep receiving marketing email", the global state becomes unsubscribed and all marketing email stops regardless of group state. The group endpoints would still report Subscribed for Weekly Digest, though, because the global state supersedes group status without overwriting it. Show global state as its own control, or the page will appear to contradict itself. Five failure modes worth testing • Brand-new user, never touched a group — the status endpoint returns only groups with a prior status update, so a fresh user returns nothing. Default your checkboxes from your own config, not from an empty response. • Group returns Unknown — a documented third value alongside Subscribed and Unsubscribed. Don't render it as unsubscribed. • Global unsubscribed, group subscribed — no email sends, but the group still reads Subscribed. Make sure your UI reflects both layers. • Someone else's ID in the query string — must do nothing. Test it explicitly. • Ad blocker blocks the Web SDK — Option B's client-side write silently no-ops, which is the main argument for doing the write server-side. Happy to compare notes if you go the Option A route, curious whether the hosted page frames cleanly for you. Docs: Preference center · Drag-and-drop preference center · API preference center · Preference center endpoints · Subscription group endpoints · Email subscriptions · SDK Authentication

stefanie.baldwin · Answer

Option B — Rebuild the form on your own domain

If the page must live on your domain with your nav and styling, don't try to embed Braze's page. Render your own checkboxes and write to Braze directly. Do the write server-side, since that survives ad blockers and users with no SDK session:

# One call updates several groups. Auth: REST key with subscription.status.setcurl -X POST "https://rest.iad-03.braze.com/v2/subscription/status/set" \  -H "Authorization: Bearer $BRAZE_REST_KEY" \  -H "Content-Type: application/json" \  -d '{    "subscription_groups": [      { "subscription_group_id": "c1a4e0b2-51d7-4a83-9e11-3f7b2c8d4a60", "subscription_state": "subscribed" },      { "subscription_group_id": "f7e2d9c4-6b18-4c22-8d5a-91e0f3a7b2c5", "subscription_state": "unsubscribed" },      { "subscription_group_id": "b2c8a5f1-3d47-4e90-a1c6-7f2b9d0e4a18", "subscription_state": "subscribed" }    ],    "external_ids": ["user_84213"]  }'

The v2 endpoint handles multiple groups per request where v1 takes one, and accepts up to 50 identifiers (POST: Update users subscription group status v2). Use external IDs rather than emails when you need email and SMS groups in the same call. For the global email state, /users/track with "email_subscribe": "unsubscribed" is the documented path for a custom unsubscribe link (Email subscriptions, POST: Create and update users).

If you'd rather write from the browser on an already-identified session:

import * as braze from "@braze/web-sdk";braze.initialize("YOUR-WEB-SDK-API-KEY", { baseUrl: "sdk.iad-03.braze.com" });braze.changeUser("user_84213", YOUR_SDK_AUTH_JWT);   // JWT: see the security notebraze.openSession();const ALL = [  "c1a4e0b2-51d7-4a83-9e11-3f7b2c8d4a60",   // Weekly Digest  "f7e2d9c4-6b18-4c22-8d5a-91e0f3a7b2c5",   // Promotions & Offers  "b2c8a5f1-3d47-4e90-a1c6-7f2b9d0e4a18",   // Product Updates];document.getElementById("prefs").addEventListener("submit", (e) => {  e.preventDefault();  const checked = new Set([...document.querySelectorAll('input[name=grp]:checked')].map(i => i.value));  const user = braze.getUser();  ALL.forEach(id => checked.has(id)    ? user.addToSubscriptionGroup(id)    : user.removeFromSubscriptionGroup(id));  user.setEmailNotificationSubscriptionType(    document.getElementById("global").checked      ? braze.User.NotificationSubscriptionTypes.OPTED_IN      : braze.User.NotificationSubscriptionTypes.UNSUBSCRIBED  );  location.href = "/preferences/saved";});

The add and remove subscription-group methods are available on Web as well as iOS and Android, and the email-subscription setter takes the braze.User.NotificationSubscriptionTypes enum — Set user attributes through the Braze SDK, Integrate the Braze SDK (Web), Set user IDs.

To pre-tick the boxes, read current state with List User's Subscription Groups, or the single-group status endpoint if you only need one.