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 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, list menus, link buttons, carousels, location requests and contact information requests.
Reading the replies back is a separate half, and interactive replies covers what arrives when someone taps.