{"id":3059,"date":"2026-10-02T11:15:52","date_gmt":"2026-10-02T05:45:52","guid":{"rendered":"https:\/\/www.smsgatewaycenter.com\/blog\/?p=3059"},"modified":"2026-10-02T11:19:34","modified_gmt":"2026-10-02T05:49:34","slug":"scheduling-messages-sms-whatsapp-rcs-telegram","status":"publish","type":"post","link":"https:\/\/www.smsgatewaycenter.com\/blog\/scheduling-messages-sms-whatsapp-rcs-telegram\/","title":{"rendered":"How to Schedule Messages on SMS, WhatsApp, RCS and Telegram (and Why You Still Need Your Own Scheduler)"},"content":{"rendered":"\n

You can schedule an SMS through the API and change your mind later. WhatsApp lets you book but never undo. RCS and Telegram don’t let you schedule at all. Here’s how each one really works, how to find out which time zone your timestamps land in, and how to build one scheduler that behaves the same on all four.<\/p>\n\n\n\n

\"Abstract<\/a>
Two channels can hold a schedule for you. All four need a clock you own.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h2>\n\n\n\n
    \n
  1. The Short Answer<\/a><\/li>\n\n\n\n
  2. TL;DR<\/a><\/li>\n\n\n\n
  3. What Each Channel Actually Lets You Do<\/a><\/li>\n\n\n\n
  4. Where Should the Schedule Live?<\/a><\/li>\n\n\n\n
  5. Scheduling an SMS, Start to Finish<\/a><\/li>\n\n\n\n
  6. One ID, Three Names<\/a><\/li>\n\n\n\n
  7. The Time Zone Problem<\/a><\/li>\n\n\n\n
  8. Finding the Time Zone With One Test Booking<\/a><\/li>\n\n\n\n
  9. WhatsApp: You Can Book It, but You Can’t Take It Back<\/a><\/li>\n\n\n\n
  10. RCS and Telegram: Bring Your Own Clock<\/a><\/li>\n\n\n\n
  11. Promotional Hours and Store and Forward<\/a><\/li>\n\n\n\n
  12. What Can Go Wrong While a Message Waits<\/a><\/li>\n\n\n\n
  13. The Cancel That Arrives Too Late<\/a><\/li>\n\n\n\n
  14. Putting It Together: A Hybrid Scheduler<\/a><\/li>\n\n\n\n
  15. The Schedule Table<\/a><\/li>\n\n\n\n
  16. Checking Your Schedule Against the Platform<\/a><\/li>\n\n\n\n
  17. Code: Four Samples, Four Gotchas<\/a><\/li>\n\n\n\n
  18. Which Path Should This Message Take?<\/a><\/li>\n\n\n\n
  19. Testing a Scheduler Without Waiting for the Clock<\/a><\/li>\n\n\n\n
  20. Before You Go Live<\/a><\/li>\n\n\n\n
  21. Unspecified Behaviour and How to Code Around It<\/a><\/li>\n\n\n\n
  22. FAQs<\/a><\/li>\n\n\n\n
  23. <\/li>\n<\/ol>\n\n\n\n

    The Short Answer<\/h2>\n\n\n\n

    SMS<\/a> is the only channel where the API lets you schedule a message and then change your mind. You add scheduleTime<\/code> to SMSApi\/send<\/code>, and later you can list it, move it or cancel it with the SMSApi\/schedule\/read<\/code>, update<\/code> and delete<\/code> endpoints.<\/p>\n\n\n\n

    WhatsApp will take a scheduletime<\/code> on WAApi\/send<\/code> (note the lower-case t, and no seconds), but that’s a one-shot deal. There’s no way to look at it, move it or cancel it afterwards. RCS and Telegram don’t accept a schedule time through the API at all.<\/p>\n\n\n\n

    So if your app has a “send later” button, you’re going to end up running your own scheduler anyway. The sensible setup is to keep every scheduled message in your own database, send RCS and Telegram yourself when the time comes, and only hand SMS over to the platform shortly before it’s due, once you’ve confirmed which time zone it reads your timestamps in.<\/p>\n\n\n\n

    Two other things will bite you if you don’t plan for them. The API never tells you what time zone it uses, but its read endpoint returns plain epoch timestamps, so one test booking is enough to find out. And if you send promotional SMS outside the allowed hours, the Store and Forward OWH setting can quietly hold it until the next morning.<\/p>\n\n\n\n

    TL;DR<\/h2>\n\n\n\n
    Question<\/th>Answer<\/th><\/tr><\/thead>
    Which channels can I schedule through the API?<\/td>SMS (scheduleTime<\/code> on SMSApi\/send<\/code>) and WhatsApp (scheduletime<\/code> on WAApi\/send<\/code>). RCS and Telegram can’t be scheduled through the API.<\/td><\/tr>
    Which ones can I change or cancel afterwards?<\/td>Only SMS, with SMSApi\/schedule\/read<\/code>, SMSApi\/schedule\/update<\/code> and SMSApi\/schedule\/delete<\/code>. Split campaigns move with SMSApi\/campaign\/update<\/code>.<\/td><\/tr>
    What format do they want?<\/td>SMS: YYYY-MM-DD HH:MM:SS<\/code>. WhatsApp: YYYY-MM-DD HH:MM<\/code>. Neither takes a time zone or offset.<\/td><\/tr>
    What do I get back when I read a booking?<\/td>uuId<\/code>, status<\/code>, total<\/code>, timestamp<\/code>, scheduledTimestamp<\/code>, lastupdatedTimestamp<\/code>, all as strings, times in epoch milliseconds.<\/td><\/tr>
    What’s the ID called?<\/td>Depends where you look: transactionId<\/code> when you send, uuid<\/code> when you update or delete, uuId<\/code> when you read. It’s the same value. Keep it as text.<\/td><\/tr>
    What time zone does it use?<\/td>Don’t assume. Book one test send, read it back, and compare.<\/td><\/tr>
    What about promotional hours?<\/td>Promotional and service-explicit SMS sent outside the posting window can be held until it reopens. Transactional SMS always goes straight out.<\/td><\/tr>
    Where should my schedule live?<\/td>In your own database. Treat the platform’s scheduler as a last-minute handoff for SMS.<\/td><\/tr>
    What should I check right before sending?<\/td>Balance, template status, sender ID, whether the person opted out, and whether anyone cancelled.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n

    What Each Channel Actually Lets You Do<\/h2>\n\n\n\n

    When you schedule anything, you need to know six things: can I book it, what format does it want, can I see it afterwards, can I move it, can I cancel it, and what ID do I use to do all that? Here’s how the four channels answer.<\/p>\n\n\n\n

    \"Table<\/a>
    Only the SMS paths have a full book, read, move and cancel lifecycle. WhatsApp is book-only. RCS and Telegram need your own clock.<\/figcaption><\/figure>\n\n\n\n
    Capability<\/th>SMS (quick, group, file)<\/th>SMS split campaign<\/th>WhatsApp<\/th>RCS<\/th>Telegram<\/th><\/tr><\/thead>
    Book a future send<\/td>scheduleTime<\/code> on SMSApi\/send<\/code><\/td>Created in the portal<\/td>scheduletime<\/code> on WAApi\/send<\/code><\/td>No API parameter<\/td>No API parameter<\/td><\/tr>
    Format<\/td>YYYY-MM-DD HH:MM:SS<\/code><\/td>n\/a<\/td>YYYY-MM-DD HH:MM<\/code><\/td>n\/a<\/td>n\/a<\/td><\/tr>
    Read back<\/td>SMSApi\/schedule\/read<\/code><\/td>SMSApi\/campaign\/read<\/code><\/td>No endpoint<\/td>Portal list only<\/td>n\/a<\/td><\/tr>
    Move<\/td>SMSApi\/schedule\/update<\/code> (uuid<\/code>, scheduletime<\/code>)<\/td>SMSApi\/campaign\/update<\/code> (campaignid<\/code>, scheduletime<\/code>)<\/td>No endpoint<\/td>Portal only<\/td>n\/a<\/td><\/tr>
    Cancel<\/td>SMSApi\/schedule\/delete<\/code> (uuid<\/code>)<\/td>SMSApi\/campaign\/delete<\/code><\/td>No endpoint<\/td>Portal only<\/td>n\/a<\/td><\/tr>
    Identifier<\/td>transactionId<\/code> -> uuid<\/code> -> uuId<\/code><\/td>campaignid<\/code> plus per-batch uuId<\/code><\/td>messageId<\/code><\/td>n\/a<\/td>n\/a<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    SMS is the easy one. You book it, you get an ID back, and with that ID you can look it up, move it or cancel it whenever you like. That’s what makes it safe to let the platform hold an SMS for you.<\/p>\n\n\n\n

    WhatsApp is the trap. Booking works fine, but the WhatsApp section of the API reference has sending, media, templates, reports, inbox and analytics, and nothing for schedules. Once you’ve sent scheduletime<\/code>, that message is going out at that time and there’s nothing you can do about it.<\/p>\n\n\n\n

    RCS<\/a> is a bit odd. You can schedule RCS campaigns in the portal, and the RCS scheduling help article<\/a> shows how to change or cancel them there. But RCSApi\/send<\/code> only takes sendMethod<\/code>, msgType<\/code>, format<\/code>, botId<\/code>, msg<\/code>, mobile<\/code> and an optional identifier<\/code>. No schedule time. Telegram<\/a>‘s rest\/tg\/v1\/send<\/code> is the same story. If you’re integrating through the API, both of them are send-now only.<\/p>\n\n\n\n

    Which means if you offer scheduling on more than one channel, you’re writing a scheduler. There’s no way around that. What you get to decide is how much of the actual sending you let the platform do.<\/p>\n\n\n\n

    \n\n\n\n

    Where Should the Schedule Live?<\/h2>\n\n\n\n

    You’ve got three options, and they each fail in their own way.<\/p>\n\n\n\n

    You can let the platform hold it. You submit the message now with a future time, and it goes out on schedule even if your whole stack is down. That’s genuinely useful: a bad deploy at 08:59 won’t make you miss a 09:00 reminder. The downside is that the message is now frozen. You can still move or cancel an SMS, but you can’t edit the text, and on WhatsApp you can’t do anything at all.<\/p>\n\n\n\n

    You can hold it yourself. Store it in your database and have a worker send it (without any schedule parameter) when it’s due. Now you can change the text, re-check consent and cancel right up to the last second, and the same code works for every channel. The cost is that if your worker is down at 09:00, the message is late.<\/p>\n\n\n\n

    Or you can do both, which is what we’ll build here. Your database is always the master copy. A little before an SMS is due, a worker hands it to the platform with scheduleTime<\/code>, saves the ID, and reads the booking back to make sure it’s right. If something changes after that, you call update or delete. RCS, Telegram, and any WhatsApp message someone might want to cancel never get handed off; your own worker sends them when they’re due.<\/p>\n\n\n\n

    Here’s how the three stack up:<\/p>\n\n\n\n

    <\/th>Platform holds it<\/th>You hold it<\/th>Both<\/th><\/tr><\/thead>
    Works on all four channels<\/td>No<\/td>Yes<\/td>Yes<\/td><\/tr>
    Still sends if your workers are down<\/td>Yes, on SMS and WhatsApp<\/td>No<\/td>Yes, once handed off<\/td><\/tr>
    Can edit the text after booking<\/td>No (cancel and rebook on SMS)<\/td>Yes<\/td>Yes, until handoff<\/td><\/tr>
    Can cancel right up to send time<\/td>SMS only<\/td>Yes<\/td>Yes, with delete after handoff on SMS<\/td><\/tr>
    Consent re-checked before sending<\/td>No<\/td>Yes<\/td>Yes, up to handoff<\/td><\/tr>
    One place to see everything scheduled<\/td>No, read is SMS-only and unfiltered<\/td>Yes<\/td>Yes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n

    Scheduling an SMS, Start to Finish<\/h2>\n\n\n\n

    Everything below hits https:\/\/unify.smsgateway.center\/<\/code>. Send the apikey<\/code> header with userid<\/code> on each call; the header works on every endpoint.<\/p>\n\n\n\n

    To book, POST to SMSApi\/send<\/code> exactly as you normally would (sendMethod<\/code>, mobile<\/code> or group<\/code>, msg<\/code>, senderid<\/code>, msgType<\/code>, output<\/code>) and add scheduleTime<\/code>. Both the quick and group send pages list it as “Date format YYYY-MM-DD HH:MM:SS”. The response looks just like a normal send:<\/p>\n\n\n\n

    {\n  \"status\": \"success\",\n  \"mobile\": \"919999999999\",\n  \"invalidMobile\": \"\",\n  \"transactionId\": \"6305583318236810379\",\n  \"statusCode\": \"200\",\n  \"reason\": \"success\"\n}<\/code><\/pre>\n\n\n\n
    Save that transactionId<\/code> straight away, as text. Without it you can’t move or cancel the message later. If your outbound message table<\/a> already keeps it for delivery reports, good, just make sure scheduled sends write it too.<\/p>\n\n\n\n
    To see what’s pending, call SMSApi\/schedule\/read<\/code> (POST or GET) with output=json<\/code>. You can’t filter it or page through it. It just returns everything:<\/p>\n\n\n\n
    {\n  \"response\": {\n    \"api\": \"schedule\",\n    \"action\": \"read\",\n    \"status\": \"success\",\n    \"msg\": \"success\",\n    \"code\": \"200\",\n    \"count\": 1,\n    \"scheduleList\": [\n      {\n        \"schedule\": {\n          \"uuId\": \"5718742519829975000\",\n          \"status\": \"pending\",\n          \"total\": \"1\",\n          \"timestamp\": \"1562974594713\",\n          \"scheduledTimestamp\": \"1564529760000\",\n          \"lastupdatedTimestamp\": \"0\"\n        }\n      }\n    ]\n  }\n}<\/code><\/pre>\n\n\n\n
    A couple of things to notice. Each row is wrapped in a schedule<\/code> object. count<\/code> is a real number, but total<\/code> (how many recipients) is a string. The three timestamps are epoch milliseconds, also as strings: timestamp<\/code> is when you booked it, scheduledTimestamp<\/code> is when it’ll go out, and lastupdatedTimestamp<\/code> of \"0\"<\/code> just means nobody has moved it yet. It’s not a date in 1970.<\/p>\n\n\n\n
    To move a booking, POST to SMSApi\/schedule\/update<\/code> with uuid<\/code>, the new scheduletime<\/code> (same format) and output<\/code>. The page says it’s POST only. You’ll get back \"msg\":\"Schedule time updated successfully.\"<\/code> with \"status\":\"success\"<\/code>.<\/p>\n\n\n\n
    To cancel, POST to SMSApi\/schedule\/delete<\/code> with uuid<\/code> and output<\/code>. You’ll get \"msg\":\"Schedule deleted successfully\"<\/code>.<\/p>\n\n\n\n
    Neither of those tells you what things look like afterwards, so read the list again and check. It’s one extra call, and it means you actually know the booking moved or disappeared instead of just trusting a success message.<\/p>\n\n\n\n
    Split campaigns<\/a>, where one booking goes out in several batches, work the same way but use campaignid<\/code>: SMSApi\/campaign\/read<\/code> (with campaignid<\/code>, optional uuid<\/code>, fromdate<\/code>, todate<\/code>), SMSApi\/campaign\/update<\/code> (campaignid<\/code>, scheduletime<\/code>) and SMSApi\/campaign\/delete<\/code>. You set those campaigns up in the portal, not through the API. The campaign splitting guide<\/a> goes deeper, and everything below about time zones and promotional hours applies to them as well.<\/p>\n\n\n\n
    \n\n\n\n
    One ID, Three Names<\/h2>\n\n\n\n
    This one catches people. The ID you use to manage a booking has a different name at every step:<\/p>\n\n\n\n
    Where<\/th>Name<\/th>JSON type<\/th>Example<\/th><\/tr><\/thead>
    SMSApi\/send<\/code> response<\/td>transactionId<\/code><\/td>quoted string<\/td>\"6305583318236810379\"<\/code><\/td><\/tr>
    SMSApi\/schedule\/update<\/code> and \/delete<\/code> request<\/td>uuid<\/code><\/td>form field<\/td>uuid=83147103413249843<\/code><\/td><\/tr>
    SMSApi\/schedule\/read<\/code> response<\/td>uuId<\/code><\/td>quoted string<\/td>\"5718742519829975000\"<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    It’s the same value every time. The easiest way to stay sane is to give it one name in your own code (something like provider_txn_id<\/code>) and only deal with the three API spellings inside the bits of code that talk to the API.<\/p>\n\n\n\n
    The other thing: never let it become a number. These IDs can be nineteen digits. A double can only store whole numbers exactly up to 2^53, which is sixteen digits, so anything longer gets rounded. Push \"6305583318236810379\"<\/code> through a JavaScript Number<\/code> or a Python float<\/code> and you get 6305583318236810240. Try to cancel with that and you’ll be cancelling something that doesn’t exist, while the real message goes out on time. The API sends these as quoted strings, so this only happens if your own code converts them: a stray parseInt<\/code>, a BIGINT<\/code> column in a language that maps it to a double, or a round trip through Excel. Store them as text, compare them as text, and you’re fine.<\/p>\n\n\n\n
    \n\n\n\n
    The Time Zone Problem<\/h2>\n\n\n\n
    When you send 2026-10-05 09:30:00<\/code>, you’re sending a clock reading, not a moment in time. 09:30 where? The API doesn’t take an offset, so the server decides.<\/p>\n\n\n\n
    The RCS scheduling help article<\/a> mentions that the portal shows times “in your account’s time zone” and that the update screen shows “the current server time” for reference. So there are at least two clocks around, and nothing tells you which one the API uses for your timestamp.<\/p>\n\n\n\n
    If your account is in India, it’s almost certainly IST (UTC+05:30) and you’d probably be fine guessing. But don’t bake that guess into your code, because:<\/p>\n\n\n\n
      \n
    1. If you’re wrong, everything is off by five and a half hours. Your 09:00 reminder lands at 14:30, or, if you’re wrong the other way, your promotional blast goes out at 03:30 and runs straight into restricted hours.<\/li>\n\n\n\n
    2. Your servers are probably on UTC. Somebody writes datetime.now() + timedelta(hours=2)<\/code>, gets a UTC clock time, and it works fine on their laptop in Bengaluru and breaks in production.<\/li>\n\n\n\n
    3. Not every account is in India, and an account’s zone setting won’t always match the default.<\/li>\n<\/ol>\n\n\n\n
      Luckily you don’t have to guess. The read endpoint gives you back epoch milliseconds, which don’t have a time zone. Compare that with what you sent and you know exactly how your timestamp was read.<\/p>\n\n\n\n
      \n\n\n\n
      Finding the Time Zone With One Test Booking<\/h2>\n\n\n\n
      You only need to do this once per account, and again if someone changes the account’s settings.<\/p>\n\n\n\n
      Step one: book a test send.<\/strong> Pick a number you own, a transactional template, and a time at least a day away at an easy-to-spot minute, say 2026-10-09 11:17:00<\/code>. Note exactly what you sent and the transactionId<\/code> you got back.<\/p>\n\n\n\n
      Step two: read it back.<\/strong> Call SMSApi\/schedule\/read<\/code>, find the row whose uuId<\/code> matches your transactionId<\/code> (compare them as strings), and take its scheduledTimestamp<\/code>.<\/p>\n\n\n\n
      Step three: see which zone matches.<\/strong> Convert your timestamp to epoch milliseconds as if it were UTC, then as if it were Asia\/Kolkata, and any other zone you suspect. One of them will match what came back.<\/p>\n\n\n\n
      Step four: save it and clean up.<\/strong> Store the zone against the account, cancel the test with SMSApi\/schedule\/delete<\/code>, and read once more to make sure it’s gone.<\/p>\n\n\n\n
      from datetime import datetime\nfrom zoneinfo import ZoneInfo\n\ndef epoch_ms(wall: str, tz: str) -> int:\n    dt = datetime.strptime(wall, \"%Y-%m-%d %H:%M:%S\").replace(tzinfo=ZoneInfo(tz))\n    return int(dt.timestamp() * 1000)\n\ndef infer_zone(sent_wall: str, returned_ms: str, candidates: list[str]) -> str | None:\n    target = int(returned_ms)            # quoted string on the wire; parse locally only\n    for tz in candidates:\n        if epoch_ms(sent_wall, tz) == target:\n            return tz\n    return None                          # no match: stop and investigate, do not default\n\nzone = infer_zone(\"2026-10-09 11:17:00\", \"1791524820000\",\n                  [\"UTC\", \"Asia\/Kolkata\"])<\/code><\/pre>\n\n\n\n
      If nothing matches, don’t just fall back to IST. Either you grabbed the wrong row or the platform is using a zone you didn’t think of, and you want a human to look at that before real customers get scheduled messages.<\/p>\n\n\n\n
      To give you something to check against: 2026-10-09 11:17:00<\/code> in IST is 1791524820000<\/code>. If you get 1791544620000<\/code> back, the platform treated it as UTC.<\/p>\n\n\n\n
      You can’t do this on WhatsApp because there’s nothing to read back. Use the zone you found for SMS, then send yourself one scheduled WhatsApp message and check when it actually arrives on your phone.<\/p>\n\n\n\n
      \n\n\n\n
      WhatsApp: You Can Book It, but You Can’t Take It Back<\/h2>\n\n\n\n
      WAApi\/send<\/code> has an optional scheduletime<\/code> field. The docs describe it as “Add your schedule Timestamp in YYYY-MM-DD HH:MM format” and give 2026-10-03 07:13<\/code> as the example. Three things are different from SMS.<\/p>\n\n\n\n
      The name is all lower case. SMS uses scheduleTime<\/code>, WhatsApp uses scheduletime<\/code>. If you have one shared helper for both, one of them is getting the wrong parameter. Keep a small adapter per channel that knows its own field names, which is what the WhatsApp wire contract guide<\/a> recommends for that endpoint in general.<\/p>\n\n\n\n
      There are no seconds. If your message is due at 09:29:40 and you format it as %H:%M<\/code>, you’ll send 09:29<\/code> and it goes out twenty seconds early. Usually nobody cares. But if you’ve promised a sale opens at 09:30 sharp, or you’re right at the edge of quiet hours, round up to the next minute instead. Write that down in the code, because every date library truncates by default and someone will “fix” it later.<\/p>\n\n\n\n
      And you can’t undo it. The response gives you status<\/code>, messageId<\/code>, mobile<\/code>, a numeric statusCode<\/code> and a description<\/code>, and that’s the end of your involvement. There’s no endpoint to look it up, move it or cancel it. If the customer changes their mind, the template gets paused, or the recipient opts out in the meantime, the message still goes.<\/p>\n\n\n\n
      So only use WhatsApp’s scheduletime<\/code> when:<\/p>\n\n\n\n