DEV Community: Dishant Singh

Why Your Web Scraper Works Locally But Fails in Production (and How to Fix It)

Dishant Singh — Sun, 24 May 2026 18:49:47 +0000

When you build a web scraper locally it feels invincible. curl works, Playwright works, your Python script pulls data without a hitch. Then you deploy — and within minutes you see 403s, 429s, Cloudflare challenges, and blank pages.

This is the most common debugging trap in web scraping. The culprit is almost always your IP.

The local vs production gap

On your laptop you have a real residential IP — assigned by your home ISP, with years of browsing history behind it. Bot detection systems score it low risk. You look human.

In production you are almost certainly on AWS, GCP, Hetzner, or DigitalOcean. Those ASNs are public knowledge. Cloudflare, Akamai, and PerimeterX flag them automatically — before evaluating any other signal. Your perfectly crafted headers don't matter. The IP gives it away.

The fix: residential proxies

Residential proxies route traffic through real ISP-assigned IPs on home broadband connections. Bot detection sees a request from a real user in a real location, not a data center.

Key things to evaluate:

Pool size: larger = less reuse = less chance of hitting burned IPs. Under 10M is risky for serious work.
ASN type: must be genuine residential, not repackaged datacenter ranges relabeled "residential."
Sticky sessions: login flows and multi-step scraping need the same IP across requests.
Price: most enterprise providers charge $7-10/GB — brutal at scale.

What I use

After testing a few, I settled on v-proxies.com for most projects:

$0.99/GB — vs Bright Data ($8.40), Smartproxy ($7), Oxylabs ($8+)
84M+ residential IPs across 196+ countries, 5,000+ cities
Sticky sessions up to 60 minutes — encoded directly in the proxy username
Unlimited concurrency — no thread caps
99.97% uptime, avg response under 0.8s
Pay-as-you-go, credits never expire, $5 minimum to start

Proxy format:

# Rotating (new IP per request)
http://username:password@gate.v-proxies.com:9000

# City-targeted
http://username-country-us-city-new_york:password@gate.v-proxies.com:9000

# Sticky 30min session
http://username-session-abc123-sticky-30:password@gate.v-proxies.com:9000

Playwright example

from playwright.async_api import async_playwright

async def scrape(url):
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            proxy={
                "server": "http://gate.v-proxies.com:9000",
                "username": "username-country-us",
                "password": "your_password"
            }
        )
        page = await browser.new_page()
        await page.goto(url, wait_until="networkidle")
        content = await page.content()
        await browser.close()
        return content

Python requests example

import requests

proxies = {
    "http": "http://username-country-us:password@gate.v-proxies.com:9000",
    "https": "http://username-country-us:password@gate.v-proxies.com:9000"
}

response = requests.get("https://target-site.com", proxies=proxies)

Rule of thumb

Always test against the real target with production-equivalent proxies before you ship. The moment you introduce different IP types between dev and prod, you are setting yourself up for phantom failures that are miserable to debug.

At $0.99/GB there is no reason not to. A session that fetches 10,000 pages at ~200KB each uses roughly 2GB — that is $2.

Have you hit this local-vs-production gap? What helped you close it?

Virtual Phone Numbers for Developers: Complete API Guide 2026

Dishant Singh — Tue, 19 May 2026 06:34:00 +0000

Virtual Phone Numbers for Developers: Complete API Guide 2026

Virtual phone numbers aren't just a privacy tool — for developers, they're infrastructure. From integration testing to multi-account management to production SMS workflows, a reliable virtual number API is something every developer building with phone-based services eventually needs.

This guide covers everything: how virtual numbers work at the carrier level, what the API landscape looks like, and a practical reference for integrating them into your stack.

How Virtual Phone Numbers Work

A virtual phone number is a PSTN-routable number without a physical SIM. The carrier assigns a DID (Direct Inward Dial) number that routes to an internet endpoint instead of a handset.

SMS Sender → Mobile Carrier Network
                    ↓
            DID Routing Table
                    ↓
        Virtual Number Provider API
                    ↓
         Your Webhook / Dashboard

VoIP vs. Non-VoIP Numbers

This distinction matters enormously for verification use cases:

Type	How it works	Platform acceptance
VoIP	Internet-based (SIP/VoIP)	Blocked by Google, WhatsApp, Meta
Non-VoIP	Real SIM-backed carrier	Accepted everywhere

Services like Google Voice and Skype numbers are VoIP. NumberOTP provides SIM-backed non-VoIP numbers — which pass on platforms that reject VoIP.

Use Cases by Developer Type

Integration Testing

def test_phone_verification_flow():
    # Get a test number instead of hardcoding
    number_data = numberotp_client.get_number(country="us")

    # Trigger SMS verification in your app
    response = requests.post("/api/verify/send", json={
        "phone": number_data["number"]
    })
    assert response.status_code == 200

    # Verify the SMS was actually sent and received
    sms = numberotp_client.wait_for_sms(number_data["id"])
    assert "verification" in sms.lower()

    # Complete verification
    code = extract_otp(sms)
    complete = requests.post("/api/verify/confirm", json={"code": code})
    assert complete.status_code == 200

