Temporary Email for QA Testing: How to Automate Sign-Up Flows

In QA, a temporary email lets you test sign-ups, verification codes, and password resets with real addresses that actually receive mail, without creating an email account for every test case. With Mawlio, you can create the address, trigger the flow, and read the message from the same script by calling the app's endpoints with your account's session cookie. It's not a public API with keys: it works with your signed-in session, just like the web app.

Why use a temporary email for QA testing?

A temporary email gives you a fresh, isolated address for each test, delivered to an inbox you can read from code. That avoids three common problems: reusing the same test account until the system rejects it as a duplicate, mixing emails from different runs in a single inbox, and relying on team members' personal accounts.

The test also runs end to end: your application sends a real email over the internet, and you verify that it arrived with the right subject and content. If you only need to check the HTML without actually sending anything, a tool that captures email locally, like Mailpit, may be enough. For the bigger picture, what a temporary email is explains how it works behind the scenes.

Which flows can you test?

You can test any flow in your application that depends on an email arriving:

• Sign-up with email confirmation, by code or by link.
• One-time login codes.
• Password resets.
• Transactional emails, such as order confirmations or email-change notices.

Only use it on applications you own or have permission to test, like your staging environment. Automating mass sign-ups on third-party services usually violates their terms of use, and it's not a use we support.

How do your scripts authenticate their requests?

Your scripts authenticate with your Mawlio account's session cookie, called mw_session. Without it, the endpoints return 401 with the message "Inicia sesión" ("Sign in").

To get it, sign in to mawlio.com in your browser, open the developer tools, and look for the mw_session value in the site's cookie storage. Because it's a protected (HttpOnly) cookie, it doesn't show up in document.cookie; you have to copy it from that panel.

Treat it like a password: anyone who has it can create addresses and spend your account's credits. Store it as a secret in your continuous integration (CI) system and never commit it to the repository. In the examples we use an environment variable:

export MAWLIO_COOKIE="mw_session=YOUR_COOKIE"

With curl, you pass it with -b (or its long form, --cookie).

What's the basic flow with the endpoints?

The flow has five steps, all using the same cookie:

1. Create the address with POST /api/my/create, specifying a label, the address type and, optionally, the part before the @ and the duration.
2. Use the returned address in the form you're testing.
3. Poll GET /api/my/mail until the message shows up.
4. Read its content with GET /api/my/mail/body, extract the code or link, and continue the test.
5. When you're done, release the address with POST /api/my/delete.

Here's how to create an @mawlio.com address:

curl -s -X POST https://mawlio.com/api/my/create \
  -b "$MAWLIO_COOKIE" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "QA tests",
    "provider": "mawlio",
    "localPart": "qa.build114",
    "duration": "1d"
  }'

The response is JSON with the address in the hme field and the expiration date in expiresAt (milliseconds since 1970). If you omit localPart, the part before the @ is generated at random. If you choose one, it must be 1 to 30 characters long and use only letters, numbers, periods, hyphens, and underscores; some names are reserved (admin, soporte, info, and others) and return 403.

How do you read the code or link from the email?

You read the email in two steps: first you list the messages and filter by recipient, then you request the body of the one you want. The inbox only includes emails that arrived after the address was created, so you won't see leftovers from previous test runs.

ADDR="qa.build114@mawlio.com"

curl -s -b "$MAWLIO_COOKIE" "https://mawlio.com/api/my/mail?limit=50" \
  | jq -c --arg a "$ADDR" '.messages[] | select(.recipients | index($a)) | {uid, mailbox, subject}'

With that message's uid and mailbox, you request its content and extract, for example, a six-digit code:

curl -s -b "$MAWLIO_COOKIE" \
  "https://mawlio.com/api/my/mail/body?mailbox=INBOX&uid=123" \
  | jq -r '.text' | grep -oE '[0-9]{6}' | head -n 1

The body includes text, html, subject, from, and the list of attachments. Adjust the regular expression to match your code's format, or look for the confirmation URL in html.

To wait for the email, poll every few seconds with a timeout. The endpoints are rate limited: if you send too many requests in a row, they return 429 and make you wait a few seconds, so a 3- to 5-second interval is reasonable.

How do you extend an address, and which duration should you pick?

You extend an address with POST /api/my/extend, sending the address and the new duration. The new expiration is counted from the moment you extend; it isn't added to the time that was left.

curl -s -X POST https://mawlio.com/api/my/extend \
  -b "$MAWLIO_COOKIE" \
  -H "Content-Type: application/json" \
  -d '{"hme": "qa.build114@mawlio.com", "duration": "1d"}'

The response returns the new expiresAt. These are the available durations, valid both for extend and for the duration field in create:

When creating an address, if you omit duration or send 1h, Mawlio uses your free 1-hour address if you have one available. Each account can hold 2 free 1-hour addresses at a time (one @mawlio.com and one of a second address type); beyond that allowance, an extra 1-hour address costs 1 credit for @mawlio.com and 1.5 for iCloud; if you request it with a longer duration, the difference from the table is added. You get 5 credits when you sign up, and you can top up by card or crypto from US$2 (10 credits). If you don't have enough credits, the response is 402.

How do you keep tests isolated and traceable?

Each account only sees its own addresses, and each address only shows emails that arrived after you got it. Within your account, GET /api/my/mail returns messages for all your active addresses, so you should always filter by the recipients field.

A few practices that help:

• Predictable names. Use the build or test case number in localPart, for example qa.build114, so you know which run received each email. If another account is already using that name, you'll get 409 and need to pick a different one.
• Clear labels. The label field shows up in your web inbox and helps you manually review what the script did.
• Clean up at the end. Release the addresses with POST /api/my/delete and {"hme": "..."} when the suite finishes.

Keep in mind that once an address is released or expires, it may later be assigned to someone else. The new owner starts with an empty inbox, but they would receive anything your application sends to that address afterward. So don't leave long-lived test accounts in staging tied to addresses you've already released, especially if your application sends sensitive data.

Frequently asked questions

Does Mawlio have a public API with keys?

No. The endpoints are the same ones the web app uses, and they work with the session cookie of a signed-in account. There are no API keys: everything depends on your session.

Can I use Mawlio in my CI pipeline?

Yes, by storing the mw_session cookie as a pipeline secret and passing it with every request. Respect the rate limit by polling the inbox every few seconds, and keep in mind that every address beyond your free allowance uses credits.

Can I receive SMS codes in my tests?

No. Mawlio only receives email and doesn't offer phone numbers. For SMS flows you need a different tool; in temporary phone numbers for receiving SMS we explain their limitations.

Does it work for manual testing too?

Yes. You can do the same thing from the app: create the address, copy the highlighted code with one tap, and reply from the temporary address. The step-by-step guide is in how to receive verification codes without giving out your personal email.

To start testing your email flows, create your free account on Mawlio.