Capability
A million recipients, and a list that cannot move under you.
An audience is a resource with a version and a seal, not a payload attached to a send call. That single decision is what makes very large sends reliable, reports honest and interrupted jobs resumable at no extra cost.
A list that grows mid-send makes the report describe a moving target.
Sealing is required before an audience can be used, and it is one-way. A changed audience is a new build rather than an edit, which gives you a clean audit trail of exactly who a given send targeted — a question that is easy to ask afterwards and impossible to answer if the list kept changing.
Every append carries an idempotency key you supply, so a retried chunk upload never writes twice. Networks fail mid-request as a matter of routine, and a system that treats that as exceptional produces duplicates.
- Up to 1,000,000 recipients per audience
- Appended in chunks of 50,000 per request, stored in shards of 20,000 per document
- Twenty open audiences per tenant, so a runaway integration is noticed quickly
- A default 30-day time-to-live, because an audience is personal data in its own right
What happens when a sealed list meets live consent.
Streamed, never loaded
The sender reads one 20,000-person shard at a time and never holds a million identifiers in memory. The same property is what makes an interrupted send resumable without extra bookkeeping.
Consent re-checked per recipient
An audience never overrides the per-recipient compliance check. Sealing freezes who was selected, not whether they may be contacted.
Counted, not enumerated
Reading an audience through the API returns its size and seal state, never the member list. It is a list of people, and it is treated like one.
Limits and behaviours.
Questions about audiences
Can I still send to everybody?
Yes, but it has to be said explicitly on the send call rather than left as an empty field. That is a deliberate change following a defect where an unset audience silently meant the whole tenancy.
What if a chunk upload fails halfway?
Retry it with the same idempotency key. The append is not applied twice, so a network failure costs you a retry rather than a duplicated list.
Can I edit a sealed audience?
No — build a new one. That is what makes the trail clean: each send points at exactly one immutable list, and 'who did this go to' has a single answer.
Is an audience personal data?
Yes, and it is treated as such: tenant-scoped, given a default 30-day lifetime, never enumerated through the API, and re-checked against live consent and erasure every time it is used.
Related capabilities
Volume changes the conversation more than almost anything else. We will tell you quickly whether this shape fits.