Multi-Account Management

Developers building tools that manage multiple accounts across platforms need unique, reliable phone numbers per account. NumberOTP's virtual numbers are private (not shared), so each account gets a distinct number.

Webhook-Driven SMS Workflows

// Express.js webhook endpoint
app.post('/webhook/sms', express.json(), (req, res) => {
  const { from, to, body, timestamp } = req.body;

  const handler = smsRoutes.get(to);
  if (handler) {
    handler({ from, body, timestamp });
  }

  res.status(200).json({ received: true });
});

NumberOTP API Reference

The NumberOTP API follows standard REST conventions. Base URL: https://numberotp.com/api

Authentication

All endpoints require an X-API-Key header:

X-API-Key: your_api_key_here

Core Endpoints

GET /numbers — Request a virtual number

curl -X GET "https://numberotp.com/api/numbers" \
  -H "X-API-Key: YOUR_KEY" \
  -G \
  --data-urlencode "country=us" \
  --data-urlencode "service=google"

Response:

{
  "id": "num_abc123",
  "number": "+12025551234",
  "country": "us",
  "service": "google",
  "expires_at": "2026-05-19T15:30:00Z",
  "credits_used": 0.10
}

GET /sms/{number_id} — Poll for incoming SMS

curl "https://numberotp.com/api/sms/num_abc123" \
  -H "X-API-Key: YOUR_KEY"

Response:

{
  "number_id": "num_abc123",
  "messages": [
    {
      "id": "sms_xyz789",
      "from": "+12125550000",
      "body": "Your Google verification code is 847291",
      "received_at": "2026-05-19T15:12:33Z"
    }
  ]
}

DELETE /numbers/{number_id} — Cancel / trigger refund

curl -X DELETE "https://numberotp.com/api/numbers/num_abc123" \
  -H "X-API-Key: YOUR_KEY"

Returns 200 with refund confirmation if no SMS was received.

Country Coverage Reference

Country	Code	Notes
United States	`us`	Widest service support
United Kingdom	`gb`	Good EU service support
India	`in`	Required for IN-only apps
Germany	`de`	Strong EU banking support
Canada	`ca`	US-adjacent coverage
Brazil	`br`	Large inventory

NumberOTP covers 150+ countries →

Comparing Virtual Number APIs

Provider	API Docs	Non-VoIP	Auto-Refund	Free Credits	Per-Use Pricing
NumberOTP	Full REST	Yes	Yes	$0.10	Yes
Twilio	Full REST	Yes	No	$15 trial	Monthly rental
5sim	Basic	Some	No	No	Yes
TextVerified	Yes	Yes	No	Limited	Yes

For verification use cases (one-time numbers, OTP testing): NumberOTP is the cleaner option — no monthly number rental, pay per use, auto-refund on failure.

For production inbound SMS infrastructure (permanent numbers, high volume): Twilio or Plivo are better suited.

TypeScript SDK Example

class SMSVerificationService {
  private baseUrl = 'https://numberotp.com/api';

  constructor(private apiKey: string) {}

  async getNumber(country = 'us', service = 'any'): Promise<{ id: string; number: string }> {
    const res = await fetch(
      `${this.baseUrl}/numbers?country=${country}&service=${service}`,
      { headers: { 'X-API-Key': this.apiKey } }
    );
    if (!res.ok) throw new Error(`API error: ${res.status}`);
    return res.json();
  }

  async waitForOTP(numberId: string, timeoutMs = 120000): Promise<string | null> {
    const deadline = Date.now() + timeoutMs;
    let interval = 3000;

    while (Date.now() < deadline) {
      await new Promise(r => setTimeout(r, interval));

      const res = await fetch(`${this.baseUrl}/sms/${numberId}`, {
        headers: { 'X-API-Key': this.apiKey }
      });
      const data = await res.json();

      if (data.messages?.length > 0) {
        const otp = data.messages[0].body.match(/\b(\d{4,8})\b/)?.[1];
        return otp ?? null;
      }

      interval = Math.min(interval * 1.5, 15000);
    }

    // Trigger refund on timeout
    await fetch(`${this.baseUrl}/numbers/${numberId}`, {
      method: 'DELETE',
      headers: { 'X-API-Key': this.apiKey }
    });
    return null;
  }
}

// Usage
const sms = new SMSVerificationService(process.env.NUMBEROTP_API_KEY!);
const { id, number } = await sms.getNumber('us', 'google');
console.log(`Use: ${number}`);
const otp = await sms.waitForOTP(id);
console.log(`OTP: ${otp}`);

Frequently Asked Questions

What is a virtual phone number API?

A virtual phone number API lets you programmatically request, manage, and receive SMS to temporary or permanent phone numbers without physical SIM cards. Services like NumberOTP expose REST endpoints that return real carrier numbers you can use for any SMS verification or inbound SMS workflow.

