Any send to POST /v1/send can be scheduled for later by adding a scheduled_at timestamp. The message is accepted immediately and persisted with status scheduled; Sendara dispatches it automatically once the time arrives. No cron, no queue of your own — you make one call and walk away.
Schedule a send
Pass scheduled_at as an RFC 3339 timestamp alongside the normal send fields. Everything else — idempotency, your verified From, templates — works exactly as it does for an immediate send.
curl https://api.sendara.dev/v1/send \
-H "Authorization: Bearer sk_live_xxx" \
-H "Content-Type: application/json" \
-d '{
"channel": "email",
"idempotency_key": "welcome_9f21",
"message_type": "transactional",
"destination": { "email": "[email protected]" },
"metadata": { "from_email": "[email protected]" },
"payload": { "subject": "See you Monday", "body_html": "<p>Reminder…</p>" },
"scheduled_at": "2026-06-20T14:00:00Z"
}'The response comes back with status scheduled and the message id you use to track or cancel it:
{
"id": "msg_7a3f9c",
"status": "scheduled",
"channel": "email",
"idempotency_key": "welcome_9f21",
"created_at": "2026-06-17T09:12:00Z"
}scheduled_at is excluded from the idempotency hash, so re-submitting the same logical send with the same idempotency_key returns the original scheduled message rather than creating a duplicate.When it is charged
A scheduled message is charged when it is dispatched, not when you schedule it — so usage reflects the month the email actually goes out, and the send respects the plan limits in force at that time. Verified test sends remain free.
Cancel a scheduled send
As long as the message has not been dispatched yet, you can cancel it. The row moves to status canceled and is never sent.
curl -X POST https://api.sendara.dev/v1/messages/msg_7a3f9c/cancel \
-H "Authorization: Bearer sk_live_xxx"{ "id": "msg_7a3f9c", "status": "canceled" }If the message has already been sent (or was never scheduled), the cancel returns 404 not_found — there is nothing to stop.
Timing & precision
Sendara sweeps for due messages continuously, so a scheduled send goes out within a short window of its scheduled_at— treat it as “at or shortly after” the requested time, not to-the-second. For very near-term sends (under a minute away) Sendara dispatches immediately instead of scheduling.
GET /v1/messages/{id} returns its status and, once it sends, the full delivery & open timeline.