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

# How many notifications a customer gets

> One per event, or one per value of a field: how a Transactional counts its sends, and what happens when an event arrives twice.

Every Transactional asks one question besides the event and the messages:
**how many notifications per customer?** There are two answers.

## One per event (the default)

Every time the event arrives, the customer gets the notification. Use it for
notifications where each event is its own thing, like a password reset or a
shipping update.

* Each event sends once.
* A customer gets one at a time: if two events for the same customer arrive at
  the same moment, only the first one sends.
* A retry of the same event sends again, even with the same `externalId`. If
  your system retries, or must never send the same thing twice, use **one per
  field value**.

## One per field value

Each different value of a field you pick gets its own notification, and a value
that comes again is skipped. Use it when a customer can have several of
something at once, like orders or appointments, and must never get the same one
twice.

Pick the field that is **different on every event**, usually an id: `orderId`,
`appointmentId`, `invoiceId`.

* Each distinct value sends **once, ever**, per customer.
* The same value arriving again for that customer sends **nothing**, so a retry
  never sends twice.
* Two different values for the same customer send **two** notifications, even
  at the same moment.

### An example

Your system records an `order_shipped` event each time an order ships, and the
Transactional sends one per `orderId`.

| Event received | `orderId` | What Boom does |
| - | - | - |
| Ana's first order | `ord_1` | Sends the notification |
| Ana's second order, at the same moment | `ord_2` | Sends it again, for this order |
| A retry of Ana's first order | `ord_1` | Nothing: `ord_1` already sent |

With **one per event**, the second order would be skipped (it arrived at the
same moment as the first), and the retry would send again.

### Choosing the field

* **Use an id that your system creates once per thing**, the same one you would
  use to look it up later.
* **Do not use a field shared by many events**, like the customer id, a status
  or an amount. A customer id would send only the first notification the
  customer ever gets, and never again.
* **Do not use a field that changes on a retry**, like a timestamp or a request
  id. Every retry would send again.

When the event has exactly one field ending in `Id`, choosing **One per field
value** starts from it. If your event has not arrived yet, type the field's
name; it only has to match what your system will send.

### Sending the field

Put the field in the event's `properties`:

```json theme={null}
{
  "name": "order_shipped",
  "externalId": "evt_001",
  "personExternalId": "cus_42",
  "properties": {
    "orderId": "ord_1",
    "trackingUrl": "https://track.example.com/ord_1"
  }
}
```

An event that arrives **without** the field, or with an empty one, sends
nothing, because Boom cannot tell which order it belongs to. So does a value
longer than 255 characters.

See [Send transactional messages](/transactional-messages) for the full set-up,
and [events](/events) for the event API.


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