How do I get a non-VoIP number for Google verification via API?

Use a service that specifically provides SIM-backed non-VoIP numbers. NumberOTP guarantees this — VoIP numbers from standard telephony providers will fail Google's verification check.

What is the difference between a virtual number API and Twilio?

Twilio is a full-scale communications platform with long-term number rentals, voice, SMS, and many features. Virtual number APIs like NumberOTP are optimized for one-time verification use cases — lower cost per verification, no monthly number fees, and auto-refund if no SMS arrives.

Is there a free virtual phone number API?

Most services offer trial credits. NumberOTP gives $0.10 in free credits on signup. Twilio gives $15 in trial credits. There is no sustainably free unlimited API, but free-tier credits are sufficient for development testing.

Can virtual phone numbers receive calls as well as SMS?

It depends on the provider. Most SMS verification APIs (including NumberOTP) focus on inbound SMS only. For two-way voice and SMS, providers like Twilio and Plivo are more appropriate.

Conclusion

Virtual number APIs have matured significantly. For developers building anything that touches SMS verification — integration tests, automation pipelines, multi-account tools, or just testing your own OTP flow — the NumberOTP API is the fastest path to a working implementation.

Clean REST interface, real SIM-backed numbers, auto-refund on failure, and $0.10 free to try. Get your API key →

SMS OTP Verification in Python: Automate with Virtual Numbers

Dishant Singh — Tue, 19 May 2026 06:33:05 +0000

SMS OTP Verification in Python: Automate with Virtual Numbers

Manually entering OTP codes during development gets old fast. Whether you're running integration tests, automating account setups, or building a verification bypass for your own service, automating SMS OTP collection with Python turns a manual 2-minute process into a 10-second script.

This tutorial walks through a complete, production-ready SMS OTP collection system using the NumberOTP API — covering number acquisition, SMS polling, OTP extraction, and error handling.

Prerequisites

Python 3.8+
requests library (pip install requests)
A NumberOTP API key (free $0.10 credits on signup)

Architecture Overview

The flow has three stages:

1. Request a virtual number (country + service specific)
      ↓
2. Use that number for SMS verification on the target platform
      ↓
3. Poll the NumberOTP API for incoming SMS → extract OTP

The number is rented for a window (typically 20 minutes). If no SMS arrives, credits are auto-refunded.

Part 1: Setting Up the Client

import requests
import time
import re
import logging
from typing import Optional

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

API_KEY = "your_numberotp_api_key_here"
BASE_URL = "https://numberotp.com/api"

class NumberOTPClient:
    def __init__(self, api_key: str):
        self.api_key = api_key
        self.session = requests.Session()
        self.session.headers.update({"X-API-Key": api_key})

    def get_number(self, country: str = "us", service: str = "google") -> dict:
        response = self.session.get(
            f"{BASE_URL}/numbers",
            params={"country": country, "service": service}
        )
        response.raise_for_status()
        data = response.json()
        logger.info(f"Got number: {data['number']} (ID: {data['id']})")
        return data

    def get_sms(self, number_id: str) -> list:
        response = self.session.get(f"{BASE_URL}/sms/{number_id}")
        response.raise_for_status()
        return response.json().get("messages", [])

    def cancel_number(self, number_id: str) -> bool:
        response = self.session.delete(f"{BASE_URL}/numbers/{number_id}")
        return response.status_code == 200

Part 2: SMS Polling with Exponential Backoff

def wait_for_sms(
    client: NumberOTPClient,
    number_id: str,
    timeout: int = 120,
    initial_interval: float = 3.0,
    max_interval: float = 15.0
) -> Optional[str]:
    deadline = time.monotonic() + timeout
    interval = initial_interval
    attempt = 0

    while time.monotonic() < deadline:
        attempt += 1
        messages = client.get_sms(number_id)

        if messages:
            message = messages[0]["body"]
            logger.info(f"SMS received on attempt {attempt}")
            return message

        remaining = deadline - time.monotonic()
        sleep_time = min(interval, remaining)

        if sleep_time <= 0:
            break

        time.sleep(sleep_time)
        interval = min(interval * 1.5, max_interval)

    logger.warning(f"Timeout after {attempt} attempts")
    return None

Part 3: OTP Extraction

OTP formats vary by platform — 4 to 8 digit codes, sometimes with dashes. This handles the common patterns:

def extract_otp(message: str) -> Optional[str]:
    patterns = [
        r'(?:code|otp|pin|verification)[\:\s]+([A-Z0-9]{4,8})',
        r'\b(\d{6})\b',   # 6-digit numeric (most common)
        r'\b(\d{4})\b',   # 4-digit PIN
        r'\b(\d{5,8})\b', # 5-8 digit
    ]

    for pattern in patterns:
        match = re.search(pattern, message, re.IGNORECASE)
        if match:
            return match.group(1)

    return None

Part 4: Complete End-to-End Function

