Scheduled Sending

Scheduling reuses the send endpoint. Add scheduled_at to any normal send and the message is stored rather than transmitted. It goes out at the instant you named, anywhere from a few minutes to 30 days later.

The timestamp needs a timezone offset. A naive one is refused instead of guessed at. 09:00 alone does not say which moment you meant.

Settled at schedule time

Quota is charged and the body rendered once, when you schedule. What goes out three weeks later is the message you already composed and already paid for.

Recipients are the exception. Suppression and topic opt-out are re-checked at the due time. Someone who unsubscribes during the wait is not mailed. Freezing that up front would have been less work and would have sent mail to people who had asked you to stop.

Changing your mind

PATCH /scheduled-emails/{id} moves a send and DELETE cancels it. Both apply to a whole batch_id in one call, for the case that actually comes up: a launch slipping by a day. Cancelling is a soft delete: the status flips to canceled and the row survives.

Content is immutable once scheduled. Changing what a message says means cancelling and scheduling a new one. A batch_id is a grouping label of up to 64 characters rather than a bulk endpoint, and each message stays its own request.

Your first scheduled send

1. Add scheduled_at to a normal send, for example 2026-08-20T09:00:00+02:00
2. Optionally add a batch_id to group it with the rest of the campaign
3. Send over the REST API as usual. The response comes back scheduled, with the id you manage it by
4. List, reschedule or cancel any time before the due time, and watch for email.scheduled, email.sent and email.failed on your webhooks

Scheduled sending is on the paid plans. Without the entitlement, a send carrying scheduled_at is rejected with scheduling_not_included, and immediate sends are unaffected. See pricing for the plan list.