DEV Community: Dishant Singh

The Best Temp Mail API in 2026: A Practical Guide for Developers

Dishant Singh — Mon, 06 Apr 2026 17:49:50 +0000

Email verification is deceptively simple on paper. Your app sends a code, the user enters it, done. In practice, automating that handshake is one of the most friction-heavy parts of any test pipeline, AI agent workflow, or CI/CD system.

The disposable email API market has grown significantly in 2026 — but the gap between services has also widened. Several platforms have added real developer tooling while others remain stuck at basic polling APIs from five years ago. This guide is based on hands-on evaluation of every major option with attention to the features that actually matter in modern automation: MCP server support, webhooks, long-polling Wait APIs, OTP extraction, SDK quality, and pricing at real scale.

What "Temp Mail API" Actually Means in 2026

Five years ago, a temp mail API meant: create an inbox, poll for messages, parse the body yourself. That was the entire contract.

In 2026, the expectation has evolved significantly:

AI agents need native tool interfaces. Model Context Protocol (MCP) is now supported by every major AI provider — Anthropic, OpenAI, Google, Microsoft. Agents that can use tools are everywhere, and email verification is almost always one of the first bottlenecks they hit. A temp mail API that lacks MCP support requires custom glue code for every agent framework.

Test suites expect zero-polling delivery. Long-polling "Wait API" and WebSocket streaming deliver emails the moment they arrive. A Playwright test that has to poll GET /messages in a loop with a sleep is both slower and more flaky than one that blocks on a single HTTP request.

OTP extraction should be automatic. Writing regex to parse verification codes from email bodies is maintenance debt. Services that extract OTPs on the server side and return the value directly eliminate an entire category of technical debt.

Webhooks enable event-driven architectures. For backend services, n8n workflows, and persistent integrations, server-push is the correct delivery model. Polling is not.

With those requirements in mind, here is how the major options compare.

FreeCustom.Email: The Complete Developer Platform

Of all the disposable email APIs evaluated, FreeCustom.Email is the only one that ships all four delivery methods — polling, long-poll Wait API, WebSocket, and webhooks — in a single platform. It is also the only service in this category with an official CLI, official language SDKs, and an MCP server for AI agents.

The MCP Server: One Tool Call for the Full Signup Flow

The MCP server is the most significant differentiator. A single call to create_and_wait_for_otp provisions a fresh inbox, holds an HTTP connection open until an OTP arrives, and returns it — no polling loop, no custom code, no regex.

Configure it in Claude Desktop or Cursor:

{
  "mcpServers": {
    "fce-mcp": {
      "command": "npx",
      "args": ["-y", "fce-mcp-server"],
      "env": { "FCE_API_KEY": "fce_your_growth_key" }
    }
  }
}

Once configured, you can tell Claude: "I'm testing our signup flow. Use create_and_wait_for_otp to generate a test inbox — I'll trigger the verification on my end." Claude handles the inbox creation, the waiting, and the extraction.

The three available MCP tools:

Tool	Plan	Description
`get_latest_email`	Growth+	Fetch the most recent message with OTP extracted
`extract_otp`	Growth+	Return only the OTP or verification link
`create_and_wait_for_otp`	Growth+	Create inbox + block until OTP arrives — the gold call

The Wait API: Long-Polling for Scripts and Tests

For Playwright tests and CI scripts, the Wait API is the cleanest approach. One HTTP request blocks until an email arrives (or until timeout):

curl "https://api2.freecustom.email/v1/inboxes/test@ditapi.info/wait?timeout=30" \
  -H "Authorization: Bearer fce_your_key"
# Returns when email arrives — no loop, no sleep()

In a Playwright test, this means the OTP wait is a single await fetch() call that resolves the moment the email lands. No polling. No flakiness from sleep intervals that are either too short (race condition) or too long (slow tests).

Webhooks: Server-Push for Persistent Backends

For backend services, n8n workflows, and event-driven architectures, webhooks are the right model. Register a URL and FCE sends an HTTP POST the instant an email arrives:

curl -X POST https://api2.freecustom.email/v1/webhooks \
  -H "Authorization: Bearer fce_your_key" \
  -d '{"url":"https://your-app.com/hook","inbox":"test@ditapi.info"}'

The payload includes the fully extracted OTP and verification link — no parsing required on your end. A HMAC-SHA256 signature on every request (X-FCE-Signature) lets you verify authenticity.

The CLI: The Only One in the Industry

The fce CLI is a Go binary for macOS, Linux, and Windows — and it is the only official CLI tool for any disposable email service. Install it:

curl -fsSL freecustom.email/install.sh | sh
fce login
# Browser opens → authenticates → API key saved to OS keychain

For local development, fce dev is a single command that creates an inbox and starts watching it in real time. Emails appear in the terminal the moment they arrive. fce otp <address> extracts and displays the OTP without any parsing:

  OTP   ·  212342
  From  ·  noreply@myapp.com
  Subj  ·  Your verification code
  Time  ·  20:19:54

Pricing

Plan	Price	Req/month	OTP extract	Wait API	Webhooks	MCP
Free	$0	5,000	Detected	✗	✗	✗
Developer	$7/mo	100,000	✓	✓	✗	✗
Startup	$19/mo	500,000	✓	✓	✗	✗
Growth	$49/mo	2,000,000	✓	✓	✓	✓
Enterprise	$149/mo	10,000,000	✓	✓	✓	✓

Credits (never expire) are also available à la carte for burst usage.

Mailinator: The Enterprise QA Platform

Mailinator has been around since 2003 and occupies a specific niche: enterprise QA testing with SMS, Selenium/Playwright/Cypress integration, and webhook routing rules. It is a professional platform designed for developer teams at larger organizations.

The practical limitations for most developers in 2026:

Meaningful API access starts at around $99/month
No OTP extraction endpoint — regex on your end
No CLI
No MCP server
No long-poll Wait API — polling only
Public inboxes are readable by anyone (intentional for testing, not suitable for sensitive data)

Who should use it: Teams at organizations that already have a Mailinator contract, or enterprises that specifically need SMS testing alongside email testing and have the budget for it.

Who should not: Individual developers, small teams, or anyone building AI agent workflows.

MailSlurp: Best for Email Send + Receive Testing

MailSlurp solves a different problem than FreeCustom.Email. Its core strength is testing the full email lifecycle — including outbound sending — for teams that need to verify deliverability, inspect headers, and test SMTP configuration alongside inbound verification.

It has solid REST and SDK support, webhooks, and wait methods. The gaps for disposable email specifically are that there is no OTP extraction endpoint (parsing is manual), no CLI, no MCP server, and the free tier has tight restrictions. For teams whose primary concern is inbound OTP verification and AI agent integration, MailSlurp requires more custom infrastructure.

Best fit: Backend teams testing transactional email delivery end-to-end.

mail.tm: The Free Minimalist Option

mail.tm offers a REST API with no API key required — create an account, get a JWT, fetch messages. That is the complete feature set.

No OTP extraction, no WebSocket, no webhooks, no long-polling, no CLI, no SDK. JWT management means each inbox requires credential handling. For zero-cost throwaway scripts where the simplicity tradeoff is acceptable, it works. For any workflow requiring reliability, OTP automation, or scale, it is the wrong tool.

The Parallel Test Problem

One practical issue worth addressing directly: parallel CI test jobs sharing an inbox.

When five Playwright workers all submit signups and receive OTPs from the same inbox, each worker risks reading another's code. The only reliable solution is fresh isolated inboxes per test run — which requires programmatic inbox creation.

FreeCustom.Email supports this natively at any scale. The Growth plan allows 50 req/sec, which means 50 inbox creations per second. Parallel Playwright workers, each with their own address, have zero interference:

// playwright.config.ts
export default defineConfig({
  workers: 10,
  // Each worker fixture creates its own inbox — no shared state
});

For the complete fixture pattern, see the Playwright integration guide.

LangChain Integration Example

For AI agent use cases beyond Claude Desktop, the FCE MCP endpoint is directly callable from any framework that supports function calling:

from langchain.tools import tool
import requests, os

@tool
def create_inbox_and_wait_for_otp(timeout: int = 45) -> dict:
    """Creates a temporary inbox and waits for a one-time password."""
    r = requests.post(
        "https://mcp.freecustom.email/mcp",
        headers={"Authorization": f"Bearer {os.environ['FCE_API_KEY']}"},
        json={"timeout": timeout},
        timeout=timeout + 5,
    )
    return r.json()

This works in LangChain, LangGraph, and any OpenAI function-calling setup without needing the MCP protocol at all.

Summary

The disposable email API market in 2026 ranges from session-based free tools to enterprise QA platforms. For developers building AI agents, test suites, CI pipelines, and event-driven backends, the evaluation comes down to:

OTP extraction (server-side vs. manual regex)
Delivery method (polling vs. long-poll vs. WebSocket vs. webhooks)
AI agent tooling (MCP server support)
CLI (for terminal and CI workflows)
Pricing (at the scale your test suite actually runs)

FreeCustom.Email is the only platform that covers all five. For AI agent integration specifically, its MCP server — which provides create_and_wait_for_otp as a single tool call — is the most significant technical advancement in this space in 2026.

Further reading:

I Switched From mail.tm to This — Here's What I Got

Dishant Singh — Sun, 29 Mar 2026 04:42:15 +0000

I used mail.tm for about a year for disposable inbox needs in my test pipelines. Clean REST API, decent uptime, simple enough to integrate. I did not think too hard about switching.