def get_sms_otp(
    country: str = "us",
    service: str = "google",
    timeout: int = 120
) -> Optional[str]:
    client = NumberOTPClient(API_KEY)
    number = None

    try:
        number = client.get_number(country=country, service=service)
        print(f"\nUse this number: {number['number']}")
        print("Waiting for SMS...\n")

        message = wait_for_sms(client, number["id"], timeout=timeout)

        if not message:
            logger.warning("No SMS received, cancelling number for refund")
            client.cancel_number(number["id"])
            return None

        otp = extract_otp(message)
        logger.info(f"Extracted OTP: {otp}")
        return otp

    except Exception as e:
        logger.error(f"Error: {e}")
        if number:
            client.cancel_number(number["id"])
        raise

# Usage
otp = get_sms_otp(country="us", service="google", timeout=120)
if otp:
    print(f"OTP: {otp}")
else:
    print("No OTP received (credits refunded)")

Service Codes Reference

Common service parameter values for the NumberOTP API:

Platform	Service Code
Google	`google`
WhatsApp	`whatsapp`
Telegram	`telegram`
Discord	`discord`
Amazon	`amazon`
Twitter/X	`twitter`
Instagram	`instagram`
Any platform	`any`

Integration with Playwright

Combining with browser automation:

from playwright.sync_api import sync_playwright

def automated_verification():
    client = NumberOTPClient(API_KEY)
    number = client.get_number(country="us", service="google")

    with sync_playwright() as p:
        browser = p.chromium.launch()
        page = browser.new_page()

        # Navigate to your verification page
        page.goto("https://example.com/verify")
        page.fill('[name="phone"]', number["number"])
        page.click('[type="submit"]')

        # Wait for SMS
        message = wait_for_sms(client, number["id"])
        otp = extract_otp(message)

        # Enter the OTP
        page.fill('[name="code"]', otp)
        page.click('[type="submit"]')

        browser.close()

    return otp

Frequently Asked Questions

What Python library works best for SMS OTP automation?

The requests library is sufficient for polling the NumberOTP API. For full automation including browser interaction, combine it with playwright or selenium. No specialized SMS library is needed when using a REST API like NumberOTP.

How do I handle rate limits when polling for SMS?

Use exponential backoff as shown in Part 2. Start at 3-second intervals and back off up to 15 seconds. Most OTPs arrive within 30 seconds of the SMS being sent.

Can I receive multiple SMS to the same virtual number?

Yes. The NumberOTP API supports receiving multiple messages to one number ID. The messages array contains all received SMS in order — useful for testing re-send flows.

What happens if the OTP SMS never arrives?

Cancel the number via the API (DELETE /numbers/{id}) to trigger auto-refund. Build this into your error handling as shown in the get_sms_otp function.

Is it legal to use virtual numbers for SMS verification?

Using virtual numbers for your own testing, development, and legitimate account management is legal. Creating fake accounts to defraud services or circumvent bans may violate terms of service and local laws. Always use virtual numbers responsibly.

Conclusion

SMS OTP automation in Python is straightforward once you have a reliable virtual number API. Get a SIM-backed non-VoIP number, poll for SMS with backoff, and extract the OTP with a robust regex pattern.

The NumberOTP API is the cleanest option for this workflow — real carrier numbers, auto-refund on failure, and a simple REST interface. Get your API key →

5sim Alternatives for SMS Verification in 2026

Dishant Singh — Tue, 19 May 2026 06:32:56 +0000

5sim Alternatives for SMS Verification in 2026

5sim.net is one of the most widely used SMS verification services, known for its wide country coverage and competitive pricing. But users switch away from it for a few common reasons: inconsistent number quality, some numbers pre-flagged by platforms, and customer support that's slow to respond when things go wrong.

If you're looking for 5sim alternatives — whether because of reliability issues, API needs, or just wanting to compare — here's a complete breakdown of what's available in 2026.

Why Developers Look for 5sim Alternatives

5sim has legitimate strengths: 180+ countries, low per-verification pricing, and a usable API. The main friction points reported by users:

Number quality inconsistency — some numbers return no SMS even when the platform sends it
No auto-refund guarantee — credits lost if number fails without obvious reason
Limited non-VoIP assurance — not all numbers in inventory are SIM-backed
Google/WhatsApp failures — strict platforms frequently reject 5sim numbers
Dashboard UX — functional but dated, especially for managing bulk workflows

Top 5sim Alternatives

1. NumberOTP — Best for Reliability + API

NumberOTP is a strong 5sim alternative with a key differentiator: all numbers are SIM-backed non-VoIP, and credits are auto-refunded if no SMS arrives within the window.

Feature	5sim	NumberOTP
Countries	180+	150+
Non-VoIP guaranteed	⚠️ Varies	✅ Always
Auto-refund	❌ No	✅ Yes
REST API	✅ Yes	✅ Yes
Free credits	❌ No	✅ $0.10
Google/WhatsApp success	⚠️ Mixed	✅ High

