Free Verifier Bulk Verifier API Pricing
Tools
SPF/DKIM/DMARC Checker Fake Email Checker Domain Checker Disposable Checker Deliverability Checker
Sign Up Free

Email Verification Sandbox — Test API Without Credits

Everything you need to integrate email verification into your application.

Getting Started

The sandbox lets you test the API without consuming credits or making real SMTP connections. All results are simulated based on deterministic email patterns, perfect for development and CI/CD pipelines.

Enable by setting X-EV-Sandbox: true header or sandbox: true in any SDK config. Supports all endpoints including batch and webhooks. For production verification, visit our email verifier.

Code Example

// Enable sandbox mode
curl -X POST https://api.ev.ecomtechbd.com/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-EV-Sandbox: true" \
  -H "Content-Type: application/json" \
  -d '{"email": "valid-test@example.com"}'

// Sandbox patterns:
// valid*@*      -> deliverable
// invalid*@*    -> undeliverable
// risky*@*      -> risky
// catchall*@*   -> catch-all
// disposable*@* -> disposable
// role*@*       -> role-based
// Any other     -> random realistic result

// SDK usage
const verifier = new EmailVerifier({
  apiKey: 'YOUR_API_KEY',
  sandbox: true
});

Authentication & Setup

No special setup needed. Add X-EV-Sandbox: true to any request header, or set sandbox: true in the SDK config. Available on all plans including free. No credits consumed. Sandbox webhooks include sandbox: true flag.

Getting Started

The sandbox environment lets you test your email verification integration without consuming credits or making real SMTP connections. To enable sandbox mode, add the X-EV-Sandbox: true header to any API request, or set sandbox: true in any SDK's configuration. The sandbox is available on all plans, including the free tier, and requires no separate API key. All endpoints work identically in sandbox mode, including single verification, batch processing, webhooks, and history retrieval, making it perfect for development, staging, and CI/CD pipelines.

Sandbox results are deterministic and based on email address patterns. Emails starting with valid always return "deliverable," those starting with invalid return "undeliverable," risky returns a risky result, catchall returns a catch-all detection, disposable flags the address as disposable, and role marks it as a role-based address. Any email that does not match these prefixes returns a random but realistic result. Response times in sandbox mode are artificially fast (under 50ms) compared to production verification, which may take 2-10 seconds due to real SMTP probing. Use sandbox mode during development and automated testing, then remove the header or configuration flag when deploying to production.

Code Examples

Sandbox Verification via cURL

# Test a deliverable email
curl -X POST https://api.ev.ecomtechbd.com/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-EV-Sandbox: true" \
  -H "Content-Type: application/json" \
  -d '{"email": "valid-user@example.com"}'

# Response: {"status": "deliverable", "score": 95, ...}

# Test an undeliverable email
curl -X POST https://api.ev.ecomtechbd.com/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-EV-Sandbox: true" \
  -H "Content-Type: application/json" \
  -d '{"email": "invalid-bounce@example.com"}'

# Response: {"status": "undeliverable", "score": 0, ...}

# Test a disposable email
curl -X POST https://api.ev.ecomtechbd.com/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-EV-Sandbox: true" \
  -H "Content-Type: application/json" \
  -d '{"email": "disposable-temp@example.com"}'

# Response: {"status": "risky", "is_disposable": true, ...}

Sandbox Mode in SDK (Node.js)

import { EmailVerifier } from '@ev-ecomtechbd/node';

// Enable sandbox mode in the SDK configuration
const verifier = new EmailVerifier({
  apiKey: process.env.EV_API_KEY,
  sandbox: true  // No credits consumed, deterministic results
});

// Test different scenarios
const valid = await verifier.verify('valid-test@example.com');
console.log(valid.status);      // "deliverable"

const invalid = await verifier.verify('invalid-test@example.com');
console.log(invalid.status);    // "undeliverable"

const risky = await verifier.verify('risky-test@example.com');
console.log(risky.status);      // "risky"