Then I started hitting its limits in quick succession: no OTP extraction (write your own regex), no WebSocket delivery (poll and wait), no CLI (write your own wrapper), no official SDK (use a random community package that was last updated 18 months ago).

Every project that grew beyond basic message fetching required me to build and maintain tooling that should have been provided by the service. Eventually I switched to FreeCustom.Email and those problems went away. This post explains exactly what changed.

The Gap That Kept Growing

The longer I used mail.tm, the more I noticed what was missing — not bugs, but capabilities that simply did not exist:

What I wanted	mail.tm	FreeCustom.Email
`otp extract` command	✗ write your own regex	✓ built in
Real-time WebSocket delivery	✗ polling only	✓ < 200ms
Official CLI	✗	✓ `fce` — open source, MIT
Official TypeScript SDK	✗	✓
Official Python SDK	✗	✓
CI/CD first-class support	✗ manual	✓ native
AI agent integration	✗	✓
n8n integration	✗	✓

mail.tm is not broken — it is just a REST API that stopped evolving. In 2026, if you are doing anything beyond basic email retrieval, you will spend more time building workarounds than writing your actual application.

The CLI Is the Biggest Difference

FreeCustom.Email ships fce — the only official CLI for any disposable email service in the world. That is not marketing — I checked. No other provider has one.

Install it:

# macOS / Linux
curl -fsSL freecustom.email/install.sh | sh

# Homebrew
brew tap DishIs/homebrew-tap && brew install fce

# Windows (Scoop)
scoop bucket add fce https://github.com/DishIs/scoop-bucket && scoop install fce

# Windows (Chocolatey)
choco install fce

# npm (all platforms)
npm install -g fcemail@latest

# Go (all platforms)
go install github.com/DishIs/fce-cli@latest

Source and all releases: github.com/DishIs/fce-cli/releases

fce login
# No manual token copying. Key auto-updates with your plan.

Then:

fce dev

  ·  Temporary inbox: dev-fy8x@ditcloud.info
  ✓  Watching for emails...
  ·  Waiting for emails… (press Ctrl+C to stop)

────────────────────────────────────────────────────
  ID    JpW3DImT3
  FROM  noreply@myapp.com
  SUBJ  Your verification code
  TIME  20:19:54
────────────────────────────────────────────────────

Inbox created. WebSocket open. Emails appearing in real time. One command.

With mail.tm, the equivalent required: create an account, get a JWT, store it, poll GET /messages, parse the email body, extract the OTP with regex. That is a script, not a command.

OTP Extraction: mail.tm vs fce

This was my biggest pain point with mail.tm.

With mail.tm, you fetch the full message body and parse it yourself:

// What I was doing with mail.tm
const messages = await fetch('https://api.mail.tm/messages', {
  headers: { Authorization: `Bearer ${jwt}` }
}).then(r => r.json());

const body = messages['hydra:member'][0]?.text ?? '';

// Six patterns because different services format OTPs differently
const otp = body.match(/\b(\d{6})\b/)
  ?? body.match(/code[:\s]+(\d{6})/i)
  ?? body.match(/OTP[:\s]+(\d{4,8})/i)
  ?? body.match(/verification[:\s]+(\d{4,8})/i)
  // ... and it still breaks when templates change
  ?.[1];

With FreeCustom.Email:

fce otp dev-fy8x@ditcloud.info

────────────────────────────────────────────────
  OTP
────────────────────────────────────────────────

  OTP   ·  212342
  From  ·  noreply@myapp.com
  Subj  ·  Your verification code
  Time  ·  20:19:54

Or in code:

const otp = await fce.otp.waitFor(inbox, { timeout: 30_000 });
// → "212342"

The OTP extraction engine handles numeric codes, alphanumeric tokens, magic links, HTML emails, and multi-part MIME — without regex that breaks when a template changes.

Migration from mail.tm

If you are already using mail.tm in a project, migration is maybe an hour of work.

Step 1: Get an FCE account and key

curl -fsSL freecustom.email/install.sh | sh
fce login
# Key saved automatically to keychain
# For CI: export FCE_API_KEY=... (get from dashboard)

Step 2: Replace account creation with inbox registration

Before:

// mail.tm — must create an account with a password, then get a JWT
const { id: accountId } = await fetch('https://api.mail.tm/accounts', {
  method: 'POST',
  body: JSON.stringify({ address: inbox, password: 'SomePass123' }),
}).then(r => r.json());

const { token: jwt } = await fetch('https://api.mail.tm/token', {
  method: 'POST',
  body: JSON.stringify({ address: inbox, password: 'SomePass123' }),
}).then(r => r.json());

After:

// FCE — one call, no password, no JWT management
const fce = new FreecustomEmailClient({ apiKey: process.env.FCE_API_KEY });
await fce.inboxes.register(inbox);

Step 3: Replace polling + regex with OTP extraction

Before:

// Poll and regex
let otp = null;
for (let i = 0; i < 30 && !otp; i++) {
  await sleep(2000);
  const { 'hydra:member': messages } = await fetch('https://api.mail.tm/messages', {
    headers: { Authorization: `Bearer ${jwt}` },
  }).then(r => r.json());
  if (messages.length > 0) {
    const match = messages[0].text.match(/\b(\d{6})\b/);
    otp = match?.[1];
  }
}

After:

const otp = await fce.otp.waitFor(inbox, { timeout: 30_000 });

Step 4: Replace account deletion with inbox removal

Before:

await fetch(`https://api.mail.tm/accounts/${accountId}`, {
  method: 'DELETE',
  headers: { Authorization: `Bearer ${jwt}` },
});

After:

await fce.inboxes.unregister(inbox);
// Or: fce inbox remove inbox@ditmail.info

Real-Time vs Polling

mail.tm has no WebSocket option. You poll GET /messages on a loop, which means:

Minimum 2–5 second delay per check
Wasted API quota on empty responses
CI pipelines that feel slow for no reason

FreeCustom.Email delivers emails via WebSocket on Startup plan+. They appear in your terminal (or SDK callback) in under 200ms:

fce watch test@ditmail.info

In CI tests, this is the difference between a 30-second polling loop and near-instant OTP receipt.

Authentication: JWT Hell vs Bearer Token

This is a minor thing but I noticed it every time. mail.tm requires you to POST credentials to get a JWT, then use that JWT for all subsequent requests. JWTs expire. You have to handle refresh. You are managing a password for a test inbox.

FreeCustom.Email uses a simple Bearer token (fce_your_key). Get it from the dashboard, set it once as FCE_API_KEY, done. Never expires unless you rotate it. No password to manage.

The Automation Ecosystem That mail.tm Has None Of

Beyond the core API, FreeCustom.Email is building something mail.tm has not touched: an automation ecosystem.

Today:

fce CLI — the only disposable email CLI
Official JS/TS and Python SDKs
n8n visual workflow integration
OpenClaw AI agent support

Coming Q2 2026:

Native Make (Integromat) modules
Native Zapier triggers and actions

Full details: freecustom.email/api/automation

Pricing

Plan	Price	WebSocket	OTP extraction
Free	$0	✗	✗
Developer	$7/mo	✗	✗
Startup	$19/mo	✓	✗
Growth	$49/mo	✓	✓
Enterprise	$149/mo	✓	✓

Full details: freecustom.email/api/pricing

Quick Decision Guide

Use case	Best option
Local dev: watch for emails	`fce dev`
Shell script / CI	`fce inbox add random` + `fce otp`
Playwright / Vitest	`freecustom-email` npm SDK
pytest / Selenium	`freecustom-email` pip SDK
AI agent automation	OpenClaw + `fce login`
Visual no-code workflow	n8n (now) / Make or Zapier (Q2 2026)

Links

🖥️ CLI docs: freecustom.email/api/cli
📦 GitHub: github.com/DishIs/fce-cli
🚀 Releases: github.com/DishIs/fce-cli/releases
🤖 Automation: freecustom.email/api/automation
📖 API docs: freecustom.email/api/docs
💬 Discord: discord.com/invite/Ztp7kT2QBz

If you are currently using mail.tm, Mailinator, or Guerrilla Mail in your projects, I am curious what is holding you back from switching to something with better tooling. Is it the migration effort, pricing, or something the other services do that FCE does not?

Stop Skipping Email Verification in Your Automated Tests

Dishant Singh — Sun, 29 Mar 2026 04:40:51 +0000

Every team I have talked to handles email verification the same way in their test suite: they skip it, mock it, or use a shared inbox that makes parallel tests unreliable. I did all three before I found an approach that actually works at scale.

The problem is that most disposable email services have no real developer tooling. You get a web UI and maybe a REST API that requires you to poll, parse, and regex your way to an OTP. Nothing is designed for automation.

FreeCustom.Email is different — it is the only disposable email service with an official CLI, official SDKs, a dedicated OTP extraction endpoint, and WebSocket real-time delivery. This post covers every way to use it for signup automation, from a three-line bash script to a full parallel Playwright test suite.

The Pattern

All signup automation comes down to three steps:

1. Create a fresh inbox        → get an address nobody else is using
2. Submit it in the signup UI  → your app sends the verification email
3. Extract the OTP             → complete verification

The only question is which tool you use for each step. I will cover all of them.

Option 1: The CLI (Fastest for Local Dev and Scripts)

Install:

curl -fsSL freecustom.email/install.sh | sh   # macOS / Linux
npm install -g fcemail@latest                  # All platforms
choco install fce                              # Windows
brew tap DishIs/homebrew-tap && brew install fce  # Homebrew

Full install options and all releases at github.com/DishIs/fce-cli. Login once:

fce login
# Browser → sign in → key saved to OS keychain automatically

Automate a signup in four lines:

INBOX=$(fce inbox add random)
curl -s -X POST https://myapp.com/signup -d "email=$INBOX&password=Test1234!"
OTP=$(fce otp "$INBOX" | grep "OTP   ·" | awk '{print $NF}')
curl -s -X POST https://myapp.com/verify -d "email=$INBOX&otp=$OTP"

The fce otp output:

────────────────────────────────────────────────
  OTP
────────────────────────────────────────────────

  OTP   ·  212342
  From  ·  noreply@myapp.com
  Subj  ·  Your verification code
  Time  ·  20:19:54

For local development, fce dev is even faster — it creates an inbox and starts watching it in one command:

fce dev
# → dev-fy8x@ditcloud.info created and watching
# → emails appear in real time as they arrive

Option 2: The TypeScript SDK

npm install freecustom-email

import { FreecustomEmailClient } from 'freecustom-email';

const fce = new FreecustomEmailClient({ apiKey: process.env.FCE_API_KEY! });

async function automateSignup() {
  const email = `auto-${Date.now()}@ditmail.info`;
  await fce.inboxes.register(email);

  // Trigger signup
  await fetch(`${process.env.APP_URL}/api/signup`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email, password: 'AutoTest123!' }),
  });

  // No polling loop. No regex. Just this:
  const otp = await fce.otp.waitFor(email, { timeout: 30_000 });
  console.log(`Got OTP: ${otp}`);

  // Complete verification
  await fetch(`${process.env.APP_URL}/api/verify`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email, otp }),
  });

  await fce.inboxes.unregister(email);
}

Running 10 signups in parallel is trivial because each has its own inbox:

await Promise.all(Array.from({ length: 10 }, () => automateSignup()));

Option 3: The Python SDK

pip install freecustom-email httpx

import asyncio, os, httpx
from freecustom_email import FreeCustomEmail

fce = FreeCustomEmail(api_key=os.environ["FCE_API_KEY"])
APP = os.environ["APP_URL"]

async def automate_signup():
    email = f"auto-{int(asyncio.get_event_loop().time())}@ditmail.info"
    await fce.inboxes.register(email)

    async with httpx.AsyncClient() as client:
        await client.post(f"{APP}/api/signup",
                          json={"email": email, "password": "AutoTest123!"})

        otp = await fce.otp.wait_for(email, timeout=30)
        print(f"OTP: {otp}")

        await client.post(f"{APP}/api/verify",
                          json={"email": email, "otp": otp})

    await fce.inboxes.unregister(email)

# Five parallel signups
asyncio.run(asyncio.gather(*[automate_signup() for _ in range(5)]))

Option 4: Playwright (Browser-Based Flows)

When you need to interact with the actual UI rather than call APIs directly:

// tests/fixtures/fce.ts
import { test as base } from '@playwright/test';
import { FreecustomEmailClient } from 'freecustom-email';

const fce = new FreecustomEmailClient({ apiKey: process.env.FCE_API_KEY! });

export const test = base.extend({
  inbox: async ({}, use) => {
    const addr = `pw-${Date.now()}@ditmail.info`;
    await fce.inboxes.register(addr);
    await use(addr);
    await fce.inboxes.unregister(addr).catch(() => {});
  },
  getOtp: async ({ inbox }: any, use: any) => {
    await use((ms = 30_000) => fce.otp.waitFor(inbox, { timeout: ms }));
  },
});

// tests/signup.spec.ts
import { test, expect } from './fixtures/fce';

test('signup flow', async ({ page, inbox, getOtp }: any) => {
  await page.goto('/signup');
  await page.fill('#email', inbox);
  await page.fill('#password', 'Test123!');
  await page.click('button[type="submit"]');
  await page.waitForSelector('#otp-input');

  const otp = await getOtp();
  await page.fill('#otp-input', otp);
  await page.click('button[type="submit"]');
  await expect(page).toHaveURL(/dashboard/);
});

Option 5: Selenium (Python)

from selenium import webdriver
from selenium.webdriver.common.by import By
from freecustom_email import FreeCustomEmail
import asyncio, os, time

fce = FreeCustomEmail(api_key=os.environ["FCE_API_KEY"])
opts = webdriver.ChromeOptions()
opts.add_argument("--headless")
driver = webdriver.Chrome(options=opts)

inbox = f"sel-{int(time.time())}@ditmail.info"
asyncio.run(fce.inboxes.register(inbox))

driver.get("https://myapp.com/signup")
driver.find_element(By.ID, "email").send_keys(inbox)
driver.find_element(By.ID, "password").send_keys("Test123!")
driver.find_element(By.CSS_SELECTOR, "button[type='submit']").click()

otp = asyncio.run(fce.otp.wait_for(inbox, timeout=30))
driver.find_element(By.ID, "otp-input").send_keys(otp)
driver.find_element(By.CSS_SELECTOR, "button[type='submit']").click()

driver.quit()
asyncio.run(fce.inboxes.unregister(inbox))

Option 6: OpenClaw AI Agent (Zero Code)

This one surprised me with how well it works. With any AI agent that can run shell commands, just describe the task:

"Automate a signup at https://myapp.com — create a temp inbox, fill the form, extract the OTP, and complete verification. The fce CLI is already logged in."

The agent figures out the right commands and runs them. Great for one-off tasks or when you want automation without writing a script.

GitHub Actions — Parallel Jobs with Matrix Strategy

jobs:
  signup-automation:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1, 2, 3, 4]

    steps:
      - uses: actions/checkout@v4

      - name: Install fce CLI
        run: curl -fsSL freecustom.email/install.sh | sh

      - name: Run signup automation (shard ${{ matrix.shard }})
        env:
          FCE_API_KEY: ${{ secrets.FCE_API_KEY }}
          APP_URL: ${{ vars.STAGING_URL }}
        run: node scripts/signup-automation.js

      - name: Cleanup on failure
        if: failure()
        env:
          FCE_API_KEY: ${{ secrets.FCE_API_KEY }}
        run: fce inbox list | grep "auto-" | xargs -I{} fce inbox remove {} || true

Handling Apps That Reject Disposable Domains

Some signup forms check the email domain and reject known temp mail addresses. Two options:

Custom domain (Growth plan): Register your own domain in the FCE dashboard. Then test-001@automation.yourcompany.com is a valid FCE inbox. No blocklist problems.

Use less-known FCE domains: Run fce domains to see all domains available on your plan. Some are newer and not on common blocklists.

Approach Comparison

Approach	OTP extraction	Parallel safe	CI-ready	Skill needed
fce CLI + bash	Auto	✓	✓	Bash
JS/TS SDK	Auto	✓	✓	TypeScript
Python SDK	Auto	✓	✓	Python
Playwright fixture	Auto	✓	✓	Playwright
Selenium fixture	Auto	✓	✓	Selenium
OpenClaw AI agent	Auto	Partial	✓	None
Shared inbox (old way)	Manual regex	✗	✗	Regex suffering

Links

🖥️ CLI docs: freecustom.email/api/cli
🤖 Automation hub: freecustom.email/api/automation
📦 GitHub: github.com/DishIs/fce-cli
🚀 Releases: github.com/DishIs/fce-cli/releases
📖 API docs: freecustom.email/api/docs
💬 Discord: discord.com/invite/Ztp7kT2QBz

What is your current setup for testing email verification flows? I am especially curious whether anyone has built something with the AI agent approach — it still feels a bit like magic to me every time it works.

Automating OTP Verification in Playwright Without Writing a Single Regex

Dishant Singh — Sun, 29 Mar 2026 04:39:29 +0000

I used to have a function in my test suite called extractOtpFromEmail. It was 40 lines long, had six different regex patterns for different email formats, and still broke every time an upstream service changed their email template.

When I finally killed that function, I replaced it with one line:

const otp = await fce.otp.waitFor(inbox, { timeout: 30_000 });

This post is about how to get there — a clean, parallel-safe OTP automation setup for Playwright using the FreeCustom.Email API, which is the only disposable email service that ships a proper OTP extraction endpoint (and the only one with an official CLI).

The Core Problem

Playwright's async model and parallel worker architecture are genuinely excellent. But when your test needs to read an email, you hit a wall:

You can't share an inbox across workers — parallel tests receive each other's OTPs
Web-based temp mail sites require a second page context and fragile DOM scraping
Mocking email delivery means you are not testing the actual pipeline
Rolling your own IMAP reader is a project in itself

The answer is a fresh isolated inbox per test, with a purpose-built OTP extraction API that does the parsing for you.

Setup

Install the SDK and create a free account at freecustom.email:

npm install freecustom-email

For the CLI (useful for local debugging):

curl -fsSL freecustom.email/install.sh | sh   # macOS / Linux
npm install -g fcemail@latest                  # All platforms
choco install fce                              # Windows

All releases at github.com/DishIs/fce-cli/releases. Authenticate once:

fce login
# Browser opens → sign in → key saved to keychain automatically

For CI, grab your API key from the dashboard and set FCE_API_KEY as a secret.

The Fixture — The Right Pattern for Playwright

