Schedule an SMS

Set sending_type: "scheduled" and pass a scheduled_dates array. Each entry is a (date, time) pair in the merchant’s configured timezone. The gateway accepts up to 20 dates per request.

Single future moment

curl $BASE_URL/api/v1/lisoloo/sms-api/send \
  -X POST \
  -H "app-key: $LISOLOO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["+243998857000"],
    "message": "Your appointment is tomorrow at 09:00.",
    "sender_id": "CLINIC",
    "sending_type": "scheduled",
    "scheduled_dates": [
      { "date": "2026-06-01", "time": "08:00" }
    ]
  }'

requests.post(SEND_URL, headers=HEADERS, json={
    "to":        ["+243998857000"],
    "message":   "Your appointment is tomorrow at 09:00.",
    "sender_id": "CLINIC",
    "sending_type": "scheduled",
    "scheduled_dates": [
        {"date": "2026-06-01", "time": "08:00"},
    ],
}).raise_for_status()

await fetch(SEND_URL, {
  method: "POST",
  headers: HEADERS,
  body: JSON.stringify({
    to: ["+243998857000"],
    message: "Your appointment is tomorrow at 09:00.",
    sender_id: "CLINIC",
    sending_type: "scheduled",
    scheduled_dates: [
      { date: "2026-06-01", time: "08:00" },
    ],
  }),
});

Multiple moments

Each entry in scheduled_dates is a separate dispatch. The example below sends the same message twice — morning and evening reminder.

{
  "to": ["+243998857000"],
  "message": "Don't forget to take your medication.",
  "sending_type": "scheduled",
  "scheduled_dates": [
    { "date": "2026-06-01", "time": "08:00" },
    { "date": "2026-06-01", "time": "20:00" },
    { "date": "2026-06-02", "time": "08:00" },
    { "date": "2026-06-02", "time": "20:00" }
  ]
}

This produces 4 dates × 1 recipient = 4 SMS, billed up-front.

Cost is reserved at submit time

The full total_cost for every scheduled dispatch is deducted from your balance immediately when POST /send returns 201. If your balance later drops below the reserved amount (because of other sends), the scheduled dispatches still go out — the reserve is sticky.

Timezone semantics

date and time are interpreted in the merchant timezone configured on your account (default: Africa/Kinshasa, UTC+1). To send at a specific UTC moment, do the conversion on your side before submit.

If the merchant timezone observes DST, ambiguous times (the “fall-back” hour) are resolved as the first occurrence. The “spring-forward” gap (e.g. 02:30 on a DST-spring day that doesn’t exist) is rejected with 1110 INVALID_FIELD_FORMAT.

What you can’t do

Mix sending_type: "scheduled" with recurring_schedule. Pick one.
Schedule more than 20 (date, time) pairs in one request. Use recurring for higher cadences.
Schedule a date in the past. Past entries are rejected at submit.