Documentation
Sign inGet started
Get started
Guides
API Reference
SDKs & CLI
Knowledge Base
Changelog

Scheduled sending

Preview — Scheduled sending is part of Bird's new email platform and is still in preview, not yet generally available. Supplying scheduled_at today returns 422 unsupported_feature. The behavior below is what's coming; the interface may change before launch.
Scheduled sending lets you hand a message to Bird now and have it delivered at a future time you pick, instead of holding it in your own scheduler until the moment to call the API. You set one field on the send; Bird stores the message and releases it into the normal delivery pipeline at the scheduled time.

The scheduled_at field

Add an RFC 3339 timestamp as scheduled_at on POST /v1/email/messages:
Code example
{
  "from": "news@yourdomain.com",
  "to": ["subscriber@example.com"],
  "subject": "Your weekly digest",
  "html": "<p>Here's what happened this week...</p>",
  "category": "marketing",
  "scheduled_at": "2026-07-01T09:00:00Z"
}
The send still returns 202 Accepted with an em_ message ID immediately — acceptance is synchronous, delivery is deferred. Omit scheduled_at (or send null) and the message goes out right away, exactly as it does today.

What stays the same

Scheduling changes when a message is released, not how it's built or governed. Everything else on the send behaves as documented:
  • Validation is up front. Field validation and the sender-domain check happen when you call the API, not at release time — a malformed scheduled send fails immediately with a 422, so you find out now, not at 9am.
  • Suppression is evaluated at release. Whether a recipient is suppressed is decided when the message is sent, against the list as it stands then — so a recipient who unsubscribes between scheduling and release is still honored.
  • Category and idempotency are unchanged. Set category: "marketing" for marketing mail as always, and an Idempotency-Key still makes the scheduling request safe to retry.

Scheduling a broadcast

Audience broadcasts carry their own scheduled_at to send to a whole audience at a future time, with the same preview status. A scheduled broadcast stays a draft until its time arrives and can be canceled before it sends.

Next steps