The auto-refund alone is worth the switch — with 5sim, a failed verification is a sunk cost. With NumberOTP, you get your credits back automatically.

Get started free →

2. SMS-Man

SMS-Man is a direct competitor to 5sim with similar pricing and country range. Their CIS and Eastern European inventory is strong. API is available and documented.

Good for: Russia, Ukraine, Kazakhstan, India numbers
API: Yes
Pricing: Comparable to 5sim
Auto-refund: No

3. TextVerified

TextVerified is more expensive than 5sim but has better quality control. Good for US numbers specifically.

Good for: US verifications where quality matters more than price
API: Yes
Pricing: $0.10–$5+ (higher than 5sim)
Non-VoIP: Yes (strong)

4. SMSPVA

SMSPVA has been in the market longer than 5sim and has a large bulk inventory. Pricing is competitive for high-volume buyers.

API: Yes
Countries: 60+
Best for: Bulk purchasing, established workflow

5. OnlineSIM

One of the oldest services in this category (since 2013). Solid reputation, consistent number quality, and good international coverage.

API: Yes
Countries: 100+
Pricing: Slightly higher than 5sim
Best for: Stability, long-term use

API Comparison for Developer Use

If you're automating SMS verification in code, the API quality matters as much as the numbers themselves.

NumberOTP API (Recommended)

import requests, time, re

API_KEY = "your_key"
BASE = "https://numberotp.com/api"

def get_otp(country="us", service="google"):
    # Get a number
    r = requests.get(f"{BASE}/numbers",
        params={"country": country, "service": service},
        headers={"X-API-Key": API_KEY})
    data = r.json()
    num_id = data["id"]

    # Wait for SMS
    for _ in range(24):  # 2 min timeout
        time.sleep(5)
        sms = requests.get(f"{BASE}/sms/{num_id}",
            headers={"X-API-Key": API_KEY}).json()
        if sms.get("messages"):
            msg = sms["messages"][0]["body"]
            otp = re.search(r'\b(\d{4,8})\b', msg)
            return otp.group(1) if otp else msg
    return None  # Auto-refund triggers

print(get_otp("us", "google"))

See full API documentation →

5sim API

5sim's API is similar in structure but lacks auto-refund. You also need to call a separate cancel endpoint to get any partial credit back on failed verifications — this needs to be built into your code manually.

Choosing Based on Your Use Case

High-volume, cost-sensitive automation

5sim or SMS-Man — lowest per-verification cost. Budget for ~15-20% failure rate.

One-time verifications where reliability matters

NumberOTP — auto-refund means you only pay for successful verifications. Works on Google, WhatsApp, Telegram.

US-only verifications, highest quality

TextVerified — premium pricing but strong US inventory.

Large-scale CIS market operations

SMS-Man or SMSPVA — specialized in Eastern European and CIS numbers.

Which Services Work for Google and WhatsApp?

Google and WhatsApp are the strictest verifiers. They check:

Whether the number is mobile-carrier registered (non-VoIP)
Whether the number block has a history of abuse
Whether the number was recently registered to too many accounts

Services with the highest success rates on these platforms:

NumberOTP — SIM-backed numbers, consistently passes Google/WhatsApp
TextVerified — strong for US numbers on these platforms
OnlineSIM — solid track record

5sim works for less strict platforms but has higher failure rates on Google and WhatsApp specifically.

Frequently Asked Questions

What is the best 5sim alternative?

For reliability and API quality, NumberOTP is the strongest 5sim alternative. It guarantees auto-refund on failed verifications, provides real SIM-backed non-VoIP numbers, and covers 150+ countries. For pure price competition, SMS-Man is comparable to 5sim.

Is 5sim safe to use?

5sim is generally safe for receiving SMS verifications. They've been operating since around 2017 and have a large user base. The main concern isn't safety — it's reliability. Numbers sometimes fail without explanation, and credits aren't automatically refunded.

What are the cheapest SMS verification services?

5sim and SMS-Man consistently offer the lowest per-verification pricing. However, factoring in failure rates, NumberOTP's auto-refund policy means you're only paying for what works — making the effective cost competitive even at a higher headline price.

Can 5sim numbers be used for Telegram verification?

It depends on the number. Some 5sim numbers work for Telegram, others are flagged. Services with guaranteed SIM-backed non-VoIP numbers (like NumberOTP) have more consistent success with Telegram, which is nearly as strict as WhatsApp.

Does 5sim have a free trial?

No, 5sim doesn't offer free credits. You need to deposit funds before purchasing numbers. NumberOTP offers $0.10 in free credits on signup, which is enough to test 2–3 verifications.

Final Thoughts

5sim is a solid service for high-volume, cost-sensitive workflows where occasional failures are acceptable. If you need higher reliability — especially for Google, WhatsApp, or Telegram — or want an API with auto-refund built in, NumberOTP is worth trying.

The $0.10 free credit is enough to test the full flow before committing. Start here →

