Email Verification Code API for OTP Extraction from Inbound Email

Email verification looks simple from a user perspective: submit an email, receive a code, enter the code, continue.

From an engineering perspective, it is one of the most common sources of flaky automation.
Templates evolve, multiple numbers can appear in the same message, and parser logic scattered across test suites becomes difficult to trust over time.

This is exactly where MailSlurp helps. MailSlurp gives you programmable inboxes plus API endpoints for message retrieval and parsing.
For verification code extraction from inbound email, use:

POST /emails/{emailId}/codes

This endpoint gives you a structured and repeatable extraction result you can use in CI, integration tests, and message-driven automation flows.

What MailSlurp Is in This Workflow

At a high level, MailSlurp is the inbox layer of your test or automation stack:

• create inboxes
• receive inbound messages
• fetch message content
• extract values (like OTP codes)

Instead of writing and maintaining parser code in every test project, you can centralize code extraction with the MailSlurp API.

API Base URL and Authentication

MailSlurp API base URL:

https://api.mailslurp.com

Authentication header:

x-api-key: YOUR_API_KEY

Suggested shell setup:

export API_KEY="your-mailslurp-api-key"

Where This Endpoint Fits in a Real Flow

A typical auth automation flow:

1. Trigger signup, login challenge, or password reset in your app.
2. Wait for inbound email in a MailSlurp inbox.
3. Get the emailId for that message.
4. Call /emails/{emailId}/codes.
5. Submit the returned code to your verify step.

This pattern is useful in:

• end-to-end test pipelines
• smoke tests for critical auth paths
• staging environment validation
• internal QA tooling

Endpoint

POST /emails/{emailId}/codes

Request Body

{
  "method": "AUTO",
  "allowFallback": true,
  "minLength": 6,
  "maxLength": 6,
  "maxCandidates": 5,
  "customPatterns": ["verification code[: ]+(\\d{6})"]
}

Parameter Guidance

• method: extraction strategy. AUTO is a strong default for most teams.
• allowFallback: when true, unavailable method paths can degrade gracefully.
• minLength and maxLength: the most effective way to reduce false positives.
• maxCandidates: keeps output manageable for deterministic assertions.
• customPatterns: useful when your template phrasing is stable and known.

cURL Example

curl -sS -X POST "https://api.mailslurp.com/emails/$EMAIL_ID/codes" \
  -H "x-api-key: $API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "method": "AUTO",
    "allowFallback": true,
    "minLength": 6,
    "maxLength": 6
  }'

JavaScript Example

const response = await fetch(`https://api.mailslurp.com/emails/${emailId}/codes`, {
  method: "POST",
  headers: {
    "x-api-key": process.env.MAILSLURP_API_KEY,
    "content-type": "application/json",
  },
  body: JSON.stringify({
    method: "AUTO",
    allowFallback: true,
    minLength: 6,
    maxLength: 6,
  }),
});

const result = await response.json();

if (!result.found) {
  throw new Error(`No verification code found. Warnings: ${(result.warnings || []).join("; ")}`);
}

console.log("verification code:", result.code);

Example Response

{
  "found": true,
  "code": "734921",
  "methodUsed": "PATTERN",
  "candidates": [
    {
      "code": "734921",
      "confidence": 0.95,
      "method": "PATTERN",
      "source": "RAW_TEXT_PART",
      "context": "Your verification code is 734921."
    }
  ],
  "warnings": []
}

Why the Structured Response Matters

The single most useful improvement over hand-written parser logic is observability.

You get:

• found for clean assertions
• code for immediate use
• ranked candidates for debugging ambiguous messages
• warnings for visibility into fallback or extraction quality

That makes failures easier to diagnose and reduces time spent reproducing parser bugs.

Reliability Patterns for CI

Use two extraction profiles in your test suite:

1. Resilient mode with allowFallback=true for broad regression stability.
2. Strict mode with allowFallback=false for targeted parser contract checks.

This prevents brittle failures from blocking all pipelines while still surfacing real extraction regressions.

Common Failure Cases and Mitigations

• Wrong numeric token selected: set exact length constraints and add a template-specific pattern.
• Template wording changed: update customPatterns and monitor warnings for drift signals.
• Intermittent failures in CI: persist methodUsed, source, and warnings in test artifacts.

Business Value for Teams

Teams that centralize verification-code extraction with MailSlurp usually get:

• less duplicated parser code across repos
• fewer flaky auth tests
• faster diagnosis when message templates change
• cleaner QA ownership boundaries

If your product relies on email verification, this endpoint is one of the highest-leverage API calls you can add to your automation stack.