# Test data: email address requirements

When running automated testing against the Boarding API and Application flows, please use valid, deliverable email addresses and ensure each application uses a unique email address.

This prevents:

* Message undeliverable and bounce back noise in our email systems
* Test failures caused by duplicate email reuse when unique emails are expected
* Confusing support investigations caused by blocked or invalid destination addresses

### Requirements and Best Practices

#### Use a valid, deliverable email address

Use an email address that can receive mail. Avoid obviously invalid domains (for example `@example.fake`) or malformed addresses.

If your test does not need to receive the email content, you can still use a deliverable address, but route it to a mailbox you control for testing.

#### Use a unique email per application

Our system expects each application to have its own unique email address. Reusing the same email across many applications can lead to validation failures or unexpected results.

Best practice:

* One email address per application record

### Recommended Email Uniqueness Patterns

#### Option A: Plus addressing (+tag)

Most common email providers support plus addressing, which treats everything after `+` as a tag while still delivering to the same mailbox.

Pattern:

* `youraddress+tag@domain.com`

Examples:

* `qa+1@yourcompany.com`
* `qa+2@yourcompany.com`
* `beadtest+boarding@yourcompany.com`

This is a good default for small scale testing.

#### Option B: Plus addressing with timestamp

For automated testing, use a timestamp based tag so every request is unique.

Recommended tag formats:

* `yymmddhhmmss`
* `yyyymmddhhmmss`

Examples:

* `qa+260127143015@yourcompany.com`
* `qa+20260127143015@yourcompany.com`

Notes:

* Keep the tag numeric and compact for easier log searching
* Ensure your generator uses the local time or UTC consistently within your test suite

#### Option C: Timestamp plus sequence counter

If your test can create multiple applications within the same second, add a short counter to avoid collisions.

Examples:

* `qa+20260127143015-01@yourcompany.com`
* `qa+20260127143015-02@yourcompany.com`

If you want to keep the tag purely numeric:

* `qa+2026012714301501@yourcompany.com`

### What Not To Do

Avoid these patterns:

* Reusing the same email across many applications (example: always `qa@yourcompany.com`)
* Using non deliverable domains (example: `@nope`, `@invalid`, `@fake`)
* Using mailbox names that will cause large bounce volume (example: random addresses at a corporate domain that rejects unknown users)

### Suggested Implementation in Automated Tests

#### Simple generator rule

1. Choose a base mailbox that is deliverable and controlled by your team, for example `qa@yourcompany.com`
2. Convert it to a tagged address with a timestamp
3. Optionally add a sequence when generating multiple emails quickly

Example output set:

```
qa+20260127143015@yourcompany.com
qa+20260127143015-01@yourcompany.com
qa+20260127143015-02@yourcompany.com
qa+20260127143016@yourcompany.com
```

#### Example pseudo logic

```
base = "qa@yourcompany.com"
timestamp = yyyymmddhhmmss(now)
counter = 1..N within the same second

email = "qa+" + timestamp + "-" + twoDigit(counter) + "@yourcompany.com"
```

If you are only generating one email per second, you can omit the counter.

### Troubleshooting

#### Emails are not being delivered

Common causes:

* Your mail provider does not support plus addressing
* Your organization has mail rules that strip or block tagged addresses
* The address is not deliverable, or the domain rejects unknown recipients

What to do:

* Confirm plus addressing works for your domain
* If it does not, use a catch all mailbox, or create a dedicated test mailbox list (for example `qa1@`, `qa2@`, `qa3@`)
* Keep the uniqueness rule, even if you use a different strategy

#### Duplicate email validation failures

If you see application failures that look like email uniqueness issues:

* Confirm your test data generator is producing a unique value per application
* Add the timestamp and counter strategy above
* Avoid parallel test workers sharing the same base tag logic without coordination


---

# Agent Instructions: 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:

```
GET https://developers.bead.xyz/faqs-and-troubleshooting/environment-and-testing/test-data-email-address-requirements.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.