Test mode

Test mode runs a send through every check a real send goes through, then stops before the message reaches a mail server. Nothing is delivered, nothing is charged, and your sending reputation is untouched.

There are two ways in, and they compose.

Test keys

A key created in the test environment is prefixed tix_test_ and can never send real mail. Use it in CI, in local development, and anywhere you would rather not hand out a credential that can reach your customers.

Authorization: Bearer tix_test_...

A test key is not a weaker live key. It is a separate world:

• Sends are simulated. No message leaves the platform.
• Nothing counts against your daily or monthly send allowance.
• It reads only test data. Listing or fetching a live message with a test key returns not_found, so a leaked test key cannot read production mail.
• It can only create further test keys. Asking for a live key returns test_mode_restricted.
• It has its own rate-limit allowance, so a load test cannot starve production.

Everything else behaves normally. An unverified sending domain still fails, a malformed from still fails, an oversized attachment still fails. That is the point: test mode is useful precisely because it does not skip validation.

Sandbox addresses

Any recipient at epostix.dev is simulated, and you choose the outcome with the local part.

Recipient	What happens
[email protected]	Accepted and delivered
[email protected]	Rejected as a hard bounce
[email protected]	Delivered, then marked as spam
[email protected]	Blocked before sending
[email protected]	Deferred, then delivered

Each accepts a +label suffix, so [email protected] and [email protected] are distinct messages. Use labels in loops: without them you will trip duplicate detection on the eleventh identical send inside a minute.

Any other local part at that domain is rejected with a validation_error listing the ones that work, rather than quietly defaulting to delivered.

Sandbox addresses work with live keys too. A live key sending to [email protected] produces a simulated bounce: no delivery, no quota, no effect on reputation, and no suppression written to your account. That is how you exercise your bounce handling against your real production credentials.

Webhooks fire either way

Simulated sends emit the same events as real ones, in the same order, with the same payload shape. [email protected] produces email.sent and then email.bounced, and your endpoint cannot tell the difference except that the message never arrived anywhere.

This is the reason to use sandbox addresses rather than mocking our API: you are testing your own webhook handler against real deliveries of real payloads.

Telling them apart afterwards

Every message carries a mode field, either live or test, so a simulated send is identifiable long after it was made.

{
  "id": "...",
  "mode": "test",
  "status": "delivered"
}

What test mode does not cover

SMTP submission is always live. SMTP credentials have no test variant, so a message sent through smtp.epostix.com is a real send whatever else you have configured. Use the API when you want a simulated send.