Appearance
Changelog
Changes to the API surface, newest first. This tracks the specification. The gateway route is live and 49 methods are now verified against it with a real (seed) bot token, but public token issuance is still broken, so nothing has shipped to developers yet and nothing here is a release note.
Method additions, removals and status changes are detected automatically by comparing the schema against the last sealed snapshot. The prose around them is written by hand.
Unreleased — 0.1-draft
2026-07-19
The initial surface, published for review.
- Messaging, editing, chat administration, invite links, forum topics, callbacks, inline mode, bot settings, reactions, payments, games and stickers are specified.
- Update delivery is specified for both long polling and webhooks, with the full
allowed_updateslist. - The error taxonomy is mapped from the core's error vocabulary to Telegram-compatible
error_codevalues. - Limits are published as targets, not as measurements.
Surface — 94 methods across 15 categories · 55 types · 23 update types · 21 errors.
49 of 94 methods are verified against the running gateway.
Schema changes since 2026-07-19 — detected automatically by comparing the schema against the sealed snapshot.
| Change | Detail |
|---|---|
| Status | banChatMember — planned → live |
| Status | copyMessage — planned → live |
| Status | copyMessages — planned → live |
| Status | createChatInviteLink — planned → live |
| Status | deleteMessage — planned → live |
| Status | deleteMessages — planned → live |
| Status | deleteMyCommands — planned → live |
| Status | deleteWebhook — planned → live |
| Status | editMessageText — planned → live |
| Status | forwardMessage — planned → live |
| Status | forwardMessages — planned → live |
| Status | getChat — planned → partial |
| Status | getChatAdministrators — planned → live |
| Status | getChatMember — planned → live |
| Status | getChatMemberCount — planned → live |
| Status | getChatMenuButton — planned → live |
| Status | getMe — planned → live |
| Status | getMyCommands — planned → live |
| Status | getMyDefaultAdministratorRights — planned → live |
| Status | getMyDescription — planned → live |
| Status | getMyName — planned → live |
| Status | getMyShortDescription — planned → live |
| Status | getUpdates — planned → live |
| Status | getWebhookInfo — planned → live |
| Status | pinChatMessage — planned → live |
| Status | promoteChatMember — planned → live |
| Status | restrictChatMember — planned → live |
| Status | revokeChatInviteLink — planned → live |
| Status | sendAnimation — planned → live |
| Status | sendChatAction — planned → live |
| Status | sendDocument — planned → live |
| Status | sendLocation — planned → live |
| Status | sendMessage — planned → live |
| Status | sendPhoto — planned → live |
| Status | sendPoll — planned → live |
| Status | sendVideo — planned → live |
| Status | sendVideoNote — planned → live |
| Status | sendVoice — planned → live |
| Status | setChatDescription — planned → live |
| Status | setChatMenuButton — planned → live |
| Status | setChatTitle — planned → live |
| Status | setMessageReaction — planned → live |
| Status | setMyCommands — planned → live |
| Status | setMyDefaultAdministratorRights — planned → live |
| Status | setMyDescription — planned → live |
| Status | setMyName — planned → live |
| Status | setMyShortDescription — planned → live |
| Status | setWebhook — planned → live |
| Status | unbanChatMember — planned → live |
| Status | unpinChatMessage — planned → live |
| Gateway | not live → live |
Open questions that may still change the surface:
- The currency model for payments is undecided — Stars/XTR versus GROM's internal Take token.
sendInvoice,createInvoiceLinkandrefundStarPaymentmay change shape. - No MTProto layer exists, and several parts of the wider specification assume one. Anything depending on user-account access is not specified here.
answerWebAppQueryand the menu-button flow contradict each other in the source specification over whether aquery_idis issued. The method reference documents the conflict rather than picking a side.
How versions will work
Once live, the API is versioned by path — /api/v1, /api/v2 — and old versions stay reachable rather than being switched off under running bots. Additive changes (a new optional parameter, a new field in a response) do not bump the version, so parse responses tolerantly: ignore fields you do not recognise rather than failing on them.
A method moving from planned to live is not a version bump either. It is the only change on this page that means something already worked differently yesterday, so it is listed separately from additions.