You can schedule any send to POST /v1/send. Add a scheduled_at timestamp. Sendara accepts the message immediately and stores it with status scheduled. Sendara dispatches it when the time arrives. You do not write a cron job and you do not run a queue.
Schedule a send
Pass scheduled_at as an RFC 3339 timestamp beside the normal send fields. The idempotency key, your verified sender, and your templates behave the same as they do 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 carries status scheduled and the message id. Use the id to track the message or to cancel it.
{
"id": "msg_7a3f9c",
"status": "scheduled",
"channel": "email",
"idempotency_key": "welcome_9f21",
"created_at": "2026-06-17T09:12:00Z"
}scheduled_at from the idempotency hash. If you submit the same send again with the same idempotency_key, Sendara returns the original scheduled message. It does not create a second message.When it is charged
Sendara charges a scheduled message at the moment of dispatch. Sendara does not charge it when you schedule it. Your usage therefore falls in the month of the send, and the send obeys the plan limits of that month. A verified test send stays free.
Cancel a scheduled send
You can cancel the message until Sendara dispatches it. The message moves to status canceled and Sendara never sends it.
curl -X POST https://api.sendara.dev/v1/messages/msg_7a3f9c/cancel \
-H "Authorization: Bearer sk_live_xxx"{ "id": "msg_7a3f9c", "status": "canceled" }The cancel returns not_found with status 404 when Sendara finds no scheduled message to cancel. Sendara already dispatched it, you already canceled it, or the id is unknown.
The precision of the dispatch
A scheduled message does not leave at the exact second you named. A Sendara job runs every 10 minutes. It claims the messages that are due and dispatches up to 200 of them in one pass, oldest first. Read scheduled_at as the earliest send time, not as the exact send time. Allow up to 10 minutes after it.
Sendara does not schedule a message that is less than 1 minute away. It dispatches that message now.
GET /v1/messages/{id} returns its status. After the send, it also returns the full delivery and open timeline.