SMeetBot API
Sections and contents

Sections

On this page

SMeet Bot API

API changelog

Every change of the Bot API contract is recorded here, newest first. The contract itself is published as openapi.json.

How changes are recorded#

  • The version of the path, /bot-api/v1, changes only when a working program could break. Within v1 SMeet adds: new fields, new update types, new values of reason and status, new error codes. Programs ignore what they do not know (Versions and compatibility).
  • Each entry gives the date and the version and lists what is new, what was fixed, what is deprecated and what a program has to change.
  • A deprecated feature keeps working in v1; its entry says what to use instead.
  • The machine-readable contract of the current version is openapi.json.

1.2.0#

Revisions and conditional changes, and Mini Apps. Released together with SMeet Mini Apps; the date is added on release. Everything new is optional: a program that sends no new parameter works as with 1.1.1, except for what "Changed" lists.

New#

  • getMe.capabilities lists what the server promises beyond 1.1.0: chat_context, access_revisions, message_revisions, initiator_conditions, strict_conditions, mini_apps (Capabilities).
  • Revisions: access_revision in every Chat, installation_generation in group and channel chats, message_revision in message, edited_message and the results of sending and editing (Revisions in updates).
  • Conditional parameters of the changing methods: expected_access_revision, expected_installation_generation, expected_message_revision and the initiator object, checked together with the action (Conditional requests, initiator).
  • getChatContext: one chat as it is now, with its revisions and an optional check of one person (Chat context).
  • The strict conditions mode, setMyConditionsMode and getMe.conditions_mode (Strict mode).
  • Four error codes: 409 ACCESS_REVISION_CONFLICT, 409 INSTALLATION_GENERATION_CONFLICT, 409 MESSAGE_REVISION_CONFLICT, 403 INITIATOR_NOT_AUTHORIZED.
  • Mini Apps: the mini_app button, the mini_app_submission update with the person's form, getMe.mini_app, and reason: mini_app_not_configured of INVALID_REQUEST about reply_markup (Mini Apps).

Changed#

  • A conditional request repeated with the same key and body returns the first result without checking the chat and the conditions again. Unconditional repeats work as before.
  • A repeat that arrives while the first call is still running waits for it at most 2 seconds, then gets 503 TEMPORARILY_UNAVAILABLE with retry_after 1. A changing call waits for a revocation running at the same moment the same 2 seconds at most.
  • An unknown field whose name starts with expected_, an unknown field inside initiator and a condition a method does not take get 400 INVALID_REQUEST.
  • The sending rate is checked before the locks, so 429 may come before an error found under them.
  • Stop, Block and leaving the bot's space revoke the files the bot received in that private chat for good and cancel the chat's FAILED updates, as the group revocations did already.
  • A person who adds the bot's account to their general block list gives the bot chat_access_changed with the status blocked.
  • Turning a group into a channel or back gives the bot my_chat_member with the new chat.type.
  • A button has exactly one of callback_data, url and mini_app.

Fixed#

  • file_status_changed.chat of an attachment from a group is the group chat, with type, group_id, title and topic_id; it was always private.
  • Two edits of one message at the same moment no longer lose one of them: the second sees the text of the first.
  • Removing a bot from a deleted group no longer fails.

Deprecated#

Nothing.

Migration#

Nothing to change for a program that sends no conditions. To use them: read capabilities at start and at least every 5 minutes, send a condition only when its value is listed, check that every success carries result.chat.access_revision, take each revision from the update the decision was made on and never refresh it, and treat a fresh update without access_revision as a server rollback (the rules). Skip update types you do not know: mini_app_submission reaches only bots with a Mini App.

1.1.1 (2026-10-07)#

Commands in groups are addressed to one bot.

New#

  • @bot_username /command args addresses a command to one bot, in addition to /command@bot_username args. Both arrive as the plain text /command args.

Fixed#

  • A bare /command in a group reached every bot with read_all_messages, so two bots answered one question. It now reaches none.
  • A bot with read_all_messages no longer receives a message plainly addressed to another bot (its mention, its command or a reply to it).

Deprecated#

Nothing.

Migration#

Nothing to change: a command arrives in the same form as in a private chat. Programs that parsed /command@bot_username themselves keep working, because the suffix is now removed before delivery.

1.1.0 (2026-09-30)#

Group, topic and channel support.

New#

  • Group installation with independent read_all_messages, send, edit, delete, pin, restrict and channel-post permissions. Reading all new messages is off by default and never grants history.
  • Group and channel chat objects, including group_id, title and optional topic_id.
  • my_chat_member and delivery_gap updates.
  • Methods: deleteMessage, pinChatMessage, unpinChatMessage and restrictChatMember.

Fixed#

  • Current group access is checked at polling, webhook and FAILED-replay time, so removed access cannot be resurrected.

Deprecated#

Nothing.

Migration#

Keep ignoring unknown update types and chat fields. Programs that want group support should store chat.id as the reply target and handle my_chat_member and delivery_gap; do not assume every chat is private.

1.0.0 (2026-09-26)#

The first public version of the SMeet Bot API, at https://messenger.scrile.com/bot-api/v1.

New#

  • Methods: getMe, getUpdates, rejectUpdate, sendMessage, editMessageText, answerCallbackQuery, getMyCommands, setMyCommands, getDeliveryInfo, getWebhookInfo, uploadFile, sendPhoto, sendDocument, getFile, and file downloads at /files/<file_id>/content.
  • Update types: message, message_edited, message_deleted, callback_query, chat_access_changed and file_status_changed.
  • Long polling with one receiver per bot (consumer_id, lease, epoch), confirmation by offset, server-issued next_offset and skipped ranges. A call with a foreign epoch confirms nothing, and every CONSUMER_CONFLICT carries retry_after.
  • Webhook delivery signed with HMAC-SHA256, with an error budget per update and a circuit breaker. Answers only the owner can fix (a secret that does not match, an address that is gone, a redirect, a certificate) pause delivery until the owner presses Resume delivery in My bots; nothing is lost meanwhile, and SMeet BotFather tells the owner about a pause and about updates moved to FAILED.
  • An Idempotency-Key on every method that changes something; keys are kept for 7 days.
  • Buttons under messages (callback buttons and https:// links) and editing of the bot's own messages.
  • Photos and documents in both directions, checked by an antivirus scanner.
  • The FAILED list with replay by the owner; event_id stays the same across repeats and replays.

Fixed#

Nothing: this is the first version.

Deprecated#

Nothing.

Migration#

Nothing to migrate. Programs written against a preview of the contract should compare their requests with the API reference, which is generated from the published contract. The differences that matter most: a webhook's 401, 403, 404 and 410 pause delivery until the owner resumes it instead of moving updates to FAILED; getMe id is the bot's account id, the same value as from.id of its messages; a call with a foreign epoch confirms nothing; User has no language_code, and a file has no uploading status.