.svg)
You have three routes for sending transactional email from your own systems into Braze. These are the dedicated Transactional Email endpoint, an API-triggered campaign, and the messages endpoint. The right one depends on who owns the copy and who owns eligibility. Decide that first, because each route changes what you can schedule, test, suppress and track.
Key Takeaways
- Pick the route by two questions: who edits the copy after launch, and where eligibility is decided.
- The Transactional Email endpoint names one user per request and treats the whole user base as eligible, including unsubscribed users.
- It has no scheduling, re-eligibility, frequency capping or conversion tracking, so your own service is the only eligibility gate.
- Build the external_send_id from the order and the message type, because Braze stores it as a deduplication key for 24 hours.
- Status postbacks tell you whether a message arrived, and Braze describes using them to reach the user on another channel if it didn't.
- Write four decisions down before the first template: route, eligibility owner, key format and waiting window.
What counts as a transactional email in Braze?
Braze describes a transactional email as an automated, non-promotional email message that facilitates an agreed-upon transaction. Its own examples are order confirmations, password resets, billing alerts and shipping alerts.
The name is easy to confuse with something else. Braze states that transactional emails differ from transactional campaigns, which can be used to target your users without additional costs. Use the exact term in briefs, so nobody scopes the wrong feature.
Availability comes first. Transactional Email is only available as part of select Braze packages, and Braze points you to your customer success manager. Settle that before you design anything around it.
Which Braze transactional email route should you choose?
We group the ways to send transactional-style email from your own systems into three routes. They differ on where the content lives, who can be targeted and which campaign controls still apply.
RouteWhere the copy livesWho can be targetedCampaign controlsTransactional Email endpointA Braze dashboard campaignOne user per request, with the whole user base eligible, including unsubscribed usersNo scheduling, re-eligibility, frequency capping or conversion trackingAPI-triggered campaignA Braze dashboard campaignUp to 50 named recipients per request, or an audience segment defined in the requestCopy, multivariate testing and re-eligibility rules managed in the dashboardMessages endpointYour backend, inside the request bodyUsers who already exist in BrazeMessage delays and A/B testing can be added as extensions
Two questions decide the route. One is who edits the copy after launch. The other is where eligibility gets decided. When your service decides eligibility and engineers own the template, we recommend the dedicated endpoint. When marketers need to test copy or limit repeat sends, we recommend an API-triggered campaign. When your backend produces the content itself, the messages endpoint fits.
How do you set up the Transactional Email route?
The setup is short, and each step produces something the next step needs.
- Create a campaign and select Transactional Email as the messaging channel.
- Compose the email or choose a template, then note the campaign ID that Braze generates.
- Generate an API key with the
transactional.sendpermission. - Send requests to the transactional send path for that campaign ID, naming exactly one recipient.
- Set the Transactional Event Status Postback URL under Settings, then Email Preferences.
{
"external_send_id": "YOUR_BUSINESS_KEY",
"trigger_properties": { "YOUR_PROPERTY": "YOUR_VALUE" },
"recipient": { "external_user_id": "YOUR_USER_ID" }
}
The field names above come from the endpoint page, and every value is an example for you to replace. The request goes to /transactional/v1/campaigns/{campaign_id}/send, and it must name a single user by external user ID or user alias.
If you pass an external user ID that doesn't exist yet, passing any fields in the attributes object creates the profile. Send several requests for the same user with different data, and Braze updates first name, last name and email synchronously. It templates them into the message. Custom attributes don't have that protection, so take care when you pass different custom values in quick succession.
What does the dedicated route leave out?
Braze removed several campaign controls so that all users are reachable for these critical transactional alerts. Scheduling options are gone, as are re-eligibility controls and frequency capping. The Conversions step is removed too, because transactional emails don't support conversion event tracking.
There's no audience step either. Braze treats the entire user base as eligible, including unsubscribed users. Any recipient logic has to run before you decide whether to make the API request.
That makes your own service the only eligibility gate. We recommend naming the owner of that logic and writing the rule down. The campaign settings that would normally filter the send aren't there.
Two content rules follow. Braze doesn't support the Connected Content or Promotion Code tags in any field of a transactional email. The first needs an outbound API request during sending, and the second needs additional processing. Fetch any external data in your own service and pass it in through trigger properties instead.
Message Archiving is supported on this route, and Braze saves a rendered copy of each transactional email send. Anything you template into the message is in that copy.
Braze scopes this route to non-promotional messages. It says it doesn't add one-click unsubscribe to this campaign type, and you can add it by editing the setting under Sending Info. Whether a message counts as transactional under the law that applies to you is a question for your legal and security reviewers. This post doesn't settle it. Keep promotional copy out of these templates.
How do you make Braze transactional email sends safe to retry?
Braze gives you a deduplication key for this. The optional external_send_id is a string that Braze stores for 24 hours as a deduplication key. Passing the same identifier in another request doesn't result in a new instance, so a retry inside that window won't send a second email. If you intend a new message, use a new identifier.
That behaviour decides how to build the key. We recommend using the business event rather than the order alone, by combining the order number with the message type. A confirmation and a shipping alert for the same order are different messages. A shared key would suppress the second one for 24 hours.
How do you know a transactional email arrived?
Braze sends status postbacks to a URL you set under Settings, then Email Preferences. Each one carries a dispatch_id that Braze generates, plus your external_send_id if you passed one, so you can match events to your own records. Braze describes using them to evaluate message status in real time. You can reach the user on another channel if the message goes undelivered, or fall back to an internal system if Braze is experiencing latency.
Aborted and bounced events include a reason field. Braze describes it as the reason Braze or the inbox provider was unable to process the message. That makes it the first place to look when a customer says nothing arrived. We recommend setting your own waiting window for a missing delivered event, based on how time-sensitive each message is. A password reset needs a short window, and a copy of an invoice can wait longer.
Plan for volume as well. The endpoint is a paid-for endpoint in units per hour, for example 50,000 per hour depending on your package. Braze says you can send beyond your allotted volume, but only the allotted volume is covered by the service level. Within it, 99.9% of emails send in less than one minute.
Requests to this endpoint also count toward your overall external API rate limit. If you exceed that limit, Braze returns 429 and throttles requests, and its example is 250,000 requests per hour across all endpoints.
What changes with the other two routes?
An API-triggered campaign keeps copy, multivariate testing and re-eligibility rules in the Braze dashboard while your servers trigger the send. By default, send_to_existing_only is true, so Braze sends the message only to existing users.
If the profile has no email address at trigger time, Braze retries for up to approximately 2 hours while waiting for profile data. Including the email address in the attributes object of the same call avoids that delay. For anything time-critical, we suggest designing around that retry window, because a password reset that waits on a profile write defeats its own purpose.
For a transactional use case, Braze advises setting the delay to zero minutes. The user then receives the campaign every time they do the transaction. It also says to use exactly two curly braces per Liquid tag, because an extra brace is a common cause of API-triggered personalisation failures.
The messages endpoint suits content that your backend produces. Each recipient must already exist in Braze, because API-only sends don't create profiles. Call the user tracking endpoint first, or choose an API-triggered campaign. The key needs the messages.send permission, and the body accepts HTML with Liquid personalisation.
What should you test before go-live?
We suggest testing in this order, so each check builds on the last. Run every step in a test setup that you control, with recipients you own, and never with live customers.
- Send the same
external_send_idtwice and confirm the second request doesn't produce a second email. - Trigger an aborted case, such as a user with no emailable address, and confirm your postback handler records the reason.
- Confirm your service stops promotional or ineligible sends before the API call, because the route won't filter them for you.
- Time the gap between the API call and the delivered event, then set the waiting window from that evidence.
- Check what your service does on a 429 response, and make sure it retries with the same key rather than a new one.
One failure mode to plan for is a key built from the order number alone. The shipping alert then shares an identifier with the confirmation, so it isn't treated as a new message for 24 hours. A key built from the order and the message type avoids that.
What should you write down before the first template?
As a Braze implementation partner, CustomerIK recommends capturing four decisions on one page before the first template is built.
- Which route each message type uses, and who owns its copy.
- Who owns the eligibility logic that runs before the API call.
- The format of the external_send_id key.
- The waiting window that turns a missing delivered event into an incident.
Agreed once, those four lines stop each engineer making the choices differently.
How does this connect to the rest of the programme?
بالنسبة لجانب الإرسال، راجع إعدادات قابلية تسليم البريد الإلكتروني. توضح Braze أن عمليات الإرسال عبر نقطة نهاية الرسائل تظهر معدلات الفتح والنقر والارتداد إلى جانب حملاتك وCanvas الأخرى. وهذا هو المكان الذي ينطبق فيه تقارير حملات البريد الإلكتروني . ينطبق الاهتمام نفسه بالتسمية على تتبع أحداث المستخدم.
حيث يتولى المسوقون مسؤولية صياغة المحتوى، التخصيصوالمحتوى الديناميكي هي ما يحافظ على فائدة القالب الذي يتم تشغيله عبر واجهة برمجة التطبيقات (API) بعد إطلاقه.
الأسئلة الشائعة
1. ما الفرق بين البريد الإلكتروني للمعاملات وحملة المعاملات في Braze؟
إنهما أمران مختلفان. البريد الإلكتروني للمعاملات هو نوع حملة مستقل، متاح في باقات مختارة من Braze. أما حملة المعاملات فيمكن استخدامها لاستهداف مستخدميك دون تكاليف إضافية.
2. هل يمكن لرسائل البريد الإلكتروني للمعاملات من Braze الوصول إلى المستخدمين الذين ألغوا اشتراكهم؟
نعم. تتعامل Braze مع قاعدة المستخدمين بأكملها على أنهم مؤهلون، بما في ذلك المستخدمون الذين ألغوا اشتراكهم. احرص على أن يكون المحتوى غير ترويجي. أما ما إذا كانت الرسالة تُصنف كرسالة معاملات بموجب القانون المطبق عليك، فهذا سؤال يجب توجيهه إلى فريقك القانوني والأمني.
3. ما المدة التي تحتفظ فيها Braze بمعرف external_send_id؟
تخزنه Braze كمفتاح لإلغاء التكرار لمدة 24 ساعة، لذا فإن تمرير المعرف نفسه خلال هذه الفترة لا يؤدي إلى إنشاء مثيل جديد.
4. ما هي أذونات مفتاح واجهة برمجة التطبيقات (API) التي يحتاجها كل مسار؟
تحتاج نقطة نهاية البريد الإلكتروني للمعاملات إلى transactional.send. وتحتاج نقطة نهاية الرسائل إلى messages.send. أما نقطة نهاية التشغيل للحملات التي يتم تفعيلها عبر واجهة برمجة التطبيقات فتحتاج إلى campaigns.trigger.send.
5. هل يمكنني استخدام المحتوى المتصل (Connected Content) في بريد إلكتروني للمعاملات؟
لا. توضح Braze أنها لا تدعم علامات المحتوى المتصل (Connected Content) أو رموز العروض الترويجية في أي حقل من حقول حملة البريد الإلكتروني للمعاملات، لأن كلاهما يضيف عمليات معالجة أثناء الإرسال.
المصادر
- Braze،إرسال رسائل البريد الإلكتروني للمعاملات باستخدام التسليم عبر واجهة برمجة التطبيقات (API). تم الاسترجاع في 06 أكتوبر 2026.
- Braze،إنشاء بريد إلكتروني ترويجي. تم الاسترجاع في 06 أكتوبر 2026.
- Braze،التسليم عبر واجهة برمجة التطبيقات (API). تم الاسترجاع في 06 أكتوبر 2026.
- Braze،إرسال رسائل الحملات باستخدام التسليم عبر واجهة برمجة التطبيقات (API). تم الاسترجاع في 06 أكتوبر 2026.
- Braze،إرسال رسائل البريد الإلكتروني باستخدام REST API. تم الاسترجاع في 06 أكتوبر 2026.
- بقلم CustomerIK، شريك تنفيذ معتمد لـ Braze.
CustomerIK هي شريك تنفيذ لـ Braze، وتعمل في مجالات الإعداد، والتكامل التقني، وعمليات التسويق، وإدارة بيانات العملاء.
إذا كانت تأكيدات الطلبات وإعادة تعيين كلمات المرور في شركتك تعتمد على مهندس واحد يتذكر كيفية عملها، فلنتحدث.
.svg)
