WhatsApp Interactive Messages Guide

The difference between a message that asks people to reply and one that gives them something to tap looks cosmetic. It is not. It is the difference between receiving data and receiving prose you then have to interpret.

Anyone who has tried to count responses from free-text replies knows the problem. “Yes”, “yes 2”, “we’ll come”, “haan ji”, a thumbs up emoji, and a voice note. Every one of those is a human being answering clearly and a system failing to record it.

The three types

The choice between buttons and a list is mostly about how many options you have. But before you design around a three-option limit, check which path you are on — because the caps are two different numbers, and this is the single most common mistake in this area.

The limits that shape the design

Interactive messaging is one of the more tightly constrained parts of the platform, and the constraints are worth knowing before you design a flow around them rather than after.

The 25-character button label is the one that bites. It is enough for an instruction and not enough for a sentence, which pushes all good button copy toward the imperative: Confirm attendance, See the schedule, Get directions. If a label needs a comma, it is too long.

Buttons in templates

This is where interactive messaging earns its keep, because templates are your only route to anyone who has not messaged you recently. Buttons are declared as part of the template and reviewed along with it — and crucially, template quick-reply buttons cap at ten, not three. We use all ten on a live RSVP template: one button for “not attending” and nine carrying party size, so status and headcount arrive in a single tap. A team that assumed the three-button limit applied would have built a two-step conversation for something that needs one.

In our experience the approval failures around buttons are almost never about the button concept and almost always about the example. A URL button with a variable in the path needs a valid example URL supplied, and since January 2026 every URL must be reachable HTTPS. A staging link, a shortener, or a 404 will fail review — so run curl -I over your buttons before submitting, as covered in the template approval guide.

What comes back to you

When someone taps a quick-reply button, you receive a webhook containing the button’s payload — an identifier you set when you built the template. Not the label they saw. The payload.

That distinction is worth designing around. Set payloads that are stable and meaningful to your system (rsvp_yes, rsvp_no) rather than mirroring the display text, because the display text will get reworded eventually and you do not want your response handling to depend on marketing copy. The mechanics of receiving these are in the webhooks guide.

When not to use them

Buttons are not free. Every option you offer is a decision you are asking someone to make, and three buttons where one clear sentence would do is worse, not better.

Skip them when the message is purely informational and no response is wanted — a venue change, a reminder. Adding a button there invites replies you have no plan for, and unanswered taps read to the recipient as being ignored. Use interactivity where you genuinely intend to act on the answer.