/api/v1/email/sendAdd sendAt to the standard transactional payload.
Add sendAt to a normal transactional request. The email waits in NoticeAPI, stays visible to your app, and can be canceled or moved before sending begins.
renewal-user-8412One extra field
Keep the same endpoint and message. Add the future send time in sendAt, then reuse one stable retry reference from your app.
curl -X POST https://www.noticeapi.com/api/v1/email/send \
-H "Authorization: Bearer ntc_xxxxxxxxxxxxxxxxxxxx" \
-H "Idempotency-Key: renewal-user-8412" \
-H "Content-Type: application/json" \
-d '{
"from": "Acme <[email protected]>",
"to": "[email protected]",
"subject": "Your renewal reminder",
"sendAt": "<ISO_TIMESTAMP_UP_TO_30_DAYS_FROM_NOW>",
"html": "<p>Your subscription renews tomorrow.</p>"
}'Queue lifecycle
The message appears in your logs as soon as it is scheduled. Your app and support team can track it before it sends.
Use the normal send request with a date and time no more than 30 days away.
The returned email id resolves immediately, with its scheduled state and send time available to your app.
A scheduled message can be canceled or rescheduled any time before sending begins.
When due, NoticeAPI checks the current key, project, sender, recipient, and sending limit before delivery.
A controllable queue
The send response returns its id immediately. Use that same id to inspect state, cancel the message, or set a new valid time before it sends.
/api/v1/email/sendAdd sendAt to the standard transactional payload.
/api/v1/emails/:idRead the queued status, stored content, and scheduled time.
/api/v1/emails/:id/cancelStop a message while its status is still scheduled.
/api/v1/emails/:id/rescheduleReplace sendAt with another valid future timestamp.
Checked again before sending
Before the email leaves, NoticeAPI confirms the key can still send, the project and domain are active, the recipient is allowed, and the account has room to send. If anything changed while the message waited, it will not send.
Read scheduled-send behaviorSafe retries
Reuse the same retry reference with an identical request, and NoticeAPI returns the original scheduled send. Change the request while keeping that reference, and NoticeAPI rejects it.
renewal-user-8412sch_7f19a4Same scheduled idChanged request rejectedReady to queue it?
Add sendAt, keep the returned email id, and let the same NoticeAPI controls carry the message from queued to delivered.