The cleanest way to integrate FCE with Playwright is a custom fixture. Each test gets a fresh inbox and it is cleaned up automatically after:

// tests/fixtures/fce.ts
import { test as base } from '@playwright/test';
import { FreecustomEmailClient } from 'freecustom-email';

type FceFixture = {
  inbox: string;
  getOtp: (timeoutMs?: number) => Promise<string>;
};

const fce = new FreecustomEmailClient({ apiKey: process.env.FCE_API_KEY! });

export const test = base.extend<FceFixture>({
  inbox: async ({}, use) => {
    const addr = `pw-${Date.now()}-${Math.random().toString(36).slice(2, 6)}@ditmail.info`;
    await fce.inboxes.register(addr);
    await use(addr);
    await fce.inboxes.unregister(addr).catch(() => {});
  },

  getOtp: async ({ inbox }, use) => {
    await use((ms = 30_000) => fce.otp.waitFor(inbox, { timeout: ms }));
  },
});

export { expect } from '@playwright/test';

Signup Test

// tests/signup.spec.ts
import { test, expect } from './fixtures/fce';

test('user signs up and verifies email', async ({ page, inbox, getOtp }) => {
  await page.goto('/signup');
  await page.fill('#email', inbox);
  await page.fill('#password', 'TestPass123!');
  await page.click('button[type="submit"]');

  // Wait for OTP screen
  await page.waitForSelector('#otp-input');

  // No polling loop. No regex. Just this:
  const otp = await getOtp();
  expect(otp).toMatch(/^\d+$/);

  await page.fill('#otp-input', otp);
  await page.click('button[type="submit"]');

  await page.waitForURL('**/dashboard');
  expect(page.url()).toContain('/dashboard');
});

Password Reset Test

Because getOtp() always returns the latest OTP in the inbox, multi-step flows work naturally:

test('user resets password via email', async ({ page, inbox, getOtp }) => {
  // First: create and verify the account
  await page.goto('/signup');
  await page.fill('#email', inbox);
  await page.fill('#password', 'Original1!');
  await page.click('button[type="submit"]');
  await page.waitForSelector('#otp-input');
  await page.fill('#otp-input', await getOtp());
  await page.click('button[type="submit"]');
  await page.waitForURL('**/dashboard');

  // Then: request a reset
  await page.goto('/forgot-password');
  await page.fill('#email', inbox);
  await page.click('button[type="submit"]');
  await page.waitForSelector('#reset-otp');

  // getOtp() picks up the new code, not the old one
  const resetOtp = await getOtp();
  await page.fill('#reset-otp', resetOtp);
  await page.fill('#new-password', 'NewPass456!');
  await page.click('button[type="submit"]');
  await page.waitForURL('**/login');
});

Playwright Config — 4 Parallel Workers

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  workers: 4,
  retries: 1,
  timeout: 60_000,
  use: {
    baseURL: process.env.APP_URL,
    headless: true,
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox',  use: { ...devices['Desktop Firefox'] } },
  ],
});

Four workers, four isolated inboxes, no interference. This is the biggest quality-of-life improvement over any shared inbox approach.

Python Version

If you are using Python Playwright:

pip install playwright pytest-playwright freecustom-email pytest-asyncio
playwright install chromium

# conftest.py
import asyncio, os, time, pytest
from freecustom_email import FreeCustomEmail

fce = FreeCustomEmail(api_key=os.environ["FCE_API_KEY"])

@pytest.fixture
def inbox():
    addr = f"pw-{int(time.time())}@ditmail.info"
    asyncio.run(fce.inboxes.register(addr))
    yield addr
    asyncio.run(fce.inboxes.unregister(addr))

@pytest.fixture
def get_otp(inbox):
    return lambda timeout=30: asyncio.run(fce.otp.wait_for(inbox, timeout=timeout))

# tests/test_signup.py
from playwright.sync_api import Page, expect
import re

def test_signup(page: Page, inbox, get_otp):
    page.goto("/signup")
    page.fill("#email", inbox)
    page.fill("#password", "TestPass123!")
    page.click("button[type='submit']")
    page.wait_for_selector("#otp-input")

    otp = get_otp()
    assert otp and otp.isdigit()

    page.fill("#otp-input", otp)
    page.click("button[type='submit']")
    page.wait_for_url("**/dashboard")
    expect(page).to_have_url(re.compile(r"/dashboard"))

GitHub Actions

- name: Playwright E2E tests
  env:
    FCE_API_KEY: ${{ secrets.FCE_API_KEY }}
    APP_URL: ${{ vars.STAGING_URL }}
  run: npx playwright test --workers=4

- name: Upload report
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: playwright-report
    path: playwright-report/

What About Apps That Block Disposable Domains?

Some signup forms validate the email domain and reject known temp mail addresses. If that is an issue, the Growth plan lets you register a custom domain and create inboxes like test-001@automation.yourcompany.com. Register the domain in the dashboard, verify DNS, and you are done.

What the OTP Command Looks Like (CLI debugging)

When I am debugging a failing test locally, I use the CLI directly to inspect what was received:

fce otp pw-1234567890@ditmail.info

────────────────────────────────────────────────
  OTP
────────────────────────────────────────────────

  OTP   ·  212342
  From  ·  noreply@myapp.com
  Subj  ·  Your verification code
  Time  ·  20:19:54

The CLI is separate from the SDK but uses the same underlying API. Useful for quick manual checks without spinning up a test runner.

Links

🖥️ CLI docs: freecustom.email/api/cli
📦 GitHub: github.com/DishIs/fce-cli
🚀 Releases: github.com/DishIs/fce-cli/releases
📖 API docs: freecustom.email/api/docs
💬 Discord: discord.com/invite/Ztp7kT2QBz

Are you using Playwright for E2E tests with email verification? I am curious what your current setup looks like — specifically whether anyone has a nice pattern for handling magic links in Playwright that they are happy with.

How I Stopped Manually Clicking Verification Emails in My Selenium Tests

Dishant Singh — Sun, 29 Mar 2026 04:22:38 +0000

There is a specific kind of frustration that comes from having a nearly-complete automated test suite — one that handles login, forms, payments, navigation — and then hitting a wall at email verification.

You can automate the browser flawlessly. But the moment your app sends a "verify your email" message, someone has to actually read it. In most teams, that someone is still a human, which means your CI pipeline either skips the step, mocks it away, or breaks at 2 AM when a developer accidentally uses the shared test inbox.

I spent way too long doing it wrong before finding a setup that actually works. Here is everything I learned.

Why the Common Approaches All Break Eventually

I have tried most of the workarounds that come up when you search for this problem:

Shared Gmail account — works until it doesn't. Two parallel test jobs submit signups at the same time and each reads the other's OTP. Flaky tests that are impossible to debug.

Hardcoded temp mail URL — you need a second Selenium session pointed at a web UI to read it. Fragile DOM scraping, timing issues, and the site goes down at the worst time.

Mocking the email step — this one is actually the most dangerous. Your signup flow "passes" in CI but your real email pipeline could be silently broken. You find out in production.

nodemailer + IMAP — complex OAuth setup, token rotation, and you still have to write regex to parse the OTP from the email body.

What I actually needed was simple: a fresh inbox per test, fast delivery, and OTP extraction that does not require me to maintain regex patterns. That is what the FreeCustom.Email API provides.

The Setup

curl -fsSL freecustom.email/install.sh | sh
fce login
# Opens browser → signs you in → saves key to OS keychain

Or pick your package manager:

brew tap DishIs/homebrew-tap && brew install fce   # Homebrew
npm install -g fcemail@latest                      # npm
choco install fce                                  # Chocolatey (Windows)
scoop bucket add fce https://github.com/DishIs/scoop-bucket && scoop install fce  # Scoop
go install github.com/DishIs/fce-cli@latest        # Go

All releases: github.com/DishIs/fce-cli/releases

For the Python tests below, install the SDK:

pip install freecustom-email selenium pytest pytest-asyncio

The Pattern That Works

Every email verification automation follows three steps:

1. Create a fresh disposable inbox
2. Submit it in the signup form
3. Extract the OTP

The key word is fresh. Each test gets its own inbox. Parallel tests never collide.

Python + Selenium — Full Example

Here is a pytest fixture-based setup I have been using in production CI:

# conftest.py
import asyncio
import os
import time
import pytest
from freecustom_email import FreeCustomEmail

fce = FreeCustomEmail(api_key=os.environ["FCE_API_KEY"])

@pytest.fixture
def inbox():
    addr = f"sel-{int(time.time())}@ditapi.info"
    asyncio.run(fce.inboxes.register(addr))
    yield addr
    asyncio.run(fce.inboxes.unregister(addr))

# tests/test_signup.py
import asyncio
import pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from freecustom_email import FreeCustomEmail
import os

fce = FreeCustomEmail(api_key=os.environ["FCE_API_KEY"])
APP_URL = os.environ.get("APP_URL", "https://staging.myapp.com")

@pytest.fixture
def driver():
    opts = webdriver.ChromeOptions()
    opts.add_argument("--headless")
    opts.add_argument("--no-sandbox")
    drv = webdriver.Chrome(options=opts)
    yield drv
    drv.quit()

