{"id":2970,"date":"2026-09-18T12:44:08","date_gmt":"2026-09-18T07:14:08","guid":{"rendered":"https:\/\/www.smsgatewaycenter.com\/blog\/?p=2970"},"modified":"2026-09-18T12:44:11","modified_gmt":"2026-09-18T07:14:11","slug":"receiving-messages-four-channel-inbox-contracts","status":"publish","type":"post","link":"https:\/\/www.smsgatewaycenter.com\/blog\/receiving-messages-four-channel-inbox-contracts\/","title":{"rendered":"Receiving Messages on Four Channels: Inbox API Contracts Compared"},"content":{"rendered":"\n

SMS, WhatsApp, RCS and Telegram each deliver inbound messages differently. One pushes and cannot be read. Three can be read and never push. Here is every field, every type and every trap, compared side by side.<\/p>\n\n\n\n

\"Illustration<\/a>
Inbound messages arrive by push on one channel and by polling on three. The design that survives all four accommodates both.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h1>\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. The Four Inbound Surfaces at a Glance<\/a><\/li>\n\n\n\n
  4. Why SMS Is the Odd One Out<\/a><\/li>\n\n\n\n
  5. The SMS Inbound Push Contract<\/a><\/li>\n\n\n\n
  6. Receiving an SMS Reply Safely<\/a><\/li>\n\n\n\n
  7. The WhatsApp Inbox<\/a><\/li>\n\n\n\n
  8. The RCS Inbox<\/a><\/li>\n\n\n\n
  9. The Telegram Inbox<\/a><\/li>\n\n\n\n
  10. The Inbound Row, Field by Field<\/a><\/li>\n\n\n\n
  11. Four Identifier Namespaces, None of Them Shared<\/a><\/li>\n\n\n\n
  12. Threading a Reply to the Message That Caused It<\/a><\/li>\n\n\n\n
  13. Message Bodies and How They Are Encoded<\/a><\/li>\n\n\n\n
  14. Read State You Can Read but Cannot Write<\/a><\/li>\n\n\n\n
  15. Inbound Billing and Agent Attribution<\/a><\/li>\n\n\n\n
  16. Response Envelopes and the Error Shape<\/a><\/li>\n\n\n\n
  17. Designing One Inbound Table for Four Channels<\/a><\/li>\n\n\n\n
  18. The Polling Loop That Does Not Lose Messages<\/a><\/li>\n\n\n\n
  19. Four Language Samples, Four Different Traps<\/a><\/li>\n\n\n\n
  20. Ten Mistakes That Cost People Messages<\/a><\/li>\n\n\n\n
  21. Production Checklist<\/a><\/li>\n\n\n\n
  22. Unspecified Behaviour and How to Code Around It<\/a><\/li>\n\n\n\n
  23. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

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

    There are four inbound message surfaces on SMSGatewayCenter and they split two against two on transport. SMS delivers inbound messages by pushing an HTTP GET to a URL you supply, carrying six query parameters, and there is no endpoint anywhere that lets you read an SMS reply back. WhatsApp, RCS and Telegram each expose a read-only REST inbox at rest\/wa\/v1\/inbox<\/code>, rest\/rcs\/v1\/inbox<\/code> and rest\/tg\/v1\/inbox<\/code>, all GET, all action=list<\/code>, all paged on page<\/code> and limit<\/code> with a default of 50 and a maximum of 200, newest first, and none of the three pushes anything to you.<\/p>\n\n\n\n

    That split is the exact inverse of the delivery report split. SMS is the only channel with an outbound delivery push, and the account holds exactly one webhook slot for it. All four channels expose a delivery report poll. So SMS pushes what it will not serve and serves what it will not push, and the other three do the opposite.<\/p>\n\n\n\n

    The practical consequence is that you cannot write one inbound handler. You need a public HTTP endpoint that is idempotent against a payload carrying no identifier and no timestamp, and a scheduled poller that walks three paged REST inboxes on a cursor you persist yourself. Getting either half wrong loses customer replies silently, which is the worst failure mode a two-way integration has, because nothing errors and nobody complains until a sales lead goes cold.<\/p>\n\n\n\n

    \n\n\n\n

    TL;DR<\/h2>\n\n\n\n