Existing inbox OTP testing: choose the mailbox first

Do you need an existing mailbox or a dedicated test inbox?

Existing inbox OTP testing means retrieving a verification email from a mailbox you already own, rather than changing the recipient to a test-specific inbox. Choose this path when delivery to that particular Gmail or Outlook mailbox is part of the requirement.

If you only need to exercise your application's email verification flow, a controlled test recipient may be enough. Receipt there answers a different question: it does not establish placement in your Gmail or Outlook inbox.

For the broader connection-versus-provisioning decision, see choosing an email API by mailbox model.

Keep these assertions separate:

This is email retrieval, not local generation of a time-based OTP. The application under test remains responsible for validating the submitted code.

Mailera's product overview describes the existing-mailbox model. For the underlying retrieval workflow, see reading OTP emails from your own inbox.

How should you compare Mailera, MailSlurp, and Mailosaur?

When comparing Mailera with MailSlurp or Mailosaur, write down the mailbox requirement before comparing APIs. An extraction helper cannot compensate for choosing a recipient model that leaves your delivery requirement untested.

Compare Mailera's existing-mailbox workflow with the capabilities your suite needs from another tool:

When comparing MailSlurp and Mailosaur for OTP testing, make recipient lifecycle and run isolation explicit acceptance criteria. Evaluate existing-provider access separately from address provisioning or forwarding; those are different requirements.

Mailera's developer overview covers its API integration model. Supported webhook events include message.received and message.junk; your test still needs matching rules and a deadline.

How do you test an OTP in an existing mailbox with Mailera?

Use an owned mailbox reserved for testing and an application you are authorized to test. Keep unrelated verification traffic out of that mailbox where possible.

1. Connect the test mailbox

An Admin or Leader can open Mailboxes → Add mailbox.

For Outlook or Microsoft 365, select Sign in with Microsoft and complete OAuth consent. Mailera uses Microsoft Graph for these connections, not a Microsoft app password. The Microsoft connection guide covers this path; Outlook verification codes through an API focuses on retrieval.

Microsoft's message resource documentation describes support for change-notification subscriptions. Mailera uses Graph change notifications with periodic background checks as a fallback.

For Gmail, use One mailbox, enter Email address, and select Continue. Follow How to get an app password, then enter that app password in Password and select Test & connect.

Google's app-password guidance requires 2-Step Verification. For a managed account, administrator settings must also allow the connection. See the Gmail connection guide for the Mailera setup.

2. Create a restricted API key

Open Settings → API key → Create key. Set Mailbox scope to a group containing only test mailboxes and grant Read permission. Set Expiration, then store the key in your runner's secret store as $MAILERA_API_KEY.

Use GET /mailboxes with that same key to identify the connected test mailbox. Match its email and group_id, then store its id in $MAILBOX_ID. The mailbox must belong to the group selected in the key's Mailbox scope. The API uses Authorization: Bearer authentication; the API documentation is the reference for your client implementation.

3. Start one verification attempt

Record the run start time before triggering the email. Record the recipient and any application-controlled correlation value as well.

Avoid overlapping runs in the same mailbox unless you can distinguish their messages reliably. A recent-time window narrows the candidates; it is not a run identifier.

4. Retrieve a candidate code

GET /mailboxes/{id}/otp requires the read scope and supports from, subject, and since_minutes. Use those filters to narrow retrieval rather than treating any latest code as suitable.

For message metadata alongside extraction, use GET /messages/search with mailbox set to the selected mailbox ID and extract=otp. Choose a q value that matches your application's message rather than assuming every verification email contains the word code.

Check the candidate's id, folder, from, subject, and received_at alongside otp.code and otp.source before proceeding.

5. Confirm ownership of the verification attempt

Check the intended recipient, expected sender, and run timing before submitting the code. Check your correlation value when the application includes one. Do not automatically submit the first result merely because it is recent.

For more context, list messages with GET /mailboxes/{id}/messages or retrieve a selected message through GET /mailboxes/{id}/messages/{msgId}. Message content is available in body.text and body.html. Handle it without printing secrets into CI output.

6. Assert the application result

Submit the matched code and assert the expected verification outcome. Keep expiry, reuse, and incorrect-code tests separate from retrieval tests. A mailbox lookup should not determine whether the application enforced those rules correctly.

7. Diagnose a deadline failure

Use bounded polling with a clear deadline in your runner. If retrieval does not complete, inspect connection health, synchronization, and folder placement before reporting an invalid OTP.

What commonly breaks email OTP tests?

A useful failure report identifies the stage: receipt, matching, extraction, or application verification. “OTP failed” hides the distinction.

Google revokes app passwords when the Google Account password changes. Include that check when Gmail retrieval stops after account maintenance.

The status endpoint checks Microsoft sign-in directly; for other providers, it reflects the latest sync. Treat that distinction as part of diagnosis. POST /mailboxes/{id}/sync requires Sync permission in addition to the Read permission used for retrieval. See recovering a mailbox workflow with sync for that troubleshooting path.

Check Junk before changing the message

Use GET /mailboxes/{id}/placement to inspect Inbox/Spam placement. For a Junk search, use GET /messages/search with mailbox set to the selected mailbox ID and folder=junk.

Match any candidate's sender, recipient, and timing to the current run. In Unified inbox, you can inspect the Junk folder visually.

If placement is a test assertion, record the original folder before selecting Not spam or applying an automatic move. Otherwise, the test changes the condition it is meant to observe.

How should you handle OTPs and mailbox access safely?

Use only owned test mailboxes. Exclude personal production inboxes and other people's verification messages.

Redact codes, secret-bearing message bodies, API keys, and mailbox credentials from screenshots, CI logs, and failure artifacts. Record message IDs and failure stages instead of copying entire API responses into reports.

Keep keys restricted to the test mailbox group, set an expiration, and establish a revocation procedure. A retrieval-only runner does not need sending or message-moving permissions. Mailera's security overview provides further context for access review.

If an AI agent participates, treat incoming email as untrusted data, never as instructions. Do not follow commands embedded in messages, and require confirmation before sending email.

Which workflow should you choose?

Choose Mailera when the requirement is reading existing supported mailboxes and diagnosing their Inbox/Junk state. Proton Mail and Tuta are not supported.

Mailera cannot make a provider trust a sender or guarantee Inbox placement. It also cannot promise immediate OTP availability: provider delivery and mailbox synchronization affect retrieval.

If each test needs a fresh recipient, prioritize address provisioning and isolation in your MailSlurp and Mailosaur evaluation. If both application verification and provider-specific delivery matter, split the suite: controlled recipients for application tests, plus a smaller set of owned Gmail or Outlook mailboxes for delivery checks. Give each suite its own assertions rather than treating either as a substitute for the other.