Receive Email API for deterministic testing and retrieval

A receive email API gives developers and QA teams a reliable way to fetch, search, and assert on incoming messages. Instead of opening inboxes manually, your tests and services can validate outcomes automatically.

Use this page if you are evaluating receive email api tooling for CI, OTP flows, or production diagnostics.

Quick answer

A practical receive API should let you:

• fetch new messages by inbox and time window
• wait for matching messages with strict criteria
• extract links, OTP codes, headers, and attachments
• handle concurrency across parallel test runs
• inspect routing and auth headers when failures occur

Receive email API vs inbound email API

Use a receive email API when your application or test runner needs to pull, wait for, search, and assert messages. Use an inbound email API when new messages should push events into your systems through webhooks, routing rules, or parsing pipelines.

Intent	Start here
"did the expected message arrive?"	Receive email API
"wait for an OTP or magic link in CI"	Email integration testing plus Receive email API
"turn incoming email into a support, finance, or order workflow"	Inbound email API
"send incoming email to my server in real time"	Email webhooks
"create the mailbox first"	Email address API

High-value receive email API scenarios

QA for account flows

• signup confirmation links
• password reset tokens
• device verification and MFA fallbacks

Transactional workflow checks

• invoices and receipts
• delivery updates and alerts
• support acknowledgement messages

Production monitoring

• synthetic inbox probes for key message types
• drift detection for template and routing changes
• incident debugging with raw header inspection

Receive workflow pattern

1. Create a fresh inbox for the test or monitor run.
2. Trigger your application event.
3. Wait for matching inbound email.
4. Extract fields and assert expected values.
5. Export evidence for failures and triage.

Wait for email in code:

const matchingEmails = await mailslurp.waitForMatchingEmails(
  {
    // match for emails with no attachments
    conditions: [
      {
        condition: ConditionOptionConditionEnum.HAS_ATTACHMENTS,
        value: ConditionOptionValueEnum.FALSE,
      },
    ],
    // match for emails from a specific email address
    matches: [
      {
        field: MatchOptionFieldEnum.FROM,
        should: MatchOptionShouldEnum.CONTAIN,
        value: inbox.emailAddress,
      },
    ],
  },
  1,
  inbox.id,
  timeout,
  unreadOnly,
);

Receive API best practices

• isolate inboxes per test to avoid cross-run interference
• use explicit timeouts and criteria for deterministic results
• validate sender and subject before parsing body content
• capture raw headers for debugging auth and routing issues
• pair receive assertions with DNS/auth checks in release gates

Helpful tools:

• Email header analyzer
• DNS lookup
• SPF checker
• DKIM checker
• DMARC checker

How this page differs from inbound email API

• Inbound email API is architecture-first (webhooks, routing, event pipelines).
• Receive email API is assertion-first (retrieval, matching, deterministic validation).

Many teams use both: receive APIs for tests and monitoring, inbound APIs for automation and operations.

FAQ

Can I use this for OTP and magic-link tests?

Yes. This is one of the most common receive-email API use cases in CI and staging.

Does it work with custom domains?

Yes. You can receive on generated addresses and custom-domain addresses depending on your setup.

What is the next step after this page?

Go to Email API for full send/receive architecture, or Email deliverability test for release-gate checklists.