Telegram Bot Buttons: Reply and Inline

Buttons are a bot’s main interface, and the type you choose shapes both usability and how the code is organised.

Two keyboard types

A reply keyboard. Replaces the user’s keyboard, with buttons visible at the bottom of the screen. A press sends an ordinary text message containing the button label.

The practical consequence: the bot cannot tell a button press from the user typing the same text. That is both convenient and risky: anyone can send a button label at an inconvenient moment.

Inline buttons. Attached to a specific message and staying in the chat with it. A press sends a hidden event carrying data you defined, which the user never sees.

The key difference: an inline button is bound to its message, so a press can edit that message. Every in-place navigation interface follows from that.

When to use which

Task	Type
A main menu that is always available	Reply
An action on a specific object	Inline
A catalogue with pages and navigation	Inline
A quick answer in a conversation	Reply
Confirming an operation	Inline
Requesting a contact or location	Reply (only it can)

The practical rule: reply keyboards for navigation, inline for actions. Mixing them is fine and usually right: a persistent menu at the bottom, inline buttons on cards.

Handling presses

A reply button arrives as a text message. The handler compares the text to what it expects.

Two problems follow:

• Change the label and the handler breaks. Keep the labels in one place rather than duplicating strings across the code.
• The user can type the same text manually at any moment, including mid-scenario. The handler has to survive that.

An inline button arrives as a separate event carrying the data you embedded. Important details:

The data has a length limit. Long values will not fit. In practice: a short action code plus an object identifier, with everything else read from the database.

The data comes from the user. Technically it can be forged. Check permissions on the bot side: the fact that the button was only shown to an administrator guarantees nothing.

Structure the data. A separator and a fixed format, or parsing turns into a pile of conditions nobody can read a month later.

Acknowledging the press

This gets its own section because it is regularly forgotten: an inline button press must be acknowledged. Until it is, the user sees a spinner and the bot looks frozen.

The right order: acknowledge immediately, before any heavy work, and show the result separately by editing the message or sending a new one.

A useful detail: the acknowledgement can carry a short text shown as a popup. Convenient for a quick “added” without cluttering the chat.

Common mistakes

• A menu four levels deep. Users get lost. If it came to that, the task has outgrown buttons - see Mini Apps.
• Buttons from old messages. A user scrolls up and presses a week-old button. The bot must survive stale data rather than crash.
• No press acknowledgement. It reads as a freeze.
• Permissions checked by button visibility. The check belongs in the handler.
• Button labels scattered through the code. The first label change breaks a handler.

How this is structured in a real project: aiogram routers and middleware. The overview is in the Telegram bots guide.