# Telegram Bot API — reply keyboards, inline keyboards, menu button, commands

## Metadata

| Field | Value |
|---|---|
| Institute | Molodetz Institute — Research & Retrieval Division |
| Subject | tui-framework-design |
| Document type | Source Dossier |
| Tier | 1 |
| Source title | Telegram Bot API (bot keyboards, menu button, and commands sections) |
| Source URL | https://core.telegram.org/bots/api |
| Source publisher / author | Telegram |
| Source type | vendor docs |
| Source date (published) | Unknown — not stated |
| Date researched | 2026-10-11 |
| Researched by | tai (agent), model: Muse Spark, on behalf of retoor |
| Research method | direct page fetch |
| Confidence | High |
| Status | Active |

## Summary

The official protocol reference for bot input surfaces: custom reply keyboards that replace the system keyboard, inline keyboards pinned under a message that send nothing by themselves, the menu button opening the command list, and up to 100 scoped commands with slash autocomplete.

## Key findings

- Custom reply keyboards replace the system keyboard with rows of buttons; options include resize, one-time, persistent, and selective display, plus an `input_field_placeholder` of 1-64 characters.
- Inline keyboards sit under a message and send nothing on their own; buttons carry callback data, URLs, switch-inline queries, game, payment, styled, copy-text, or disabled actions, and are editable in place.
- The menu button near the input opens the command list; it has `commands` (default) and `web_app` variants.
- Commands are capped at 100, render highlighted, complete on `/`, and are set per scope and language via `setMyCommands`.
- Bots can also be invoked from the attachment menu and inline via `@username` queries.

## Pros / strengths

- The authoritative protocol contract: exact option names, limits (100 commands, 64-char placeholder), and button taxonomies.
- Cleanly separates the three surfaces (reply keyboard, inline keyboard, menu), which map to distinct UI widgets.

## Cons / limitations / caveats

- Protocol docs, not rendering guidance: how clients lay out keyboards (grid sizing, overflow, scrolling) is unspecified here.
- Only the keyboard/command/menu subset was synthesized; the page is far larger than what this subject needed.

## Relevance to tai

The grammar tai's bot affordances must mirror: a reply-keyboard surface distinct from inline message buttons, a `Menu`-labeled command entry point, `/` autocomplete over a capped command list, and a 64-char input placeholder contract.

## Changelog

| Date | Change |
|---|---|
| 2026-10-11 | Initial dossier created. |