> ## Documentation Index
> Fetch the complete documentation index at: https://kb.aampe.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Real-time triggers

> Send a message every time a user does something, immediately or after a delay you choose.

Most Aampe messages use [Aampe optimised triggers](/user-guide/using-aampe/audiences/triggers). Those triggers make a user eligible, and your agents decide whether and when to message them.

**Real-time triggers** work the other way round. When a user does the thing you're waiting for, they get a message. Every time, at the time you set. Use them when the timing is the point:

* confirming a booking, order or sign-up;
* a follow-up a fixed time after an action, such as "a day after your first workout";
* reacting to a milestone, such as a personal best or a level completed.

> [!NOTE]
>
> Real-time triggers are switched on per account. If you see *"Real-time sends aren't enabled for this account"*, contact [support@aampe.com](mailto:support@aampe.com).

## Trigger types

When you create a trigger, choose its **trigger reaction timing**:

| Type | What happens |
| - | - |
| **Send immediately** | The user is messaged as soon as the trigger event happens. |
| **Send with delay** | The user is messaged a set time after the trigger event: minutes, hours or days, up to **30 days**. |

> [!WARNING]
>
> Once a trigger is saved or attached to a message, you can't switch it between real-time and Aampe optimised, in either direction. Create a new trigger instead. You can switch between Send immediately and Send with delay.

## How a real-time trigger works

1. A user does the **entry event**, for example `Cart Updated`.
2. The trigger notes the time and works out when to send: straight away, or after your delay.
3. At send time, Aampe checks that:
   * the trigger is still **live**;
   * the user hasn't done an **exit event** in the meantime;
   * the user is in the **audience** of at least one live message attached to the trigger.
