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

# Test accounts and sign-in

> Give Mini the accounts it signs in with, attach them to scenarios, and set up email codes, Google sign-in and phone sign-in.

A test account is a user Mini signs in as during a run. This page shows where test accounts live, how to attach them to scenarios, and what to set up for each kind of sign-in your app uses.

| Your app signs in with | What you put on the test account |
| - | - |
| Email and password | An **Email address** and a **Password** for an account that exists in your app |
| An email code or a magic link | An `@qa.minitap.ai` address. Mini reads the code from its inbox |
| Sign in with Google | Nothing to create: attach the Google account under **Shared by Minitap** |
| A phone number and an SMS code | **Phone login**, with a **Phone number** and a **Static OTP code** you pin in staging |
| Nothing, or a public flow | No test account at all |

## Where test accounts live

Test accounts belong to an app. Open the app and go to **Builds & test data → Test accounts**: the page lists **Yours** and the accounts **Shared by Minitap**, and **Add account** creates a new one.

![Builds & test data, Test accounts: a Customer account whose password and test card point to secrets, then Google and New user accounts shared by Minitap](https://mintcdn.com/minitap-30239763/QCLbAMcddko_3eZy/minitest/images/app/test-accounts.png?fit=max\&auto=format\&n=QCLbAMcddko_3eZy\&q=85\&s=9a2b5d98c15e7389ff723c1440bbd54b)

Your accounts first, then the ones Minitap shares.

| Field | What it's for |
| - | - |
| **Name** | How you and Mini refer to the account, like `Premium subscriber` or `Admin`. |
| **Note** | Who this user is: plan, saved data, anything Mini should expect. Without a note, Mini has no context about the account. |
| **Email address** | The address Mini signs in with. Pick the `qa.minitap.ai` domain for an inbox Minitap hosts, or **Custom domain** for your own. |
| **Password** | Stored encrypted. Leave it empty for an email-code sign-in. |
| **Phone login** | Turns on **Phone number** and **Static OTP code**, see [phone number sign-in](#phone-number-sign-in). |
| **Test card** | A sandbox card your payment provider accepts in test mode, for scenarios that go through checkout. Every field is optional. |
| **Use by default** | New scenarios are created with this account unless you pick another one. |
| **One run at a time** | Other tests wait for this account to free up. Turn it on when your app allows a single active session per account. |

Register the account in your app first, unless the scenario is a sign-up flow. As you fill the fields, **What Mini can do** sums up which sign-ins Mini can complete with this account, and what is still needed on your side.

## One account per kind of user

Create one test account for every kind of user whose journeys differ: a free user, a subscriber, an admin, a driver. The note is what tells Mini which is which, so write what makes each one different ("Active premium subscription, 3 saved addresses").

Use dedicated test users. A failed run can leave an account in an odd state, like a half-finished checkout, and that is easier to live with on a test user than on a real one.

For sign-up journeys, **Shared by Minitap** also lists **New user**: it signs up from scratch on each run, and Mini maintains it.

## Attach accounts to scenarios

Open a scenario, go to its **Setup** tab and click **+ Add test account** under **Test accounts**. A scenario can carry several accounts, and Mini signs in with the right one when the journey needs it. A chat between a buyer and a seller, for example, gets both accounts, and each one runs on its own device: see [Devices](https://www.minitap.ai/docs/minitest/suite/anatomy.md#devices) for multi-device scenarios.

You can also create and attach accounts from your editor or CI with the [CLI](https://www.minitap.ai/docs/minitest/reference/cli-commands.md#test-profile):

```bash theme={"theme":{"light":"github-light","dark":"vesper"}}
minitest --json --app <app_id> test-profile create \
  --name "Pro user" --username "pro@qa.minitap.ai" \
  --about "Pro subscription active, has saved items"

minitest --json --app <app_id> scenario-binding set-profile <scenario_id> --profile <profile_id>
```

Before you delete a test account, bind the scenarios that use it to another one. The dashboard lists them and blocks the delete until then.

## My app has no sign-in

Pick **My app has no sign-in** when Mini asks for accounts during onboarding. Scenarios then run with no test account, and Mini opens the app as a visitor. In an app that does have accounts, a scenario you create without one, like a public landing page, runs the same way.

If a journey without a test account still hits a sign-in wall, Mini creates a throwaway `@qa.minitap.ai` identity during the run, signs up and reads the confirmation code from its inbox.

## Passwords and secrets

Passwords, static codes and test cards are stored encrypted. Once saved, the dashboard shows the field as unchanged until you type a new value or clear it.

For values Mini should type but never see, use **Builds & test data → Secrets**. A test account's **Password**, **OTP** or **Test card** can then point to a secret that holds the value. In a scenario's description or criteria, refer to a secret as `{{secret:NAME}}`: Mini sees only the name, the device gets the value, and values typed on screen are blacked out in the screenshots Mini reads.

## Google sign-in

You don't need your own Google account for this. Minitap maintains Google accounts for you, and they appear under **Shared by Minitap** in **Builds & test data → Test accounts** and in every scenario's account picker. Attach one to the scenario and Mini signs in with it on every run.

## Email codes

When your app sends a code or a magic link by email, give the test account an `@qa.minitap.ai` address and no password. Mini reads the email from that inbox during the run, so there is nothing to forward or paste. See [Test inboxes](https://www.minitap.ai/docs/minitest/setup/test-inboxes.md) for how these inboxes work.

## Phone number sign-in

If your app signs users in by phone number, Mini needs a number it can type and a code it can type next. You put both on the test account, and you make them work in your own staging backend.

**1. Pick a test number**

Any number you control the behavior of in staging. It never receives a real SMS, so it doesn't have to be a number you own with a carrier.

**2. Whitelist it in your staging backend**

Make your OTP endpoint accept that number without sending anything, and accept one fixed code for it. Most teams already have this for their own manual QA.

**3. Put both on the test account**

In **Builds & test data → Test accounts**, open the account, turn on **Phone login** and fill **Phone number** in international format, with the country code (`+33612345678`), and **Static OTP code**, the code your backend returns for this number.

At runtime Mini types the number on the sign-in screen, waits for the code screen and types the code. Without the static code, Mini stops at the SMS screen.

### The generic case

The change has the same shape whatever your stack: when the request is for a whitelisted test number, skip the send and accept a known code.

```text theme={"theme":{"light":"github-light","dark":"vesper"}}
1. Add +33612345678 to a TEST_PHONE_NUMBERS list, read from config, staging only.
2. In "request OTP": if the number is in that list, return success without
   calling your SMS provider.
3. In "verify OTP": if the number is in that list, accept 123456 and nothing
   else. Don't fall back to your normal code check.
4. Keep the list empty in production.
```

Two things are worth getting right:

* **Staging only.** Gate the list behind an environment setting so a whitelisted number can never be used against production data.
* **One code per number.** Accept exactly one code for a test number. If verification accepts anything, your sign-in scenario stops testing sign-in.

### If you're on Twilio Verify

Twilio ships no test mode for [Verify](https://www.twilio.com/docs/verify/api). Its [test credentials](https://www.twilio.com/docs/iam/test-credentials) cover phone numbers, calls and messages, and a Verify request made with them comes back `403`. The magic numbers you may have seen (`+15005550006` and friends) are fixtures for the Messages API.

So the allowlist above is still the answer, one step earlier: short-circuit **before** you call Verify, in both your request handler and your check handler. Your production path stays exactly as it is.

### If you can't configure it

Tell us. If your app can't whitelist a test number, [book a call](https://cal.com/team/minitap/minitap-get-access?overlayCalendar=true) and we'll look at it with your case in hand.

## Next steps

> [card] [What a scenario is](https://www.minitap.ai/docs/minitest/suite/anatomy.md)
>
> Criteria, tags, dependencies, files and accounts on one scenario.

> [card] [Test inboxes](https://www.minitap.ai/docs/minitest/setup/test-inboxes.md)
>
> How Mini reads email codes and magic links.

> [card] [What Mini can do](https://www.minitap.ai/docs/minitest/reference/capabilities.md)
>
> Every sign-in flow and device capability, per platform.

> [card] [Read a run report](https://www.minitap.ai/docs/minitest/runs/run-report.md)
>
> See what Mini did on each screen, sign-in included.


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