// Batch also works in sandbox
const batchResults = await verifier.verifyBatch([
  'valid-a@example.com',
  'invalid-b@example.com',
  'catchall-c@example.com'
]);
batchResults.forEach(r => console.log(r.email, r.status));

Sandbox in Automated Tests (Python / pytest)

import pytest
from ev_verifier import EmailVerifier

@pytest.fixture
def verifier():
    return EmailVerifier(api_key='test-key', sandbox=True)

def test_valid_email(verifier):
    result = verifier.verify('valid-user@example.com')
    assert result.status == 'deliverable'
    assert result.score >= 80

def test_invalid_email(verifier):
    result = verifier.verify('invalid-bounce@example.com')
    assert result.status == 'undeliverable'
    assert result.score == 0

def test_disposable_email(verifier):
    result = verifier.verify('disposable-temp@example.com')
    assert result.disposable is True

def test_batch_verification(verifier):
    emails = ['valid-a@test.com', 'invalid-b@test.com']
    results = verifier.verify_batch(emails)
    assert len(results) == 2
    assert results[0].status == 'deliverable'
    assert results[1].status == 'undeliverable'

Error Handling

The sandbox environment simulates error responses so you can test your error handling code without triggering real failures. Use the email prefix error-auth to simulate a 401 authentication error, error-ratelimit to simulate a 429 rate limit response with a Retry-After header, error-timeout to simulate a request timeout, and error-server to simulate a 500 internal server error. These patterns let you verify that your application handles every error condition correctly before deploying to production.

When sandbox mode is enabled, all standard error handling behavior still applies. Your SDK's retry logic, timeout configuration, and exception types work identically to production. The only difference is that sandbox errors are triggered deterministically by email prefix patterns rather than by actual service conditions. Rate limit headers (X-RateLimit-Remaining, X-RateLimit-Reset) are included in sandbox responses with simulated values. Webhook deliveries in sandbox mode include a sandbox: true flag in the payload so your webhook handler can distinguish test events from production events. Use sandbox error simulation in your CI/CD pipeline to ensure your application degrades gracefully under all failure scenarios.

# Simulate authentication error
curl -X POST https://api.ev.ecomtechbd.com/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-EV-Sandbox: true" \
  -H "Content-Type: application/json" \
  -d '{"email": "error-auth@example.com"}'
# Returns: 401 {"error": "authentication_error", "message": "Invalid API key"}

# Simulate rate limit
curl -X POST https://api.ev.ecomtechbd.com/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-EV-Sandbox: true" \
  -H "Content-Type: application/json" \
  -d '{"email": "error-ratelimit@example.com"}'
# Returns: 429 {"error": "rate_limit", "retry_after": 60}

# Simulate server error
curl -X POST https://api.ev.ecomtechbd.com/v1/verify \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-EV-Sandbox: true" \
  -H "Content-Type: application/json" \
  -d '{"email": "error-server@example.com"}'
# Returns: 500 {"error": "server_error", "message": "Internal server error"}

Frequently Asked Questions

Set the X-EV-Sandbox: true header on any API request, or initialize the SDK with sandbox: true in the configuration. Sandbox requests return simulated results based on the email address pattern. No credits are consumed in sandbox mode.

The sandbox returns deterministic results based on email patterns: addresses starting with "valid" return deliverable, "invalid" returns undeliverable, "risky" returns risky, "catchall" returns catch-all, "disposable" returns disposable, and "role" returns role-based. Any other address returns a random realistic result.

Yes, sandbox mode supports webhooks. Submit a batch verification in sandbox mode and your configured webhook endpoint will receive simulated completion events. Use tools like webhook.site or ngrok to inspect the webhook payloads during development. Sandbox webhook payloads include a sandbox: true flag.

Start Verifying Emails Today

100 daily free verifications. No credit card required. Full API access on all plans. Visit our email verifier to get started.

Try Free Email VerifierView Pricing

Try our free email verifier — verify any email instantly, no signup required. Need bulk verification? Upload your list and clean thousands of emails in minutes.

Developers: integrate email verification into your app with our RESTful API — SDKs for 7 languages.

Free tools: SPF checker · DKIM checker · SMTP tester