@pytest.mark.asyncio
async def test_signup_and_verify(driver, inbox):
    wait = WebDriverWait(driver, 15)

    # Fill the signup form with our temp inbox address
    driver.get(f"{APP_URL}/signup")
    wait.until(EC.presence_of_element_located((By.ID, "email"))).send_keys(inbox)
    driver.find_element(By.ID, "password").send_keys("TestPass123!")
    driver.find_element(By.CSS_SELECTOR, "button[type='submit']").click()

    # Wait for the OTP screen
    wait.until(EC.presence_of_element_located((By.ID, "otp-input")))

    # This is the part that used to require regex — now it's one line
    otp = await fce.otp.wait_for(inbox, timeout=30)
    assert otp and otp.isdigit()

    # Fill OTP and verify
    driver.find_element(By.ID, "otp-input").send_keys(otp)
    driver.find_element(By.CSS_SELECTOR, "button[type='submit']").click()

    wait.until(EC.url_contains("/dashboard"))
    assert "/dashboard" in driver.current_url

The fce.otp.wait_for() call handles all the polling and parsing internally. It returns the numeric code (or verification link, depending on your app). No regex to write or maintain.

JavaScript + Selenium — Same Idea

import { Builder, By, until } from 'selenium-webdriver';
import { FreecustomEmailClient } from 'freecustom-email';

const fce = new FreecustomEmailClient({ apiKey: process.env.FCE_API_KEY! });

async function testSignup() {
  const inbox = `sel-${Date.now()}@ditapi.info`;
  await fce.inboxes.register(inbox);

  const driver = await new Builder().forBrowser('chrome').build();
  try {
    await driver.get(`${process.env.APP_URL}/signup`);
    await driver.wait(until.elementLocated(By.id('email')), 10_000);
    await driver.findElement(By.id('email')).sendKeys(inbox);
    await driver.findElement(By.id('password')).sendKeys('TestPass123!');
    await driver.findElement(By.css("button[type='submit']")).click();
    await driver.wait(until.elementLocated(By.id('otp-input')), 10_000);

    const otp = await fce.otp.waitFor(inbox, { timeout: 30_000 });
    await driver.findElement(By.id('otp-input')).sendKeys(otp);
    await driver.findElement(By.css("button[type='submit']")).click();
    await driver.wait(until.urlContains('/dashboard'), 10_000);

    console.log(`✓ Signup verified. OTP was: ${otp}`);
  } finally {
    await driver.quit();
    await fce.inboxes.unregister(inbox);
  }
}

testSignup();

What the OTP Output Actually Looks Like

When you call fce otp <inbox> from the CLI (useful for debugging), here is what you get:

────────────────────────────────────────────────
  OTP
────────────────────────────────────────────────

  OTP   ·  212342
  From  ·  noreply@myapp.com
  Subj  ·  Your verification code
  Time  ·  20:19:54

In a shell script you can grab just the code:

OTP=$(fce otp "$INBOX" | grep "OTP   ·" | awk '{print $NF}')

Parallel Tests — This Is Where It Gets Good

Because every test has its own inbox, you get parallel safety for free:

pip install pytest-xdist
pytest -n 4 tests/test_signup.py

Four Chrome sessions, four isolated inboxes, no collisions. This was impossible with any shared inbox approach.

GitHub Actions

- name: E2E signup tests
  env:
    FCE_API_KEY: ${{ secrets.FCE_API_KEY }}
    APP_URL: ${{ vars.STAGING_URL }}
  run: |
    pip install selenium pytest pytest-asyncio pytest-xdist freecustom-email
    pytest -n 4 tests/ -v

Get FCE_API_KEY from the dashboard after running fce login locally. Set it as a repository secret.

What About Magic Links Instead of Numeric OTPs?

Some apps send a clickable link rather than a code. The FCE API handles this too — the message object includes a verification_link field:

messages = await fce.messages.list(inbox)
msg = await fce.messages.get(inbox, messages[0].id)
driver.get(msg.verification_link)

Plans and Pricing

The OTP extraction endpoint requires Growth plan ($49/mo). WebSocket real-time delivery (instead of polling) requires Startup ($19/mo). Everything else — inbox creation, message fetching, the CLI — works on the free tier.

Plan	Price	OTP extraction	WebSocket
Free	$0	✗	✗
Developer	$7/mo	✗	✗
Startup	$19/mo	✗	✓
Growth	$49/mo	✓	✓

Full details at freecustom.email/api/pricing.

I Built the First Official CLI for a Disposable Email Service — Here's Why and How to Use It

Dishant Singh — Sun, 15 Mar 2026 22:24:08 +0000

The problem: email verification is the last manual step in automated pipelines

If you have ever tried to automate a signup flow in CI/CD, you know the pain. You can automate everything — provisioning, building, deploying, testing — but the moment your app sends a verification email, you are stuck. You either:

Keep a shared test inbox that becomes a mess of race conditions when tests run in parallel
Mock the email step and quietly stop testing the actual delivery pipeline
Write fragile regex against a third-party API and break every time the email format changes
Just... click through it manually in staging

None of those are good. So I built fce.

What is fce?

fce is the official CLI for FreeCustom.Email — a disposable inbox API. It lets you create temporary inboxes, stream incoming emails in real time via WebSocket, and extract OTP codes automatically, all from your terminal.

As far as I can tell, it is the only official CLI tool for any disposable or temporary email service in the world. Every other provider — Mailinator, Guerrilla Mail, Temp-Mail — stops at a REST API at best. No one else ships an installable binary.

The source is fully open on GitHub: github.com/DishIs/fce-cli, MIT licensed, written in Go, available for macOS, Linux, and Windows.

Install in one line

curl -fsSL freecustom.email/install.sh | sh

Or pick your package manager:

# macOS / Linux — Homebrew
brew tap DishIs/homebrew-tap
brew install fce

# Windows — Scoop
scoop bucket add fce https://github.com/DishIs/scoop-bucket
scoop install fce

# Windows — Chocolatey
choco install fce

# All platforms — npm
npm install -g fcemail@latest

# All platforms — Go
go install github.com/DishIs/fce-cli@latest

Latest release is always at github.com/DishIs/fce-cli/releases. You can also update in-place at any time:

fce update

Login — browser-based, keychain-backed

Authentication opens your browser and saves a key to your OS keychain automatically. No manual API key copying, no environment variable setup for local use, no tokens expiring mid-test.

fce login

  [1/3]  Opening browser…
  [2/3]  Waiting for authentication…
  [3/3]  Saving credentials…

  ✓  Logged in successfully!
  ·  Run `fce status` to see your account details.

Keys live in macOS Keychain, Windows Credential Manager, or Linux Secret Service (libsecret). They automatically reflect your current plan — upgrade your plan, the CLI picks it up instantly with no extra steps.

`fce dev` — the command I use every single day

This is the one that changed my workflow. fce dev combines inbox creation and real-time watching into a single command:

fce dev

  ·  Temporary inbox: dev-fy8x@ditcloud.info
  ✓  Watching for emails...

  ✓  Watching dev-fy8x@ditcloud.info   GROWTH
  ·  Waiting for emails… (press Ctrl+C to stop)

────────────────────────────────────────────────────
  ID    JpW3DImT3
  FROM  "Dishant Singh" <dishupandey57@gmail.com>
  SUBJ  Your OTP for FCE: 212342
  TIME  20:19:54
────────────────────────────────────────────────────

Fresh disposable address, WebSocket connection open, emails arriving in real time — all in one command. When I am building a signup flow locally, I open one terminal pane with fce dev and trigger the flow in another. The email shows up in under 200ms.

Before this existed, the equivalent was: open browser, go to a temp mail site, copy the address, paste it into the app, switch tabs, wait for the page to refresh, manually copy the OTP. That is six manual steps for something that should be zero steps.

`fce otp` — no regex required

Once you have an inbox and an email has arrived, extracting the OTP is one command:

fce otp dev-fy8x@ditcloud.info

────────────────────────────────────────────────
  OTP
────────────────────────────────────────────────

  OTP   ·  212342
  From  ·  "Dishant Singh" <dishupandey57@gmail.com>
  Subj  ·  Your OTP for FCE: 212342
  Time  ·  20:19:54

In a script, capture just the code:

OTP=$(fce otp dev-fy8x@ditcloud.info | grep "OTP   ·" | awk '{print $NF}')
echo "$OTP"
# 212342

The extraction engine handles numeric codes, alphanumeric tokens, magic links, and multi-part MIME emails. It has been tested across hundreds of different email service formats. If the email format changes, the extraction does not break — it is not regex-based.

fce otp requires the Growth plan. fce watch (WebSocket streaming) requires Startup. All other commands work on the free tier.

CI/CD — use `FCE_API_KEY` for headless environments

For CI runners where there is no browser, grab your API key from the FreeCustom.Email dashboard after logging in locally and set it as a secret:

# .github/workflows/email-test.yml
- name: E2E email verification
  env:
    FCE_API_KEY: ${{ secrets.FCE_API_KEY }}
  run: |
    curl -fsSL freecustom.email/install.sh | sh

    INBOX=$(fce inbox add random | tr -d '[:space:]')
    echo "Inbox: $INBOX"

    curl -s -X POST https://staging.myapp.com/api/signup \
      -H "Content-Type: application/json" \
      -d "{\"email\": \"$INBOX\"}"

    OTP=$(fce otp "$INBOX" | grep "OTP   ·" | awk '{print $NF}')
    echo "OTP: $OTP"

    curl -s -f -X POST https://staging.myapp.com/api/verify \
      -H "Content-Type: application/json" \
      -d "{\"email\": \"$INBOX\", \"otp\": \"$OTP\"}"