TextVerified Alternatives in 2026: Best SMS Verification Services

Dishant Singh — Tue, 19 May 2026 06:31:55 +0000

TextVerified Alternatives in 2026: Best SMS Verification Services

TextVerified built a strong reputation for reliable non-VoIP SMS verification, but it's not the only game in town. Whether you're tired of their pricing, looking for better API support, or just want more country coverage, there are solid alternatives worth trying.

This guide compares the top TextVerified alternatives based on actual use — covering pricing, number quality, API support, and which services work for the hardest-to-verify platforms.

Why People Look for TextVerified Alternatives

TextVerified has genuine strengths: their numbers are real non-VoIP carrier lines, and they have a clean dashboard. But users frequently cite:

Limited country selection — strong on US, weaker internationally
Inconsistent availability — popular services (WhatsApp, Telegram) sell out fast
No batch/bulk API — built for one-off use, not automated pipelines
Pricing — US numbers for major platforms often run $1–3+

If any of those are friction points for your use case, the alternatives below are worth evaluating.

Top 8 TextVerified Alternatives

1. NumberOTP — Best for API & Multi-Country Coverage

NumberOTP is a strong TextVerified alternative if you need programmatic access or numbers from outside the US/UK.

Key differences from TextVerified:

REST API with full documentation — request numbers, poll for SMS, auto-refund if no SMS arrives
150+ countries — not just US/UK/CA
Pay-as-you-go — no subscription, credits don't expire
$0.10 free credits on signup

Numbers are SIM-backed non-VoIP, so they work on Google, WhatsApp, Discord, Meta, Telegram, and most strict verification platforms.

View pricing → | API docs →

2. SMS-Man

SMS-Man has good inventory across Eastern European and Asian numbers. Pricing is typically lower than TextVerified for non-US numbers. The dashboard is functional but not polished.

API: Yes (REST)
Country coverage: Good (Russia, Ukraine, India, etc.)
Non-VoIP: Yes for most numbers
Best for: Cheap numbers for non-US verifications

3. 5sim.net

5sim is a popular budget-friendly option, especially for Russian and CIS numbers. They have a large inventory and low prices per verification.

API: Yes
Country coverage: 180+ countries
Non-VoIP: Most numbers
Best for: Volume verifications at low cost

Weakness: Quality is inconsistent — some numbers are pre-used and may not receive SMS from certain platforms.

4. SMSPVA

SMSPVA focuses on high-volume buyers. They have bulk pricing and a wider inventory than TextVerified.

API: Yes (documented)
Country coverage: 60+ countries
Non-VoIP: Mostly yes
Best for: Bulk verifications, developers

5. OnlineSIM

OnlineSIM has been around since 2013 and has a solid reputation. Good country coverage and reliable numbers for major platforms.

API: Yes
Country coverage: 100+ countries
Non-VoIP: Yes
Best for: Stable, established service

6. Quackr

Quackr offers free shared public numbers alongside paid private ones. Good for quick throwaway verifications.

API: No
Country coverage: US, UK, Canada mainly
Non-VoIP: Some private numbers
Best for: Manual one-time verifications

7. GiveMeNumber

A smaller service with a limited but curated inventory. Prices are reasonable and reliability is good.

API: Basic
Country coverage: 30+ countries
Non-VoIP: Yes
Best for: Smaller use cases

8. MobileSMS.io

MobileSMS.io directly positions itself against TextVerified and has a similar model. Good US coverage and a cleaner UI than most alternatives.

API: Yes
Country coverage: US/UK focused
Non-VoIP: Yes
Best for: US verifications, TextVerified drop-in replacement

Feature Comparison Table

Service	API	Non-VoIP	Countries	Free Trial	Price Range
TextVerified	✅	✅	20+	⚠️ Limited	$0.10–$5+
NumberOTP	✅	✅	150+	✅ $0.10	$0.05–$1+
SMS-Man	✅	✅	100+	❌	$0.05–$2+
5sim	✅	✅	180+	❌	$0.03–$1+
SMSPVA	✅	✅	60+	❌	$0.10–$2+
OnlineSIM	✅	✅	100+	❌	$0.08–$2+
Quackr	❌	⚠️	US/UK	✅ Free (shared)	Free–$0.50
MobileSMS.io	✅	✅	15+	❌	$0.10–$3+

Which Alternative Is Best for Each Use Case?

Best for Google/WhatsApp verification

NumberOTP or OnlineSIM — both have verified non-VoIP SIM-backed numbers that pass Google's strict checks.

Best for low-cost bulk verifications

5sim or SMS-Man — lowest per-verification cost, good for high volume.

Best for API automation

NumberOTP — the cleanest REST API, auto-refund if no SMS arrives, and full documentation. See the API docs for a quick start.

Best TextVerified drop-in for US numbers

MobileSMS.io — similar model and pricing, US-focused inventory.

Best for international coverage

NumberOTP (150+ countries) or 5sim (180+ countries) — both beat TextVerified significantly on geographic range.