4. If all three hold, Aampe picks a channel and the agent picks a message on it (see [Attach messages](#attach-messages)), then sends it.

If the user isn't in the audience of any live message at send time, **nothing is sent** for that event. Aampe doesn't wait for them to join an audience later. For **Send with delay**, this check happens when the delay ends, not when the event happens.

If Aampe can't send yet for another reason, it keeps trying for up to 48 hours. That covers a brand-new user whose data hasn't reached Aampe yet, a user with no contact address for the channel yet, and temporary problems on Aampe's side. If it still can't send after 48 hours, nothing is sent for that event.

## Set up a real-time trigger

1. Go to **Configure > Triggers** and click **+ Create**.
2. Under **Trigger reaction timing**, choose **Send immediately** or **Send with delay**.
3. Choose the **entry event**: *"Start triggering messages for a user if:"*.
4. For **Send with delay**, set the delay: *"Once the trigger event is met, send the messages after"*.
5. *(Optional)* Add one or more **exit events**: *"Unless the following exception event occurs:"*. If the user does an exit event before the message goes out, it's cancelled.
6. For **Send with delay**, choose what happens on a repeat (see [Repeat events](#repeat-events)).
7. Name the trigger and click **Save**.

New triggers start **paused**, so saving one doesn't send anything yet.

## Attach messages

Attach messages to the trigger the same way as any other trigger. In the **Message Composer**, click the **Trigger** box, pick the trigger and save.

* **Use audiences** to control who can receive each message. A message with no audience can go to anyone who does the entry event. Audiences are checked when the message sends, not when the event happens.
* **Only live messages count.** If you pause or edit a message, the trigger keeps running, and sends that come due use whichever attached messages are live at that moment.
* **Supported channels: email, push, SMS and WhatsApp.** Messages on other channels (in-app, web push, content cards, surfaces) are ignored by real-time triggers.

Each time the trigger fires, the user gets **one** message. It's chosen in two steps:

1. **Channel, in a fixed order.** Aampe tries the channels of the attached messages in this order: email, push, SMS, then WhatsApp. It uses the first channel where the user is in the audience of at least one live message and can be reached, for example has an email address. If they can't be reached on a channel, Aampe moves on to the next.
2. **Message, chosen by the agent.** If several eligible messages are on that channel, the agent picks one of them. Attach more than one message on a channel if you want variety.

The agent doesn't choose the channel. For example, if a user is eligible for both an email and a push message, they get the email. They only get the push if they can't be reached by email.

## Turn the trigger on: Live and Paused

Each real-time trigger has a **Trigger status** switch. **Only this switch** turns the trigger on or off. A message's status doesn't.

* **Live:** events qualify and messages send.
* **Paused:** nothing new qualifies, and any delayed send that comes due while the trigger is paused is cancelled.
* **Back to live:** events that happened during an *earlier* live period still qualify. For example, if a user's delayed message was due after you resumed, it still sends. Events that happened *while the trigger was paused* never qualify.
* **Archived** triggers are always paused.
* Switching takes **a few minutes** (up to about 6) to take full effect.

> [!TIP]
>
> Only events that happen **after** you set a trigger live can send messages. Turning a trigger on doesn't message everyone who did the event earlier.

## Repeat events

For **Send with delay**, choose what happens if the user does the entry event again before their message sends. *"If the trigger event happens again before the message sends:"*

| Option | What happens | Good for |
| - | - | - |
| **Restart delay on repeat** *(default)* | The wait starts again from the latest event, but a message is never pushed back more than **24 hours** past its original send time. | Abandoned cart: each new add-to-cart restarts the wait. |
| **Keep first** | Repeats are ignored, and the original send time stands. | One-time milestones, like a first purchase. |

For **Send immediately**, repeats are ignored while the user's message is still waiting to go out. That's usually about a minute. A user who isn't in any message's audience is skipped straight away, so their next entry event is handled as normal. But if Aampe is still waiting on the user's data, for example a brand-new user or one with no contact address yet, it keeps trying for up to **48 hours** (see [How a real-time trigger works](#how-a-real-time-trigger-works)), and repeats during that time are ignored. Once the message has gone out, or Aampe has given up on it, the next entry event starts again.

## Frequency limits

Real-time sends **aren't held back by** the [frequency limits](/user-guide/using-aampe/admin/frequency-limits) you set in Aampe. Those limits apply to Aampe optimised triggers. A real-time trigger sends one message every time its entry event happens, so a user who repeats the event often can get many messages.

To control how often a user gets real-time messages:

* use **Send with delay** with **Keep first** or **Restart delay on repeat** (see [Repeat events](#repeat-events)), so repeats close together send only once;
* add **exit events** and **audiences** so only the users you mean to reach qualify;
* rely on your **messaging provider's** own frequency caps. They still apply to real-time sends, unless you've turned on the option to override them for that message (available for some providers; see the [Frequency FAQ](/user-guide/using-aampe/admin/frequency-limits)).

## Changing a live trigger

Changing a live trigger's **entry or exit events** restarts it. Before saving, you'll be asked *"Restart this live trigger?"*:

* **pending sends are cancelled;**
* **only events after the change qualify.**

Changing the **delay** or the **repeat** setting isn't a restart. The new setting applies to events from then on.

## Timing and data

* **Events have to reach Aampe to count.** If your events are sent to Aampe in real time, messages go out within about a minute of the event, or at the end of your delay.
* **Events loaded in daily batches** are processed when the batch arrives. A **Send immediately** message then goes out shortly after that day's data lands, rather than at the moment of the event. A delayed message goes out at the end of the delay, but never sooner than about 15 minutes after the batch arrives.
* **Events more than 48 hours old** when they reach Aampe are skipped, so an old backlog doesn't send a burst of late messages.
* The user also needs a contact address for the message's channel, such as an email address or push token. Aampe takes it from your user data.

## Checklist before going live

* [ ] Real-time sends are enabled for your account.
* [ ] The trigger has the right entry event and any exit events.
* [ ] At least one live **email, push, SMS or WhatsApp** message is attached, with the audience you intend (or none, to reach everyone).
* [ ] Your channel integration for those messages is set up.
* [ ] You've switched **Trigger status** to **Live**, and waited a few minutes before checking for the first sends.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.