Skip to main content
POST /v1/emails returns 201 Created after Signal validates and accepts the request. That response is an admission result, not proof that the recipient server accepted the message.

​
The delivery checkpoints

A provider or receiving server can reject a message after the API request was accepted. That later outcome appears in the email status, timeline, metrics, event stream, or webhook flow.

​
Immediate sends

An accepted immediate send normally begins as queued. Signal processes it asynchronously and records later provider and recipient events. Use the returned email ID to retrieve the message and follow its timeline. When multiple direct to addresses are sent without cc or bcc, Signal fans out one message per recipient. The response contains a message result for each recipient, and each result can reach a different terminal state.

​
Scheduled sends

An accepted scheduled send begins as scheduled. The domain, project, quota, and suppression state can change before dispatch, so admission cannot guarantee the future provider outcome. Signal rechecks recipient suppression before a queued or scheduled message crosses the provider boundary.

​
Test mode

A test-mode request exercises Signal’s admission flow without delivering to real recipients. Its test outcome must not be used as delivery evidence.

​
The evidence to use

For one message, open Emails, select the message, and read its status, error, and timeline. For system integration, retrieve the email by ID or consume signed webhook events. Use the short-lived email event stream for live dashboard-style updates, not as a replacement for durable webhook handling.
Do not tell a customer that a message was delivered based only on 201, queued, or sent. Use delivered for recipient-server acceptance and describe that boundary precisely.