Interactive messages are WhatsApp messages that carry tappable choices rather than only text. They exist because free-text replies are expensive to interpret: a recipient who taps "Change" has told you exactly what they meant, while one who types "cant make it sorry" has not.

There are several kinds and they are not interchangeable. Picking the wrong one is usually discovered as a limit rather than as a preference.

## Which kind should I use?

Two questions decide it: how many options, and does the answer live inside the chat.

**Reply buttons** put up to three tappable choices under a message, so the recipient answers with a tap instead of free text. They suit a quick decision, like confirming or cancelling a booking. The limit is one to three, and it is hard.

**List menus** are what you use when there are more than three choices. Reaching for a fourth reply button is the moment to switch.

**Link buttons** put one tappable button under a message that opens a URL in the recipient's browser. Use one when the next step lives on the web, a checkout page or a set of dates, rather than in the chat itself.

The distinction between the first two and the third is worth stating plainly, because it decides where the conversation continues. A reply button keeps the exchange inside WhatsApp, which keeps the customer service window alive and gives you a structured answer. A link button ends the conversational part and hands the person to a browser.

Beyond those three, WhatsApp also carries **carousels** for scrolling through several cards, **location requests**, and **contact information requests**. Each is its own message type with its own shape.

## What comes back when someone taps?

An identified choice, which is the whole point.

Each reply button carries a `slug` that you set when you send it, alongside the `text` the recipient sees. When they tap, the reply names that slug. So your handler branches on a value you chose, in a vocabulary you control, rather than parsing what somebody typed. Changing the visible label later does not break the branch, because the label and the identifier are separate fields.

That is also the practical argument for buttons over free text in any flow that drives logic: the interpretation problem disappears rather than being solved with better parsing.

## Do interactive messages still need a template?

Yes, whenever any message would.

An interactive message is a message like any other, so the [24-hour customer service window](/docs/knowledge-base/whatsapp/customer-service-window) applies to it unchanged. Inside an open window you can send interactive content freely. Outside one, reaching someone at all takes an approved template, and the interactivity does not exempt you.

This catches people who think of buttons as a lighter kind of message. They are not lighter; they are the same kind of message with more structure in it.

## How do I send one?

Set `interactive.type` to the kind you want and supply that kind's fields.

For reply buttons that is `button`, with a `body_text` and one to three `buttons`, each a `quick_reply` carrying its own `slug` and `text`. For a link button it is `cta_url`, with a `body_text` and a `cta_url` object carrying the button's `text` and `url`.

Each type has its own guide with a complete example in every SDK: [reply buttons](/docs/guides/whatsapp/message-types/interactive/reply-buttons), [list menus](/docs/guides/whatsapp/message-types/interactive/list-menus), [link buttons](/docs/guides/whatsapp/message-types/interactive/cta-url-buttons), [carousels](/docs/guides/whatsapp/message-types/interactive/carousels), [location requests](/docs/guides/whatsapp/message-types/interactive/location-requests) and [contact information requests](/docs/guides/whatsapp/message-types/interactive/contact-info-requests).

Reading the replies back is a separate half, and [interactive replies](/docs/guides/whatsapp/receiving-whatsapp/interactive-replies) covers what arrives when someone taps.