Test Mode

Use test mode to check your email request before production sending. Call the same POST /v1/messages endpoint and set options.test_mode to the boolean true. A successful test returns HTTP 200 with status: "validated" and creates no production queue job.

REST API only

Test mode is a REST API option. SMTP has no test mode; to try SMTP, send a message to an address you own.

An enabled endpoint is required

Test mode is a real authenticated API request. An administrator must provide the HTTPS endpoint and activate your current key and sending configuration. The read-only examples on Send Email provide code only; they do not perform this validation.

What test mode checks

A new test request follows the normal request and sender checks:

• A complete, active, unexpired workspace API key must be available in the endpoint's current configuration.
• API intake, workspace sending, and domain sending must be enabled.
• The exact sender domain must belong to that workspace and be verified and ready for sending.
• Headers, JSON syntax, field types, recipient addresses, attachment fields, and other message constraints must be valid.
• The request must fit within 1,000,000 UTF-8 bytes and the body upload deadline.
• The request-rate limits still apply, including additional traffic protection.

Use real request fields and valid address syntax. An unsupported feature, such as scheduling a send, still returns an error. The API does not check whether a recipient mailbox exists, render the email in an email client, or prove delivery through test mode.

Make a test request

Run this request from your backend. Replace YOUR_API_KEY with your full workspace API key, including its live_ prefix, as described in Authentication. Replace these sample addresses with your configured sender and test recipient:

curl --request POST 'https://api.sendmero.com/v1/messages' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "from": "Example App <hello@example.com>",
    "to": ["recipient@example.net"],
    "subject": "Welcome to Example App",
    "text": "Thanks for signing up. Your account is ready.",
    "options": { "test_mode": true }
  }'

Use the JSON boolean true, not the string "true". Omitting test_mode or setting it to false requests production submission.

Successful validation

HTTP 200:

{
  "id": "msg_00000000000000000000000000000001",
  "status": "validated",
  "recipients": [
    {
      "id": "rcpt_00000000000000000000000000000001",
      "address": "recipient@example.net",
      "status": "validated"
    }
  ]
}

The API generates the actual message and recipient IDs. Save the response if you need the validation result later; no message-status lookup is available.

validated means the applicable checks passed at that time. It does not reserve future sending permission or guarantee that a later production request will be accepted. Keys, domain readiness, limits, or configuration can change between requests.

Limits and accounting

Item	Test-mode behavior
Workspace request rate	Uses one request slot after the key and rate checks pass. The default is 1,000 requests per 10 seconds (100/second on average), shared across workspace API keys in each Cloudflare location; approximate window permitting bursts.
Daily production recipient allowance	No new allowance is reserved or consumed. A test therefore does not verify that enough production allowance remains.
Production queue	No email job is queued.
Result	The response contains the validation result and generated IDs; there is no lookup endpoint.
Repeated test POST	Creates a separate validation request with fresh IDs on success and uses another request slot.

Every POST is independent, even when the body is identical. Repeating a test with options.test_mode: true still creates no production send, but it does not retrieve the earlier result. Retain the original response to keep that result. See Rate Limits & Retries before repeating production requests.

Switch to production

1. Confirm that your administrator has enabled production submission for your workspace and domain.
2. Keep the intended sender, recipients, and email content, then omit options.test_mode or set it to false.
3. Submit the production request once. It must pass the current checks and have enough daily recipient allowance.
4. Save the result and fresh message and recipient IDs. If the result is uncertain, retain the available IDs and contact your administrator before another POST.

The earlier validation is not converted into a send. Each production POST is a new submission and can use its own recipient allowance, even when the message content matches an earlier test or production request. The API does not suppress repeated submissions.

Production success returns status: "accepted", confirming queued processing. Integrated delivery and delivery reporting remain outside this preview. See Send Email for the production response and Error Codes for rejected requests.