.svg)
Triggered push notifications in Braze send when a user completes an event, rather than on a calendar date. You choose the trigger, a delay, any exception events, a time frame and a re-eligibility rule. Problems tend to sit where those choices interact, so this guide sets them up in sequence and shows where sends go missing.
Key Takeaways
- A triggered push sends after a user completes an event, not on a calendar date.
- The target audience works as a waiting room: users must already match it before the trigger fires.
- Users who completed the trigger event before the campaign launched don't qualify.
- An exception event only applies when the message sends after a time delay.
- A time frame or a long delay can remove a send by default, unless you choose the next available time option.
- Test by firing the event after launch, then confirm Braze received it.
What are triggered push notifications in Braze?
A triggered push is a campaign that waits for a user action. The Braze documentation puts it this way: "Instead of sending your campaign on certain days, you can trigger them to send after a user completes a certain event."
Braze offers three delivery routes for push. Messages can go out on a schedule, after an action, or from an API trigger, and each suits a different job.
| Delivery route | What fires the send | Choose it when |
|---|---|---|
| Scheduled | A date and time you set | The message is a planned broadcast |
| Action-based | A user event, such as a purchase or custom event | The message responds to behaviour |
| API-triggered | A call from your own servers | Your backend holds the signal first |
How do you set up triggered push notifications in Braze?
Work through the build in this order. The sequence matters because later settings depend on earlier ones.
- Create a campaign or a Canvas and choose the push platforms.
- Compose the title, body and on-click behaviour, then test.
- In the delivery step, choose Action-based and select the trigger event.
- Set the delay, then any exception events.
- Set the campaign duration and time frame.
- Decide on re-eligibility and frequency capping.
- Choose the target audience and conversion events, then review and launch.
Our suggestion is to build the audience last. What you learn in the earlier steps often changes who should be in it, and it works as a gate rather than a filter.
Why does a user in the audience still not get the push?
The target audience works as a waiting room. The documentation says that "Your message will only be sent to users who already match the conditions you set in the Target Audience step. After that, they still need to meet the trigger you define in the Schedule Delivery step."
Timing creates the second trap. Users who completed the trigger event before launch don't qualify, so a test that fired the event yesterday proves nothing.
Segmenting on user data recorded at the time of the event can cause a race condition. When the attribute can't reach Braze ahead of the event, the documentation's fix is to attach the relevant values as custom event properties and filter on the event property instead of a segmentation filter.
How should you set the delay and exception events?
A delay is a promise that the user still needs the message when it arrives. An exception event is how you keep that promise. Braze lets you choose an exception event that disqualifies users from the campaign, but only if the message sends after a time delay.
Users blocked by an exception event stay eligible the next time they complete the trigger, even if you didn't enable re-eligibility. Delays also depend on the event timestamp. If a backdated timestamp arrives, Braze may treat the delay as already elapsed and send earlier than you expect.
When a campaign has a delay, you can also tick Re-evaluate segment membership at send-time. That keeps users who left the audience during the wait from receiving the message.
How do time frames and quiet hours change delivery?
A time frame can remove sends you assumed were safe. If the user completes the trigger outside the time frame, or the delay pushes them past it, they don't receive the message by default.
You can rescue those users with the checkbox that sends at the next available time. For action-based delivery you can also set the duration and quiet hours on the same step.
We recommend deciding that checkbox deliberately for each campaign. A cart reminder that arrives the next morning can still help, while a delivery-day alert that arrives a day late has stopped being an alert.
What should you decide about re-eligibility?
Re-eligibility decides whether the same user can receive the campaign again. If you allow it, you can set a delay before the user can receive the campaign again.
Pair that with frequency capping from the same delivery step. For API-triggered campaigns the same idea applies, so a user receives the campaign once or once in a window however often your system fires the trigger.
When is an API-triggered campaign the better choice?
Choose the API route when the trigger lives on your servers rather than in the app. The documentation describes API-triggered campaigns as ideal for more advanced transactional use cases, and a payment confirmed by your backend is one example. Copy, multivariate testing and re-eligibility rules stay in the Braze dashboard, and your system sends the signal.
A few documented details save a debugging session. By default, send_to_existing_only is true on /campaigns/trigger/send, so the call won't create new profiles.
Use exactly two curly braces per Liquid tag in trigger_properties and in message copy. For transactional sends, set the delay to zero minutes so the user receives the campaign every time.
If your own servers will send that signal, CustomerIK's product engineering service covers custom middleware that connects your systems to the tools around them.
What does a cart reminder look like end to end?
Take a hypothetical retailer that wants a push after someone adds items and leaves. The trigger is the cart update, which accepts property filters so the send fires only for the carts you want.
The delay is the first real decision. A short wait feels like a nudge, and a long one risks the user having already bought elsewhere. The exception event is a purchase, so anyone who completes an order during the wait never sees the reminder.
Then check the failure modes in order. Confirm the event carried the cart details as properties and the time frame allows the send when the delay ends. Keep re-eligibility short enough that a second cart tomorrow can trigger again, and long enough that the user isn't nudged twice in one sitting.
This is an illustration of reasoning, not a recommendation of specific wait times. The right delay depends on the shopping pattern, and you should test it against your own conversion data.
How do you test and debug a triggered push?
Test with the event fired after launch, never before. Then work through the documented checks in order. First, confirm that the custom event is being passed to Braze.
If it is, compare the event timestamp with the time the campaign went live. After that, look at segment membership, control group assignment and any delay.
Device behaviour matters too. A user with several devices receives the push on all devices with a valid push token by default. Switching to a single device follows the newest push token, not the latest session.
On Android, a message that contains only a single space sends as a silent push notification.
How does this connect to the rest of the programme?
A triggered push rarely runs alone. Our guide to engagement triggers in Braze covers the wider event design behind it, and push notification segmentation shows how to define who is eligible.
Timing and content come next. Read optimising push notification timing before you settle on delays, and personalising push notifications for the copy. For specific journeys, see push for onboarding completion and retention message timing.
Events reach Braze through your SDK and API integration. For an example of a partner guiding a lean internal team through that work, read our case study on guided implementation and cross-agency alignment.
As a Braze implementation partner, CustomerIK recommends building one triggered push at a time and proving its trigger, delay and exception event in a test workspace before adding the next. Each added trigger multiplies the interactions you have to check.
Frequently Asked Questions
1. What is the difference between action-based and API-triggered push in Braze?
Action-based campaigns fire when a user completes an event Braze already records. API-triggered campaigns fire when your own system calls Braze.
2. Can a user receive a triggered push if they did the event before launch?
Users who completed the trigger event before the campaign launches don't qualify, so fire the event again after launch.
3. Why did my delayed push never send?
Common causes are an exception event, a missed time frame, or an ended campaign duration. Check each in that order.
4. Do exception events work without a delay?
An exception event only applies if the triggered message sends after a time delay.
5. Does a triggered push go to every device a user owns?
By default, yes, to all devices with a valid push token. You can limit delivery to a single device.
Sources
- Braze, Action-based delivery. Retrieved 30 Oct 2026.
- Braze, Create a push message. Retrieved 30 Oct 2026.
- Braze, API-triggered delivery. Retrieved 30 Oct 2026.
- Written by CustomerIK, a Braze implementation partner.
CustomerIK is a Braze implementation partner working across onboarding, technical integration, marketing operations and customer data management.
If you want a second pair of eyes on your triggered push setup, let's talk.
.svg)