Fresh inbox per run, real OTP extraction, no shared state. Five parallel test jobs each get their own inbox with zero interference.

The full command surface

Here is everything fce can do today:

Command	Description	Plan
`fce login`	Browser-based auth, keychain-backed	Any
`fce logout`	Remove stored credentials	Any
`fce dev`	Create temp inbox + watch instantly	Any
`fce watch [inbox\	random]`	Stream emails via WebSocket
`fce otp <inbox>`	Extract latest OTP	Growth+
`fce status`	Account info, plan, inbox counts	Any
`fce inbox list`	List registered inboxes	Any
`fce inbox add <addr>`	Register a new inbox	Any
`fce inbox add random`	Register a random inbox	Any
`fce inbox remove <addr>`	Unregister an inbox	Any
`fce messages <inbox> [id]`	List or view messages	Any
`fce domains`	List available domains	Any
`fce usage`	Credit consumption this period	Any
`fce update`	Update CLI to latest version	Any
`fce uninstall`	Remove all local config + credentials	Any
`fce version`	Show version info	Any

It also has a full REST API and official SDKs

The CLI is the terminal face of FreeCustom.Email's API. If you prefer to work in code directly, there are official SDKs:

JavaScript / TypeScript

npm install freecustom-email

import { FreecustomEmailClient } from 'freecustom-email';

const client = new FreecustomEmailClient({ apiKey: process.env.FCE_API_KEY });
await client.inboxes.register('test@ditmail.info');
const otp = await client.otp.waitFor('test@ditmail.info');
console.log(otp); // '212342'

Python

pip install freecustom-email

from freecustom_email import FreeCustomEmail
import asyncio, os

client = FreeCustomEmail(api_key=os.environ["FCE_API_KEY"])

async def main():
    await client.inboxes.register("test@ditmail.info")
    otp = await client.otp.wait_for("test@ditmail.info")
    print(otp)  # '212342'

asyncio.run(main())

Automation — AI agents, n8n, Make, Zapier

One thing I am particularly excited about: because fce is a proper CLI, it works with any AI agent that can run shell commands. With OpenClaw (or Claude, GPT-4o, etc.) you can just describe what you want:

"Create a random inbox, watch it, and return the next OTP that arrives"

The agent runs fce dev, watches the WebSocket output, calls fce otp, and returns the result. No glue code.

For visual workflow automation, it works out of the box with n8n via Execute Command nodes. Native Make and Zapier integrations are coming in Q2 2026.

Full automation docs: freecustom.email/api/automation

Pricing

The CLI works with every plan. The free tier is genuinely useful for local development:

Plan	Price	Req/month	WebSocket (`watch`)	OTP (`otp`)
Free	$0	5,000	✗	✗
Developer	$7/mo	100,000	✗	✗
Startup	$19/mo	500,000	✓	✗
Growth	$49/mo	2,000,000	✓	✓
Enterprise	$149/mo	10,000,000	✓	✓

No credit card required for the free tier. Full pricing at freecustom.email/api/pricing.

Stop Polling for OTPs — Use a Disposable Inbox API with Real-Time WebSocket Push

Dishant Singh — Fri, 13 Mar 2026 18:32:48 +0000

If you've ever written an end-to-end test that covers an email verification
flow, you know the pain. You call your sign-up endpoint, an email goes out,
and then... you poll. You sleep 2 seconds, check the inbox, sleep again,
check again, pray the CI server isn't slow today.

It works. It's also fragile, slow, and annoying to maintain.

This post covers a better approach: using a disposable inbox API
(FreeCustom.email) that gives
you a real inbox per test run, automatic OTP extraction, and a WebSocket
connection that pushes the email to you the moment it arrives — no polling,
no sleeps, no flakiness.

The problem with polling

The standard approach looks like this:

await signUp({ email: 'test123@mailinator.com', password: 'hunter2' });

// 🤢 please don't do this
let otp = null;
for (let i = 0; i < 10; i++) {
  await sleep(2000);
  const messages = await checkMailinator('test123');
  if (messages.length > 0) {
    otp = extractOtp(messages[0].body); // regex hell
    break;
  }
}

Problems:

Flaky — your regex breaks when the email template changes
Slow — you're waiting up to 20 seconds for something that arrived in 300ms
Shared inboxes — Mailinator's public inboxes mean test data from other runs can bleed in
No isolation — parallel test runs interfere with each other

A better flow

Here's the same test using the FreeCustom.email API:

const BASE = 'https://api.freecustom.email/v1';
const HEADERS = { Authorization: `Bearer ${process.env.FCE_API_KEY}` };

// 1. Register a unique inbox for this test run
const inbox = `test-${crypto.randomUUID()}@ditube.info`;
await fetch(`${BASE}/inboxes`, {
  method: 'POST',
  headers: { ...HEADERS, 'Content-Type': 'application/json' },
  body: JSON.stringify({ inbox }),
});

// 2. Trigger your sign-up flow
await signUp({ email: inbox, password: 'hunter2' });

// 3. Wait for the OTP — with a real timeout, not a sleep loop
const otp = await waitForOtp(inbox);

// 4. Complete verification
await verifyAccount({ email: inbox, otp });

// 5. Clean up
await fetch(`${BASE}/inboxes/${inbox}`, { method: 'DELETE', headers: HEADERS });

The waitForOtp function uses the WebSocket endpoint:

async function waitForOtp(inbox, timeoutMs = 10000) {
  return new Promise((resolve, reject) => {
    const ws = new WebSocket(
      `wss://api.freecustom.email/v1/ws?api_key=${process.env.FCE_API_KEY}&mailbox=${inbox}`
    );

    const timer = setTimeout(() => {
      ws.close();
      reject(new Error('OTP timeout'));
    }, timeoutMs);

    ws.on('message', (data) => {
      const event = JSON.parse(data);
      if (event.type === 'connected') return; // welcome frame
      if (event.otp) {
        clearTimeout(timer);
        ws.close();
        resolve(event.otp);
      }
    });

    ws.on('error', (err) => {
      clearTimeout(timer);
      reject(err);
    });
  });
}

The email arrives, Redis pub/sub fires, WebSocket pushes it to your client,
OTP is already parsed. The whole round-trip from email sent to OTP in hand
is typically under 500ms.

Or just use the REST endpoint

If WebSocket feels like overkill for your use case (simple scripts, CI jobs),
there's a dedicated OTP endpoint that's much simpler:

curl https://api.freecustom.email/v1/inboxes/test@ditube.info/otp \
  -H "Authorization: Bearer $FCE_API_KEY"

{
  "success": true,
  "otp": "482910",
  "email_id": "64f1a2b3c4d5e6f7a8b9c0d1",
  "from": "no-reply@yourapp.com",
  "subject": "Your verification code",
  "timestamp": 1710234567000,
  "verification_link": "https://yourapp.com/verify?code=482910"
}

No regex. No template parsing. The OTP is just... there.

Quick API reference

Endpoint	What it does
`POST /v1/inboxes`	Register an inbox
`GET /v1/inboxes`	List your registered inboxes
`DELETE /v1/inboxes/:inbox`	Unregister an inbox
`GET /v1/inboxes/:inbox/messages`	List all messages
`GET /v1/inboxes/:inbox/messages/:id`	Get a single message
`GET /v1/inboxes/:inbox/otp`	Get the latest OTP
`DELETE /v1/inboxes/:inbox/messages/:id`	Delete a message
`WSS /v1/ws?api_key=...&mailbox=...`	Real-time push

Every response includes rate limit headers:

X-API-Plan: developer
X-RateLimit-Limit-Second: 10
X-RateLimit-Remaining-Second: 9
X-RateLimit-Limit-Month: 100000
X-RateLimit-Remaining-Month: 99847

Authentication

Keys are passed via Authorization: Bearer header or ?api_key= query param.
Keys are SHA-256 hashed on the server — the raw key is shown once at creation
and never stored. Rotating a key doesn't reset your monthly quota since usage
is tracked by account, not by key.

// Header (recommended)
Authorization: Bearer fce_abc123...

// Query param (useful for WebSocket connections)
?api_key=fce_abc123...

Plans

Plan	Price	Req/mo	OTP	WebSocket
Free	Free	5,000	❌	❌
Developer	$7/mo	100,000	✅	❌
Startup	$19/mo	500,000	✅	✅
Growth	$49/mo	2,000,000	✅	✅ + custom domains
Enterprise	$149/mo	10,000,000	✅	✅

You can also buy non-expiring request credits ($10 → 200k requests) as a
top-up on any plan.

Try it

Interactive playground (no sign-up needed to explore):
https://www.freecustom.email/api/playground

Free tier is genuinely free — 5,000 requests/month, no credit card.

I'm the developer — happy to answer questions in the comments about the
architecture, how OTP parsing works, or anything else. Would also love
to know: what does your current verification testing flow look like?
What's the most painful part?

How to Download Your Full Project from v0.app (When “Download ZIP” Doesn’t Work)

Dishant Singh — Mon, 23 Feb 2026 16:52:03 +0000

If you’re using v0.app and the Download ZIP option is disabled, stuck on “Waiting for sandbox to start…”, or not working — you can export your entire project using the built-in terminal.

This method works reliably for any v0 sandbox.

The Problem

Sometimes:

Download ZIP is greyed out
It shows Waiting for sandbox to start
Or clicking it does nothing

This usually happens when the sandbox hasn’t fully initialized.

