> For the complete documentation index, see [llms.txt](https://knowledge-base.letsgetdigital.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledge-base.letsgetdigital.com/pricing-and-packaging/subscription-container/unique-emails.md).

# Unique Emails

{% hint style="info" %}

#### Tip: 

When containers are not being used, it is still possible to force users to use unique email addresses using the following setting:

* [**Only allow unique emails**](/the-admin-panel/settings/general-settings-app-+-vp-1/registration-and-pre-event-page-settings.md#only-allow-unique-email-addresses)
  {% endhint %}

### Unique emails in Subscription Containers

When a subscription containe**r** is used, one environment acts as the master, and all linked events become **child environments**.

If the **Container master mode** is set to **Unique emails**, this rule applies to **all child environments** linked to that container.

This is re**quired to support cross-event access wi**thin a container.

<div data-with-frame="true"><figure><img src="/files/RyLIC7G8DkG42ZFSM1N4" alt="" width="563"><figcaption><p>Environment is set to act master (container) with the unique emails mode.</p></figcaption></figure></div>

### What does “Unique emails” mean?

When **Unique emails** is enabled:

* A single email address can be used to register for multiple child environments
* Users can log in once and switch between events they are registered for
* The system can reliably recognise and verify returning users across events

### When should you use Unique Emails?

Unique emails are recommended when:

* You run **multiple related events**
* Attendees regularly attend more than one event
* You want users to switch between events without creating new accounts
* You need stronger protection against account misuse

<div align="center" data-with-frame="true"><figure><img src="/files/lA423PIUjOSMK4LEH3ST" alt="" width="188"><figcaption><p>List of linked events in app</p></figcaption></figure></div>

### How the system works

* User identity data is stored centrally at the container (master) level
* When a user registers for a new child environment:
  * The system checks whether the email address already exists within the container
  * **If the email does not yet exist**:
    * A new user is created as part of a standard registration flow
    * The user record is added to the container and linked to the child environment
  * **If the email already exists**:
    * The user is required to verify their identity via email
    * After successful verification, a new user record is created in the child environment
    * If the verification code is not used, the user is not created
* The user can then:
  * Log in using the same credentials
  * Switch between all events where their email address is registered

This approach provides both  convenience for returning attendees and security against unauthorised access.

<div data-with-frame="true"><figure><img src="/files/G8JYbVuiEriN0vyGRGZT" alt=""><figcaption><p>User must enter verification code when registering with existing email.</p></figcaption></figure></div>

### Imported users and external systems

When users are imported from external sources (for example ticketing partners like **Weeztix** or tools like **HubSpot**):

* Multiple users may share the same email address
* To keep users distinguishable, the system automatically makes email addresses unique
  * Example: `name+12345@email.com`
* All emails are still delivered to the same inbox

These users can later be corrected by:

* Editing the email address in the Admin Panel, or
* Reassigning tickets to the correct attendee


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://knowledge-base.letsgetdigital.com/pricing-and-packaging/subscription-container/unique-emails.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.