Blueticks
Scheduled Messages

Schedule message

Send or schedule a WhatsApp message to the chat named in the URL path (`{chatId}` — a phone number in E.164 format, e.g. `+15551234567`, or a WhatsApp chat id like `12345@c.us` / `1234567890@g.us` / `12345@newsletter`).

Omit sendAt to send immediately; set it (RFC 3339, ≥10s and ≤365d in the future) to defer delivery.

The body is a FLAT object — set the type field to one of text, media, or poll; type selects which top-level fields are relevant.

Variants:

  • type: "text" — required text (1–4096 chars). A rich link-preview card is attached automatically when the text contains a URL. Example:
    curl -X POST "https://api.blueticks.co/v1/scheduled-messages/+15551234567" \
      -H "Authorization: Bearer $BLUETICKS_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{"type":"text","text":"hello"}'
  • type: "media" — provide the media as mediaUrl (HTTPS) or mediaBase64 (base64 / data: URL); mediaUrl wins if both are sent. The bytes are uploaded server-side and only a URL is sent on to the engine. Optional mediaKind (image · video · audio · document · sticker · voice · gif; auto-detected when omitted), text (caption), mediaFilename. You can also upload a file as multipart/form-data with the bytes in a mediaFile part.
  • type: "poll" — required pollQuestion and pollOptions (2–12 items). Optional pollAllowMultiple (default false).

All variants accept optional sendAt (defer) and replyTo (wire key of a prior message to quote). Pass an Idempotency-Key header to make retries safe (at most one send per key). Requires messages:write.

See Sending messages for runnable Python / Node / PHP / cURL examples per variant.

Request

curl -X POST "https://api.blueticks.co/v1/scheduled-messages/" \  -H "Content-Type: application/json" \  -d '{    "type": "text",    "text": ""  }'
POST
/v1/scheduled-messages/{chatId}

Path Parameters

chatId*string

Header Parameters

Idempotency-Key?string

Optional key for safe retries — guarantees a request runs at most once, so a network timeout + retry never double-sends. Reuse the same key to retry: an identical body replays the original response (HTTP 200 instead of 201, no second message); a different body with the same key returns 409 Conflict. Keys are scoped per workspace (max 64 chars). This is the request-level dedup control — distinct from the body secret field, which is only a correlation tag and does NOT prevent duplicate sends.

Lengthlength <= 64

Request Body

application/json

Response

Response Body

application/json

application/json

application/json