Step 1: Open the Terminal

You can open the terminal in two ways (just like VS Code):

Option A — From the menu

Top-left menu → Terminal → New Terminal

Option B — Drag to reveal

Drag the bottom panel upward if it’s hidden
The terminal panel will appear

You should see a prompt like:

[vercel-sandbox@xxxx v0-project]$

Step 2: Create the Project Archive

Run:

tar -czf project.tar.gz .

You may see this warning:

tar: .: file changed as we read it

This is normal and safe to ignore.

Step 3: Find the File

After a few seconds:

Check the file explorer (left panel)
You’ll see:

project.tar.gz

in the root folder.

If it doesn’t appear immediately, refresh the explorer.

Step 4: Download the File

Right-click project.tar.gz
Click Download

You now have the full project locally.

Optional: Cleaner Export

Exclude heavy folders:

tar -czf project.tar.gz . --exclude=node_modules --exclude=.git

Extract Locally

macOS / Linux

tar -xzf project.tar.gz

Windows

Extract using 7-Zip or WinRAR

Quick Copy Command

tar -czf project.tar.gz .

When to Use This Method

Use this if:

Download ZIP is disabled
Sandbox is stuck or slow
You need a quick backup
You want to move the project to local development

This simple terminal trick bypasses UI issues and works consistently for any v0.app project.

Automating Workflows with Image Hosting API and MCP Servers

Dishant Singh — Sun, 14 Sep 2025 08:03:08 +0000

Developers can supercharge their applications by integrating Dishis Technologies' Image Hosting API not only into their websites but also into automation workflows and MCP (Model Context Protocol) servers.

Why Use Automations?

Automations reduce repetitive manual work by allowing your app or system to:

Upload product images automatically.
Generate thumbnails on-the-fly.
Handle bulk image processing in background tasks.
Provide image URLs to other services (chatbots, design tools, dashboards).

With our Image Hosting API, you get no bandwidth limits, 35 MB per image support, and flat request-based billing.

Using the API in Automations

Example: Node.js Script for Automated Uploads

import fetch from "node-fetch";

const API_URL = "https://prod.api.market/store/dishis-tech/image/upload";
const API_KEY = process.env.DISHIS_API_KEY; // Store in env for security

async function uploadImage(base64Image) {
  const response = await fetch(API_URL, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "x-api-market-key": API_KEY,
    },
    body: JSON.stringify({
      image: base64Image,
    }),
  });

  const data = await response.json();
  console.log("Image uploaded:", data);
  return data;
}

// Example usage
uploadImage("<BASE64_STRING>");

Setting Up for MCP Servers

You can register the Dishis Image Hosting API inside your MCP server configuration for seamless automation.

Example MCP Config

{
  "mcpServers": {
    "dishis_image": {
      "url": "https://prod.api.market/api/mcp/dishis-tech/image",
      "headers": {
        "x-api-market-key": "cm7g...."
      }
    }
  }
}

This allows your MCP-powered agents and tools to call the image hosting API directly.

Example Workflow in MCP

User uploads a design file.
MCP agent triggers the Dishis Image Hosting API.
Response provides permanent URLs + thumbnails.
URLs are stored in your database or sent to downstream apps (CMS, chatbot, ERP).

API Response Example

{
  "data": {
    "id": "Ps9FZHtW",
    "url": "https://i.ibb.co/j9WbvXHw/string.png",
    "display_url": "https://i.ibb.co/CpMm5GW9/string.png",
    "width": 1280,
    "height": 692,
    "size": 96415,
    "image": {
      "filename": "string.png",
      "mime": "image/png",
      "url": "https://i.ibb.co/j9WbvXHw/string.png"
    },
    "thumb": {
      "url": "https://i.ibb.co/Ps9FZHtW/string.png"
    },
    "medium": {
      "url": "https://i.ibb.co/CpMm5GW9/string.png"
    },
    "delete_url": "https://ibb.co/Ps9FZHtW/9205a77cc5c27603389188d7e0e71df3"
  },
  "success": true,
  "status": 200
}

Conclusion

By combining Dishis Technologies' Image Hosting API with MCP servers, you unlock powerful automation capabilities. From bulk e-commerce product uploads to AI workflow integrations, this approach saves time and scales effortlessly.

👉 Start here: Get API Key on RapidAPI

👉 For advanced plans: API Market Store

How to Set Up Our Image Hosting API on Your E-Commerce App or Website

Dishant Singh — Sun, 14 Sep 2025 07:58:50 +0000

When building an e-commerce app or website, managing product images efficiently is crucial. High-resolution photos directly impact user experience and conversion rates. Our Image Hosting API makes it simple to upload, manage, and deliver product images without worrying about bandwidth limits or hidden costs.

In this guide, we’ll walk through how to set up our API in your e-commerce app or site.

Why Use Our Image Hosting API?

Flat pricing – no bandwidth billing, just per-request pricing.
High upload limit – 35 MB per image (5–10x higher than Cloudinary or others).
No auto-delete – your product images stay online.
Flexible uploads – support for binary files, base64, or image URLs.
Free tier available – perfect to test integration before scaling.

👉 Get your API key on RapidAPI: Upload Images Hosting API

For higher usage and bulk plans: Dishis Tech Store

Step 1: Get Your API Key

Sign up on RapidAPI.
Subscribe to a plan that fits your needs.
Copy your API key from the dashboard.

Step 2: Upload an Image

Here’s an example request in JavaScript (fetch):

const url = "https://upload-images-hosting-get-url.p.rapidapi.com/upload";
const data = new FormData();
data.append("image", fileInput.files[0]); // your product image file

fetch(url, {
  method: "POST",
  headers: {
    "X-RapidAPI-Key": "YOUR_API_KEY",
    "X-RapidAPI-Host": "upload-images-hosting-get-url.p.rapidapi.com"
  },
  body: data
})
  .then(response => response.json())
  .then(result => console.log(result))
  .catch(error => console.error(error));

Step 3: Example API Response

The API returns structured JSON with multiple image URLs (viewer, direct link, thumbnail, medium).

{
  "data": {
    "id": "Ps9FZHtW",
    "title": "string",
    "url_viewer": "https://ibb.co/Ps9FZHtW",
    "url": "https://i.ibb.co/j9WbvXHw/string.png",
    "display_url": "https://i.ibb.co/CpMm5GW9/string.png",
    "width": 1280,
    "height": 692,
    "size": 96415,
    "image": {
      "filename": "string.png",
      "url": "https://i.ibb.co/j9WbvXHw/string.png"
    },
    "thumb": {
      "url": "https://i.ibb.co/Ps9FZHtW/string.png"
    },
    "medium": {
      "url": "https://i.ibb.co/CpMm5GW9/string.png"
    },
    "delete_url": "https://ibb.co/Ps9FZHtW/9205a77cc5c27603389188d7e0e71df3"
  },
  "success": true,
  "status": 200
}

Step 4: Integrate Into Your E-Commerce Workflow

Product Upload Flow:
- Let sellers/admins upload product images via your dashboard.
- Call our API to store the images.
- Save the returned url or display_url in your database.
Frontend Display:
- Use the url for product detail pages.
- Use the thumb for category and search result pages.
- Use the medium for cart or recommendation widgets.

Step 5: Manage Storage and Scaling

Use delete_url for removing outdated product images.
Start with Free or Pro plan on RapidAPI, then scale to Mega or Biz plans.
For high-traffic e-commerce sites, check our Bulk plan at Dishis Tech Store.

Conclusion

By integrating our Image Hosting API, your e-commerce app will:

Load product images faster.
Handle high-res photos without hitting limits.
Avoid bandwidth overage charges.

This means better SEO, improved user experience, and higher conversion rates.

👉 Try it today: Upload Images Hosting API

🚀 A Simple, Affordable Image Hosting API (35MB per Image, No Bandwidth Limits)

Dishant Singh — Sun, 14 Sep 2025 07:49:14 +0000

If you’ve ever worked with image uploads in your project, you’ve probably hit one of these pain points:

Cloudinary-style pricing shock (paying for bandwidth + storage separately)
Strict image size caps (10–20MB max on most APIs)
Surprise overage bills when traffic spikes
Auto-deletion of your uploads after a short time

That’s why we built the Simple Image Hosting API — a developer-first solution that’s flat-priced, predictable, and designed for real-world use cases.

👉 Get started instantly on RapidAPI:
Upload Images Hosting API

🖼️ Why This API?

Here’s what sets it apart from other image hosting APIs:

Flat Pricing – Pay per request, no bandwidth billing.
35MB per image – Handle high-res photos, design assets, and screenshots without compression errors.
No Auto-Delete – Unlike “temporary image hosts,” your uploads stay.
Flexible Uploads – Send images via:
- Binary file
- Base64 data
- A URL pointing to the image

⚡ Quick Example (Node.js)

Uploading an image via URL is as simple as one POST request:

const axios = require("axios");

async function uploadImage() {
  const options = {
    method: 'POST',
    url: 'https://upload-images-hosting-get-url.p.rapidapi.com/upload',
    headers: {
      'x-rapidapi-host': 'upload-images-hosting-get-url.p.rapidapi.com',
      'x-rapidapi-key': 'YOUR_API_KEY',
      'Content-Type': 'application/json'
    },
    data: {
      url: "https://example.com/your-image.png"
    }
  };

  try {
    const res = await axios.request(options);
    console.log(res.data);
  } catch (err) {
    console.error(err);
  }
}

