> For the complete documentation index, see [llms.txt](https://developers.bead.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.bead.xyz/faqs-and-troubleshooting/environment-and-testing/test-data-uniqueness-requirements.md). # Test data: uniqueness requirements The system applies uniqueness checks to several fields when an onboarding application reaches the boarding layer. These checks apply in Sandbox as well as Production. Reusing the same values across test applications is the most common cause of unexpected rejections during integration testing. Use this page to generate test data that stays unique across repeated and parallel test runs. #### Fields that must be unique | Field | Where it is sent | What to do | | -------------------- | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | Signer email | `signerEmail` (short application) or the stakeholder marked `isApplicationSigner: true` (full application) | Use a new address for every test application. | | Business name | `merchantName` (short application) or the legal business name in `merchantData` (full application) | Use a distinct registered business name for every test application. | | Signer name | `signerFirstName` and `signerLastName` (short application) or the signer stakeholder (full application) | Vary the name for every test application. | | Merchant identifiers | `partnerMid` and `partnerExternalId` | Use a unique value for every test application. | Reusing business names or signer names across many applications can trigger duplicate checks at the boarding layer, even when the email address is new. #### Signer email The signer receives a real email, so use an address you can access. The recommended approach is plus addressing with a timestamp tag. Most mail providers deliver `name+tag@domain` to the `name@domain` inbox. ``` qa+20260127143015@yourcompany.com ``` Build the tag from `YYYYMMDDHHMMSS` so every value is unique and sorts in the order the tests ran. **Parallel test runs** If several tests can start in the same second, add a run identifier or counter after the timestamp so two runs never produce the same address. ``` qa+20260127143015r1@yourcompany.com qa+20260127143015r2@yourcompany.com ``` **If plus addressed emails do not arrive** * Confirm your mail provider or security gateway does not block or strip tagged addresses. * Check spam and quarantine folders. * If tagged addresses are blocked, use a catch all mailbox on a domain you control, or create a distinct mailbox per test. #### Business name Use a distinct registered business name for every test application. A simple approach is to append a numeric suffix or short identifier to a base name. ``` Northwind Coffee Roasters 001 Northwind Coffee Roasters 002 ``` Avoid reusing the exact same business name across applications, even across different test runs. #### Signer name Use a varied signer name for every test application. A lightweight approach is to keep a fixed first name and add a sequence number or short random suffix to the last name. ``` Morgan Reed 001 Morgan Reed 002 Morgan Reed 8f3a ``` The signer name does not need to be a real person's name, but it should be unique per application. #### Merchant identifiers Use a unique `partnerMid` and, where you send it, `partnerExternalId` for every test application. Matching the sequence number you use in the business name makes test records easy to correlate. ``` northwind-sandbox-001 northwind-sandbox-002 ``` #### Putting it together The short application example below follows every pattern on this page. ```json { "merchantName": "Northwind Coffee Roasters 001", "partnerId": "{partnerId}", "partnerMid": "northwind-sandbox-001", "signerFirstName": "Morgan", "signerLastName": "Reed 001", "signerEmail": "qa+20260127143015@yourcompany.com", "cryptoEnvironment": "sandbox", "submitImmediately": true } ``` This is an abbreviated example that omits `feeInformation`. See [Sample Payload](/onboarding/sample-payload.md) for complete request bodies. #### Troubleshooting a rejected application If an application is rejected and you are running repeated tests, check that: * the signer email has not been used on an earlier test application * the business name is distinct from previous test applications * the signer name has not been reused across many applications * `partnerMid` and `partnerExternalId` are unique If the values are unique and the application is still rejected, contact your Bead team with the `applicationId`. #### Related pages * [Test the Full Onboarding Workflow in Sandbox](/onboarding/test-the-full-onboarding-workflow-in-sandbox.md) * [Submit Application](/onboarding/submit-application.md) * [Sample Payload](/onboarding/sample-payload.md) --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://developers.bead.xyz/faqs-and-troubleshooting/environment-and-testing/test-data-uniqueness-requirements.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.