What is Rich Card?
Also called message card, carousel card, structured message.
A rich card is a structured message unit combining elements such as a title, description, image, and action buttons into a single rendered block. Several cards shown in a horizontally scrollable row form a carousel. Cards let a conversational surface present selectable options and records without leaving the message stream for a separate page.
Card formats are platform-specific in their schemas but similar in shape. A payload names the fields and actions, and the client renders them using its own styling, so the same content looks native on each surface. Actions typically include opening a URL, sending a hidden payload back to the application, or triggering a platform behavior such as starting a call.
Carousels apply cards to a small result set. They work well for a handful of comparable items where an image aids recognition, such as products, appointment slots, or documents. They work poorly for long lists, since horizontal scrolling hides items and gives no overview, and for results that need comparison across many attributes, where a table or a link to a full view is clearer.
Cards persist in the transcript, which has consequences. A button pressed days later may refer to a slot already taken or an order already shipped, so handlers must validate current state rather than trusting the payload, and expired cards should be updated or disabled where the platform supports message editing.
Accessibility and fallback deserve attention. Every image needs alternative text, action labels must make sense when read aloud in order, and any channel that cannot render cards needs a text equivalent carrying the same options. Systems that broadcast across several channels usually author content once in a neutral structure and let per-channel adapters produce the native card format.
Key points
- Structured block with title, media, and action buttons
- Carousels suit a handful of comparable, image-aided options
- Buttons persist, so handlers must revalidate state
- Images need alternative text and readable action labels
- Non-card channels need an equivalent text fallback
In practice
An assistant offers three available appointment slots as a carousel, each card showing the date, location, and a Book button carrying a slot identifier. On a channel that cannot render cards, the same content arrives as a numbered text list with the same three options. When a customer presses Book two days later, the handler checks the slot, finds it taken, and replies with fresh availability instead of confirming.