{"id":3128,"date":"2026-10-30T08:41:51","date_gmt":"2026-10-30T03:11:51","guid":{"rendered":"https:\/\/www.smsgatewaycenter.com\/blog\/?p=3128"},"modified":"2026-10-30T08:41:54","modified_gmt":"2026-10-30T03:11:54","slug":"rcs-rich-cards-carousels-content-model-validation","status":"publish","type":"post","link":"https:\/\/www.smsgatewaycenter.com\/blog\/rcs-rich-cards-carousels-content-model-validation\/","title":{"rendered":"RCS Rich Cards and Carousels as a Content Model: Validate, Version and Send Cards Without Surprises"},"content":{"rendered":"\n

RCS rich cards and carousels look like design work, but they behave like a data model with hard limits, an approval clock and no update call. Here’s how to model cards in your own system, validate them the way the device counts, version them by template name, read them back from RCSApi\/template\/list<\/code>, and match button taps to the exact send.<\/p>\n\n\n\n

\"Abstract<\/a>
A carousel is a list of cards with hard limits, and every button tap is a message coming back.<\/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. Four Template Types and What Each One Is For<\/a><\/li>\n\n\n\n
  4. The Limits That Actually Bind<\/a><\/li>\n\n\n\n
  5. What the Platform Hands Back<\/a><\/li>\n\n\n\n
  6. Your Own Card Model: Store Intent, Not Wire JSON<\/a><\/li>\n\n\n\n
  7. Counting Characters the Way the Limit Counts<\/a><\/li>\n\n\n\n
  8. Template Names Are Your Version Numbers<\/a><\/li>\n\n\n\n
  9. Variables Across Titles, Buttons and URLs<\/a><\/li>\n\n\n\n
  10. Postbacks as a Tiny Grammar<\/a><\/li>\n\n\n\n
  11. The Media Pipeline: Ratios, Sizes and Thumbnails<\/a><\/li>\n\n\n\n
  12. Carousels: Order, Height and Truncation<\/a><\/li>\n\n\n\n
  13. The Approval Lifecycle and the Integer Status<\/a><\/li>\n\n\n\n
  14. One Model, One Fallback Text<\/a><\/li>\n\n\n\n
  15. Working Code: Validator, Read-Back Parser and Postback Matcher<\/a><\/li>\n\n\n\n
  16. Four Traps in Four Languages<\/a><\/li>\n\n\n\n
  17. Decision Matrix: Card, Carousel, Media or Text<\/a><\/li>\n\n\n\n
  18. From Model to First Send in Seven Steps<\/a><\/li>\n\n\n\n
  19. Pre-Submit Checklist<\/a><\/li>\n\n\n\n
  20. Unspecified Behaviour and How to Code Around It<\/a><\/li>\n\n\n\n
  21. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

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

    Treat every RCS rich card and carousel as a record in your own system, not as JSON you hand-craft for each campaign. Keep one card model (titles, descriptions, media, buttons, variables, postback prefixes), validate it against the platform’s limits before you submit, give each version its own template name, create it with RCSApi\/template\/create<\/code>, read it back with RCSApi\/template\/list<\/code> and diff what was stored against what you meant, and only send with RCSApi\/send<\/code> once the template’s status<\/code> reads 1<\/code>. When a button is tapped, the postback comes back as your prefix plus a _[message_id]<\/code> suffix, so match it against the prefixes you issued and look the suffix up in your send ledger.<\/p>\n\n\n\n

    The limits that catch people are small and easy to check in code: a template name of up to 20 letters, digits or underscores; titles up to 200 characters; descriptions up to 2,000; up to 4 suggestions per card and 10 cards per carousel; button text up to 25 characters; and every variable costing 10 characters of the field it sits in. Count non-ASCII text by UTF-8 bytes and you’ll never be surprised by an emoji.<\/p>\n\n\n\n

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