Force a bounce. Catch the webhook. Never touch a real inbox.

Send to a simulator address and NoticeAPI writes back the outcome you asked for — through the same recipient timeline and signed webhooks your production code will read. No DNS to configure, no quota spent, no sender reputation on the line.

  1. 1
    Send from the sandbox domainUse [email protected] with simulator recipients while production DNS is still untouched.
  2. 2
    Pick the simulator outcomeAddress the message to delivered@, bounced@, complained@, or [email protected].
  3. 3
    Assert logs and webhooksFetch email status or listen for signed webhook events to verify your integration handled the outcome.
  4. 4
    Keep test traffic isolatedMixed real and simulator recipients return mixed_simulation, so test cases cannot leak into production sends.

Prove failure handling before production traffic.

  1. 1

    Send from the sandbox domain

    Use [email protected] with simulator recipients while production DNS is still untouched.

  2. 2

    Pick the simulator outcome

    Address the message to delivered@, bounced@, complained@, or [email protected].

  3. 3

    Assert logs and webhooks

    Fetch email status or listen for signed webhook events to verify your integration handled the outcome.

  4. 4

    Keep test traffic isolated

    Mixed real and simulator recipients return mixed_simulation, so test cases cannot leak into production sends.

One domain. Every delivery state your code must handle.

Each address produces one deterministic outcome you can assert against — and every one repeats the same way across local runs and CI.

Read simulator rules
Delivered

[email protected]

Create an accepted and delivered trail for happy-path assertions and webhook checks.

Bounced

[email protected]

Exercise hard-bounce handling, webhook parsing, and retry decisions without poisoning a real address.

Complaint

[email protected]

Trigger complaint-shaped events so your app can prove the abuse path before real recipient traffic.

Suppressed

[email protected]

Assert recipient_suppressed behavior without creating cleanup work.

The controls around the path.

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.

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.

Read the implementation.

Questions before you ship.

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.

Test it. Then send for real.

Simulator outcomes are free. Move to a verified domain when the path is ready.

Create your account Compare plans