What Makes a Number "Work" for Verification?

Not all virtual numbers are equal. A number fails verification when:

It's a VoIP number — platforms like Google check if a number is a mobile carrier line vs. internet-based
It's been over-used — too many accounts created from the same number triggers platform blocks
It's from a blacklisted range — some number blocks are bulk-flagged across verification platforms

The safest choice is always a fresh, SIM-backed non-VoIP number from a reputable service. NumberOTP sources numbers from real carriers — not VoIP providers — which is why they work on Google, WhatsApp, and similar strict platforms.

Frequently Asked Questions

What is the best TextVerified alternative?

The best alternative depends on your needs. For API access and broad country coverage, NumberOTP is the strongest option. For cheap bulk US verifications, MobileSMS.io is a close TextVerified equivalent. For low-cost international numbers, 5sim or SMS-Man are worth trying.

Is TextVerified legit?

Yes, TextVerified is a legitimate SMS verification service with real non-VoIP numbers. Users' main complaints are limited country selection and premium pricing for popular platforms like WhatsApp and Telegram.

What is a non-VoIP number for SMS verification?

A non-VoIP number is a real mobile carrier number assigned to a physical SIM. These pass SMS verification on platforms that block VoIP numbers (like Google, WhatsApp, Discord). Most shared public number sites use VoIP, which is why they fail on these platforms.

How do I get around phone number verification?

Use a virtual phone number from a paid service that provides real SIM-backed numbers. Services like NumberOTP give you a real number from 150+ countries that you can use for any platform's SMS verification without giving out your personal number.

Why is TextVerified not working for WhatsApp?

WhatsApp is one of the strictest platforms for number verification. They block VoIP ranges and frequently re-scan numbers. If TextVerified's number fails, try a fresh number or switch to a service with a larger non-VoIP inventory like NumberOTP.

Conclusion

TextVerified is solid but not the only option. If you need better API support, more countries, or lower prices, NumberOTP is my top pick — real SIM-backed numbers, clean REST API, and $0.10 free to start. For cheap bulk verifications, 5sim and SMS-Man offer lower per-verification cost at some quality tradeoff.

Try NumberOTP free → — no credit card needed for the initial credits.

How to Receive SMS Online for Free: A Developer's Guide (2026)

Dishant Singh — Tue, 19 May 2026 06:31:54 +0000

How to Receive SMS Online for Free: A Developer's Guide (2026)

Whether you're testing a registration flow, bypassing a verification wall, or building a multi-account system, the ability to receive SMS online for free is one of those developer superpowers that saves hours of friction. But the landscape is crowded — between shared public number sites, paid APIs, and VoIP-blocked numbers, it's hard to know what actually works.

This guide breaks it all down. You'll see exactly how online SMS receiving works, which tools are genuinely free versus gimmicks, and how to integrate a real virtual number into your code.

What "Receive SMS Online" Actually Means

When you receive SMS online, you're using a virtual phone number — a number that exists in software, not a physical SIM. SMS sent to that number routes through a carrier to a web dashboard or API endpoint you control.

There are two main types:

Type	Who Sees Messages	Use Case
Shared public numbers	Anyone visiting the site	Throwaway verifications (low privacy)
Private virtual numbers	You only	OTP testing, account management, API automation

Shared public numbers (like receive-smss.com) are technically free but are burned fast — platforms like Google and WhatsApp detect and block them within days. Private numbers from services like NumberOTP cost a few cents but are real SIM-backed numbers that aren't blacklisted.

The Free Options: What Works and What Doesn't

Shared Public Number Sites

Sites like receive-smss.com and smsfree4me.com give you a number from a pool. The catch:

Everyone can see your SMS — including the OTP you're trying to use
Heavily blacklisted by Google, WhatsApp, Telegram, Discord, Amazon
Unreliable — numbers go offline without warning

These work for no-stakes, non-sensitive verifications only.

Free-Tier Private Number Services

Some services offer small credits on signup:

NumberOTP — $0.10 free credits, real non-VoIP SIM-backed numbers from 150+ countries. API available.
Twilio — Trial credits, but numbers cost $1/month + usage. Complex setup.
TextVerified — Limited free numbers, VoIP-heavy inventory

For most developers, $0.10 in free credits on NumberOTP buys 3–5 verifications, which is enough to test a flow end to end.

How to Receive an OTP SMS Online with the NumberOTP API

If you're automating, the NumberOTP API is the cleanest option. Here's a complete flow in Python:

Step 1: Get a Number

import requests

API_KEY = "your_numberotp_api_key"
BASE_URL = "https://numberotp.com/api"

# Get a US number for Google verification
response = requests.get(
    f"{BASE_URL}/numbers",
    params={"country": "us", "service": "google"},
    headers={"X-API-Key": API_KEY}
)

number_data = response.json()
phone_number = number_data["number"]
number_id = number_data["id"]

print(f"Got number: {phone_number}")

