Skip to main content

Documentation Index

Fetch the complete documentation index at: https://support.jetemail.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Scheduled Email

You can schedule a transactional email for future delivery by setting scheduledAt on the POST /email request. JetEmail holds the message until the requested time and then sends it through the same pipeline as an immediate send.

​
When to use it

Use scheduled sends for:
  • Reminders, drip messages, and follow-ups
  • Time-zone aware announcements
  • Any send where the trigger time is known in advance
For sends that need to fire immediately, simply omit scheduledAt.

​
Field reference

FieldTypeNotes
scheduledAtinteger or stringUnix seconds (UTC) or ISO 8601 / RFC 3339 with offset.
scheduled_at (snake_case) is also accepted as an alias. Limits
  • The time must be in the future.
  • The time must be no more than 30 days out.
  • A request that violates either rule returns 400 Bad Request.

​
Accepted formats

// ISO 8601 (UTC)
{ "scheduledAt": "2026-05-15T10:00:00Z" }

// ISO 8601 with offset
{ "scheduledAt": "2026-05-15T10:00:00-04:00" }

// Unix seconds (UTC)
{ "scheduledAt": 1762435200 }

​
Example request

curl -X POST https://api.jetemail.com/email \
  -H "Authorization: Bearer transactional_xxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "Your App <[email protected]>",
    "to": "[email protected]",
    "subject": "Reminder",
    "text": "This will arrive at the scheduled time.",
    "scheduledAt": "2026-05-15T10:00:00Z"
  }'

​
Example response

A scheduled send returns 202 Accepted (immediate sends return 201 Created): 
{
  "id": "0cd0f31f-1234-4abc-8def-1234567890ab",
  "response": "Scheduled as 0cd0f31f-... for 1762435200",
  "scheduled_at": 1762435200
}
The returned id is a scheduling UUID that identifies the queued message until it is dispatched.

​
Combining with idempotency

Scheduled sends work the same way as immediate sends with the Idempotency-Key header. Pairing the two is recommended for retried scheduling calls so a network blip does not produce a duplicate scheduled message.