uploadImage();

Example Response

{
  "data": {
    "id": "Ps9FZHtW",
    "title": "string",
    "url_viewer": "https://ibb.co/Ps9FZHtW",
    "url": "https://i.ibb.co/j9WbvXHw/string.png",
    "display_url": "https://i.ibb.co/CpMm5GW9/string.png",
    "width": 1280,
    "height": 692,
    "size": 96415,
    "time": 1757746440,
    "expiration": 15552000,
    "image": {
      "filename": "string.png",
      "name": "string",
      "mime": "image/png",
      "extension": "png",
      "url": "https://i.ibb.co/j9WbvXHw/string.png"
    },
    "thumb": {
      "filename": "string.png",
      "name": "string",
      "mime": "image/png",
      "extension": "png",
      "url": "https://i.ibb.co/Ps9FZHtW/string.png"
    },
    "medium": {
      "filename": "string.png",
      "name": "string",
      "mime": "image/png",
      "extension": "png",
      "url": "https://i.ibb.co/CpMm5GW9/string.png"
    },
    "delete_url": "https://ibb.co/Ps9FZHtW/9205a77cc5c27603389188d7e0e71df3"
  },
  "success": true,
  "status": 200
}

That’s it — you’ve got a permanent hosted image link ready to embed anywhere.

💸 Pricing (No Surprises)

Unlike Cloudinary/ImageKit (where pricing depends on storage, transformations, and bandwidth), we keep it simple:

Free Tier – Test instantly
Pro / Ultra / Mega – Scale up as you grow

👉 Check plans on RapidAPI here:
Plans up to Mega

👉 Need bigger plans (Biz & Bulk)? They’re available on API Market:
Full Pricing (Biz & Bulk)

🛠️ Perfect Use Cases

High-resolution photography apps
Graphic design & print workflows
SaaS products needing reliable image storage
Developers building social apps, dashboards, or CMS tools
Agencies managing multiple client projects

🚀 Start Free in 30 Seconds

Get your free API key on RapidAPI: Upload Images Hosting API
Make your first request (free tier included).
Scale up when your app is ready.

✅ TL;DR

No bandwidth billing → predictable cost
35 MB limit per image → larger than most providers
Flat per-request pricing → scale without anxiety
Free tier available → try it now

We built this API to give developers a straightforward, no-surprise image hosting option. Whether you’re working on a personal side project or scaling a SaaS product, this API has you covered.

👉 Start free on RapidAPI
👉 View extended plans on API Market

New Domains Added! More Power and Flexibility for Your Temporary Emails

Dishant Singh — Tue, 15 Jul 2025 17:50:56 +0000

Try Out Our New Domains Now at FreeCustom.Email â†’

At FreeCustom.Email, our mission has always been to provide the most powerful, flexible, and user-friendly temporary email service available. A core part of that flexibility is giving you choices. Today, we're thrilled to announce a massive expansion of our service with the addition of 13 new domains available for you to use immediately!

This update significantly enhances your ability to create the perfect temporary email address for any situation, giving you more control and a higher chance of success when signing up for services online.

Why More Domains Matter

You might be wondering, "Why do I need more than one domain for my temp mail?" Having a diverse and growing list of domains is a key feature that sets a premium temporary email service apart. Hereâ€™s why it's a game-changer for you:

Bypassing Blocks: Some websites and services actively identify and block domains commonly associated with temporary email. As one domain becomes more popular, its likelihood of being blocked increases. By constantly adding new, fresh domains, we give you a much higher chance of your temporary email being accepted everywhere.
Enhanced Anonymity: Using less common or newer domains can help your temporary email blend in, drawing less attention than addresses from well-known public temp mail domains.
Better Organization: You can use different domains for different purposes. Perhaps you use one domain for software trials and another for forum sign-ups, helping you mentally categorize your temporary identities.
More Customization Options: Combined with our "anyone can put any email name" feature, a larger domain pool exponentially increases the number of unique, creative email addresses you can generate.

Introducing Our New Lineup of Domains

We've carefully selected a mix of professional, creative, and utility-focused domains to suit any need. We're excited to add the following to our list of available options:

Creative & General Purpose Domains:

arrangewith.me - Perfect for scheduling or coordinating temporary projects.
areueally.info - A playful and memorable option for social sign-ups.
whatsyour.info - Great for forums or Q&A sites where you're creating a new persona.

DIT Branded & Tech-Focused Domains:

Showcasing the power of the DishIs Technology ecosystem, these domains are great for developer testing, tech forums, or just a professional flair.

ditapi.info
ditcloud.info
ditdrive.info
ditgame.info
ditlearn.info
ditpay.info
ditplay.info
ditube.info

Utility & Privacy-Focused Domains:

junkstopper.info - The name says it all! The perfect domain when your primary goal is to stop spam before it starts.
saleis.live - A great choice for signing up for e-commerce deals and promotions without cluttering your main inbox.

How to Use the New Domains

Using our new domains is as simple as ever.

Navigate to FreeCustom.Email.
Enter Your Custom Name: Type any prefix you want in the email address field.
Click the Domain Dropdown: Click on the domain part of the email address (the part after the "@" symbol).
Select Your Choice: A dropdown menu will now display our full list of domains, including all the new additions. Simply click the one you want to use.
You're Ready! Your new temporary email address is instantly created with your chosen name and domain, ready to be copied and used anywhere.

The table below shows some creative examples:

Your Goal	Custom Name	Chosen New Domain	Resulting Temp Email
Testing a game's beta	`beta-tester`	`ditgame.info`	`beta-tester@ditgame.info`
Signing up for a sales newsletter	`deal-catcher`	`junkstopper.info`	`deal-catcher@junkstopper.info`
Accessing a learning platform	`new-student`	`ditlearn.info`	`new-student@ditlearn.info`
Creating a forum account	`question-asker`	`whatsyour.info`	`question-asker@whatsyour.info`

Our Commitment to Continuous Improvement

This domain expansion is part of our ongoing commitment to providing you with the best possible temporary email experience. We are constantly monitoring the digital landscape to ensure our service remains effective, reliable, and ahead of the curve.

We'll continue to add new domains and features to give you unparalleled control over your online privacy and communications. Thank you for being part of the FreeCustom.Email community!

Ready to take them for a spin?

Try out our new domains and create your perfect temporary email now! â†’

DEV Community: Dishant Singh

The Best Temp Mail API in 2026: A Practical Guide for Developers

What "Temp Mail API" Actually Means in 2026

FreeCustom.Email: The Complete Developer Platform

The MCP Server: One Tool Call for the Full Signup Flow

The Wait API: Long-Polling for Scripts and Tests

Webhooks: Server-Push for Persistent Backends

The CLI: The Only One in the Industry

Pricing

Mailinator: The Enterprise QA Platform

MailSlurp: Best for Email Send + Receive Testing

mail.tm: The Free Minimalist Option

The Parallel Test Problem

LangChain Integration Example

Summary

I Switched From mail.tm to This — Here's What I Got

The Gap That Kept Growing

The CLI Is the Biggest Difference

OTP Extraction: mail.tm vs fce

Migration from mail.tm

Step 1: Get an FCE account and key

Step 2: Replace account creation with inbox registration

Step 3: Replace polling + regex with OTP extraction

Step 4: Replace account deletion with inbox removal

Real-Time vs Polling

Authentication: JWT Hell vs Bearer Token

The Automation Ecosystem That mail.tm Has None Of

Pricing

Quick Decision Guide

Links

Stop Skipping Email Verification in Your Automated Tests

The Pattern

Option 1: The CLI (Fastest for Local Dev and Scripts)

Option 2: The TypeScript SDK

Option 3: The Python SDK

Option 4: Playwright (Browser-Based Flows)

Option 5: Selenium (Python)

Option 6: OpenClaw AI Agent (Zero Code)

GitHub Actions — Parallel Jobs with Matrix Strategy

Handling Apps That Reject Disposable Domains

Approach Comparison

Links

Automating OTP Verification in Playwright Without Writing a Single Regex

The Core Problem

Setup

The Fixture — The Right Pattern for Playwright

Signup Test

Password Reset Test

Playwright Config — 4 Parallel Workers

Python Version

GitHub Actions

What About Apps That Block Disposable Domains?

What the OTP Command Looks Like (CLI debugging)

Links

How I Stopped Manually Clicking Verification Emails in My Selenium Tests

Why the Common Approaches All Break Eventually

The Setup

The Pattern That Works

Python + Selenium — Full Example

JavaScript + Selenium — Same Idea

What the OTP Output Actually Looks Like

Parallel Tests — This Is Where It Gets Good

GitHub Actions

What About Magic Links Instead of Numeric OTPs?

Plans and Pricing

Links

I Built the First Official CLI for a Disposable Email Service — Here's Why and How to Use It

The problem: email verification is the last manual step in automated pipelines

What is fce?

Install in one line

Login — browser-based, keychain-backed

fce dev — the command I use every single day

fce otp — no regex required

CI/CD — use FCE_API_KEY for headless environments

The full command surface

It also has a full REST API and official SDKs

Automation — AI agents, n8n, Make, Zapier

Pricing

Links

Stop Polling for OTPs — Use a Disposable Inbox API with Real-Time WebSocket Push

`fce dev` — the command I use every single day

`fce otp` — no regex required

CI/CD — use `FCE_API_KEY` for headless environments