Step 2: Trigger the SMS (on the platform you're verifying)

Use the phone number wherever the verification form asks for it.

Step 3: Poll for the SMS

import time

def wait_for_sms(number_id, timeout=120):
    deadline = time.time() + timeout
    while time.time() < deadline:
        sms_resp = requests.get(
            f"{BASE_URL}/sms/{number_id}",
            headers={"X-API-Key": API_KEY}
        )
        messages = sms_resp.json().get("messages", [])
        if messages:
            return messages[0]["body"]  # The OTP is in here
        time.sleep(5)
    return None

otp_message = wait_for_sms(number_id)
print(f"Received: {otp_message}")

Step 4: Extract the OTP

import re

def extract_otp(message: str) -> str:
    match = re.search(r'\b(\d{4,8})\b', message)
    return match.group(1) if match else None

otp = extract_otp(otp_message)
print(f"OTP: {otp}")

This full flow works for any service that sends numeric OTP codes.

Node.js Version

const axios = require('axios');

const API_KEY = 'your_numberotp_api_key';
const BASE = 'https://numberotp.com/api';

async function getNumberAndWaitForSMS(country = 'us', service = 'google') {
  // Get number
  const { data: numberData } = await axios.get(`${BASE}/numbers`, {
    params: { country, service },
    headers: { 'X-API-Key': API_KEY }
  });

  console.log(`Got number: ${numberData.number}`);

  // Poll for SMS (up to 2 minutes)
  for (let i = 0; i < 24; i++) {
    await new Promise(r => setTimeout(r, 5000));
    const { data: smsData } = await axios.get(`${BASE}/sms/${numberData.id}`, {
      headers: { 'X-API-Key': API_KEY }
    });

    if (smsData.messages?.length > 0) {
      return smsData.messages[0].body;
    }
  }

  throw new Error('No SMS received within timeout');
}

getNumberAndWaitForSMS().then(console.log).catch(console.error);

Comparison: Free SMS Receiving Options for Developers

Service	Private?	API	Non-VoIP	Free Credits	Best For
receive-smss.com	❌ Public	❌ No	❌ No	Free (shared)	Throwaway only
NumberOTP	✅ Yes	✅ Full REST	✅ Yes	$0.10	Dev testing + automation
Twilio	✅ Yes	✅ Full	✅ Yes	Trial $15	Production SMS
TextVerified	✅ Yes	✅ Yes	⚠️ Mixed	Limited free	One-time verifications
Quackr	⚠️ Semi	❌ No	❌ Some	Free (shared)	Manual only

For automated testing workflows, NumberOTP hits the sweet spot — real numbers, REST API, and credits that don't expire.

Which Countries Work for SMS Verification?

Most major platforms verify against these country codes:

US (+1) — Works for Google, WhatsApp, Discord, Meta, Amazon
UK (+44) — Works for most EU-gated services
India (+91) — Required for Indian OTP-only apps
Germany (+49) — Works for banking-adjacent services

NumberOTP covers 150+ countries, so you can get the exact country code you need — without owning a SIM from that country.

Frequently Asked Questions

Can I receive SMS online for free without giving my real number?

Yes. Virtual number services let you receive SMS online using a temporary or dedicated number. Free shared number sites like receive-smss.com work for low-stakes verifications; for anything requiring privacy or automation, use a private service like NumberOTP.

Does receiving SMS online work for Google verification?

It depends on the number type. Shared public numbers are almost always blocked by Google. Real SIM-backed non-VoIP numbers from services like NumberOTP work reliably because they're actual carrier numbers, not internet-based VoIP lines.

What is the difference between VoIP and non-VoIP for SMS verification?

VoIP numbers (like those from Google Voice or Twilio's shared pool) are blocked by many platforms because they're easy to mass-create. Non-VoIP numbers are real SIM-based carrier numbers — these pass verification on Google, WhatsApp, and most other strict platforms.

Is there a free API to receive SMS online?

Most SMS APIs charge per message. NumberOTP gives $0.10 in free credits on signup — enough to receive 3–5 SMS messages. After that, numbers cost a few cents per message. There's no sustainably free unlimited SMS API.

How do I receive OTP online without a phone?

Use a virtual number service. Sign up at NumberOTP, pick a country and service, get a number, enter it where prompted, then read the incoming OTP from your dashboard or via the API. No phone required.

Can I automate SMS OTP collection with an API?

Yes. Services with REST APIs (like NumberOTP) let you request numbers, poll for incoming SMS, and extract OTP codes programmatically. See the Python example above for a working implementation.

Conclusion

For quick throwaway verifications, shared public number sites will do — but expect them to fail on Google, WhatsApp, and any platform that checks for VoIP. For developer workflows, API automation, or anything you need to actually work, invest the few cents per verification in a private, real SIM-backed number.

NumberOTP is the tool I use for all my SMS verification in testing pipelines. The API is clean, numbers arrive instantly, and credits are auto-refunded if no SMS arrives. View API docs →

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.