
The short answer: add the send_at field to the request, with the date and time in ISO 8601 including the time zone, up to 30 days ahead. Credits are only taken when the e-mail goes out. To change your mind, call POST /v1/email/messages/{id}/cancel before that time.
When scheduling makes sense
| Situation | Example |
| A reminder before a deadline | The invoice is due on Friday: schedule the reminder for Wednesday morning |
| Out of hours | An order placed at midnight: the confirmation goes at once, but the satisfaction survey can wait until the next day |
| A set date | The notice that a plan ends, the day before |
How to write the date
Use ISO 8601 with the time zone at the end, as in the documentation example: 2026-11-20T09:30:00+02:00. The +02:00 is the zone of that example; use your customer’s. Without the zone, the time is ambiguous.
"send_at": "2026-11-20T09:30:00+02:00"
| Error reason | What to fix |
| invalid_send_at | The date is not ISO 8601 with a time zone |
| send_at_in_past | The date has passed. To send now, leave out send_at |
| send_at_too_far | The date is too far ahead: the most is 30 days |
Cancelling
|
|
|
Only scheduled e-mails that have not gone out can be cancelled. After that, the API answers 409 with the reason not_cancellable.
| The balance is checked again when it is time to send. If there are not enough credits then, the e-mail does not go out and becomes failed, with the error insufficient_credits. Credits held for scheduled e-mails show in scheduled_credits, in GET /v1/email/balance. |
| Cancel when the reason goes away. If the customer pays before the reminder, your system cancels the scheduled reminder. Nobody likes a payment reminder after paying. |
|
Want to automate e-mail reminders at the right time? See the API page. See the API page |
RECOMMENDED PRODUCT Professional e-mail on your domain Mailboxes in your company name, no adverts, with spam filtering. from KSh858.00/mo (3-year plan, with coupon) See plans |











