Email sandbox simulator
Email sandbox simulator for delivery tests
Trigger bounces before customers do. Send to simulator addresses, watch the recipient timeline, and verify webhook handlers without DNS, quota, or sender reputation at risk.
curl -X POST https://www.noticeapi.com/api/v1/email/send \
-H "Authorization: Bearer ntc_xxxxxxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"from": "[email protected]",
"to": "[email protected]",
"subject": "Bounce test",
"text": "Watch the delivery timeline."
}'
# -> { "ok": true, "provider": "noticeapi_simulator",
# "simulation": { "bounced": 1 } }Failure paths on demand
Use delivered, bounced, complained, and suppressed addresses when your app needs a specific delivery state.
Repeatable test addresses
Add +labels for local runs, CI smoke tests, and webhook fixtures without creating cleanup work.
No quota or reputation cost
Simulator traffic stays out of quota, sender reputation, metrics, and autopilot health math.
Real logs and webhooks
Recipient events are recorded and signed webhook callbacks fire through the same handler path your app uses later.
Simulator map
Pick the state your app needs to survive.
Use one recipient domain to create the exact delivery state your app needs to handle. Every address below is repeatable in local tests and CI.
Read simulator rules[email protected]
Create an accepted and delivered trail for happy-path assertions and webhook checks.
[email protected]
Exercise hard-bounce handling, webhook parsing, and retry decisions without poisoning a real address.
[email protected]
Trigger complaint-shaped events so your app can prove the abuse path before real recipient traffic.
How it works
Prove failure handling before production traffic.
Send from the sandbox domain
Use [email protected] with simulator recipients while production DNS is still untouched.
Pick the simulator outcome
Address the message to delivered@, bounced@, complained@, or [email protected].
Assert logs and webhooks
Fetch email status or listen for signed webhook events to verify your integration handled the outcome.
Keep test traffic isolated
Mixed real and simulator recipients return mixed_simulation, so test cases cannot leak into production sends.
Trust
A simulator is proof of your integration, not inbox placement.
Use simulator sends to prove request shape, recipient timelines, webhook parsing, and suppression handling. Production deliverability still starts with a verified sending domain and real recipient behavior.
Implementation links
Build with the shipped docs.
FAQ
Questions developers ask before switching email.
Does the simulator send real email?
No. It records delivery events and webhook callbacks inside NoticeAPI, but no message is delivered to a real mailbox.
Can I mix simulator and real recipients?
No. The API returns mixed_simulation when simulator recipients and real recipients are in the same send. That keeps tests isolated.
Can I use it in automated tests?
Yes. Simulator addresses are deterministic and repeatable, making them useful for local development, CI smoke tests, and webhook handler tests.
Do simulator bounces affect suppression lists?
No. Simulator events exercise suppression-shaped behavior without poisoning the simulator address or your account health.
Start in the sandbox, then send from a verified domain.
Free includes simulator testing and 3,000 emails per month. Real sending on Free needs operator activation plus a verified domain; Pro adds more volume, domains, contacts, automation runs, REST attachments, and visible usage billing.