diff --git a/data/core.telegram.org/api/terms.html b/data/core.telegram.org/api/terms.html deleted file mode 100644 index 20985c7cf7..0000000000 --- a/data/core.telegram.org/api/terms.html +++ /dev/null @@ -1,133 +0,0 @@ - - - - - Telegram API Terms of Service - - - - - - - - - - - - - -
- -
-
-
- -

Telegram API Terms of Service

- -
- -

We welcome all developers to use our API and source code to create Telegram-like messaging applications on our platform free of charge. In order to ensure consistency and security across the Telegram ecosystem, all third-party client apps must comply with the following Terms of Service.

-

1. Privacy & Security

-

1.1. Telegram is a privacy-oriented platform. All client apps must, therefore, guard their users' privacy with utmost care and comply with our Security Guidelines.
1.2. Developers are welcome to add new features or improve and extend existing Telegram features provided that these modifications do not violate these Terms of Service.
1.3. As a client developer, you must make sure that all the basic features of the main Telegram apps function correctly and in an expected way both in your app and when users of your app communicate with other Telegram users. It is forbidden to force users of other Telegram clients to download your app in order to view certain messages and content sent using your app.
1.4. It is forbidden to interfere with the basic functionality of Telegram. This includes but is not limited to: making actions on behalf of the user without the user's knowledge and consent, preventing self-destructing content from disappearing, preventing last seen and online statuses from being displayed correctly, tampering with the 'read' statuses of messages (e.g. implementing a 'ghost mode'), preventing typing statuses from being sent/displayed, etc.

-

2. Transparency

-

2.1. You must obtain your own api_id for your application.
2.2. We offer our API free of charge, but your users must be aware of the fact that your app uses the Telegram API and is part of the Telegram ecosystem. This fact must be featured prominently in the app's description in the app stores and in the in-app intro if your app has it.
2.3. To avoid confusion, the title of your app must not include the word “Telegram”. An exception can be made if the word “Telegram” is preceded with the word “Unofficial” in the title.
2.4. You must not use the official Telegram logo for your app. Both the Telegram brand and its logo are registered trademarks protected by law in almost every country.

-

3. Advertising & Monetization

-

3.1. Developers are allowed to monetize their coding efforts through advertising or other legitimate means.
3.2. If you decide to monetize your app, you must clearly mention all the methods of monetization that are used in your app in all its app store descriptions.
3.3. If your app allows accessing content from Telegram channels, you must include support for official sponsored messages in Telegram channels and may not interefere with this functionality.

-

4. Breach of terms

-

4.1. If your app violates these terms, we will notify the Telegram account responsible for the app about the breach of terms.
4.2. If you do not update the app to fix the highlighted issues within 10 days, we will have to discontinue your access to Telegram API and contact the app stores about the removal of your apps that are using the Telegram API in violation of these terms.

-

We reserve the right to expand these terms and guidelines as the need arises. We will inform client developers of such changes via an in-app notification to their accounts connected to the app in question.

-
-

Back to Creating Your Telegram Application »

-
-
- -
- -
-
- -
- - - - - - - - diff --git a/data/core.telegram.org/bots/api-changelog.html b/data/core.telegram.org/bots/api-changelog.html new file mode 100644 index 0000000000..cc9e13d485 --- /dev/null +++ b/data/core.telegram.org/bots/api-changelog.html @@ -0,0 +1,663 @@ + + + + + Bot API changelog + + + + + + + + + + + + + +
+ +
+
+
+
+

Bot API changelog

+ +
+ +
+

The Bot API is an HTTP-based interface created for developers keen on building bots for Telegram.
To learn how to create and set up a bot, please consult our Introduction to Bots »

+
+

You will find all changes to our Bot API on this page.

+

Recent changes

+
+

Subscribe to @BotNews to be the first to know about the latest updates and join the discussion in @BotTalk

+
+

December 30, 2021

+

Bot API 5.6

+ +

December 7, 2021

+

Bot API 5.5

+
    +
  • Bots are now allowed to contact users who sent a join request to a chat where the bot is an administrator with the can_invite_users administrator right – even if the user never interacted with the bot before.
  • +
  • Added support for mentioning users by their ID in inline keyboards. This will only work in Telegram versions released after December 7, 2021. Older clients will display unsupported message.
  • +
  • Added the methods banChatSenderChat and unbanChatSenderChat for banning and unbanning channel chats in supergroups and channels.
  • +
  • Added the field has_private_forwards to the class Chat for private chats, which can be used to check the possibility of mentioning the user by their ID.
  • +
  • Added the field has_protected_content to the classes Chat and Message.
  • +
  • Added the field is_automatic_forward to the class Message.
  • +
+

Note: After this update it will become impossible to forward messages from some chats. Use the fields has_protected_content in the classes Message and Chat to check this.

+

Note: After this update users are able to send messages on behalf of channels they own. Bots are expected to use the field sender_chat in the class Message to correctly support such messages.

+

Note: As previously announced, user identifiers can now have up to 52 significant bits and require a 64-bit integer or double-precision float type to be stored safely.

+

November 5, 2021

+

Bot API 5.4

+ +
+
+

⚠️ WARNING! ⚠️
User identifiers will become bigger than 2^31 - 1 before the end of this year and it will be no longer possible to store them in a signed 32-bit integer type. User identifiers will have up to 52 significant bits, so a 64-bit integer or double-precision float type would still be safe for storing them. Please make sure that your code can correctly handle such user identifiers.

+
+
+

June 25, 2021

+

Bot API 5.3

+

Personalized Commands

+
    +
  • Bots can now show lists of commands tailored to specific situations - including localized commands for users with different languages, as well as different commands based on chat type or for specific chats, and special lists of commands for chat admins.
  • +
  • Added the class BotCommandScope, describing the scope to which bot commands apply.
  • +
  • Added the parameters scope and language_code to the method setMyCommands to allow bots specify different commands for different chats and users.
  • +
  • Added the parameters scope and language_code to the method getMyCommands.
  • +
  • Added the method deleteMyCommands to allow deletion of the bot's commands for the given scope and user language.
  • +
  • Improved visibility of bot commands in Telegram apps with the new 'Menu' button in chats with bots, read more on the blog.
  • +
+

Custom Placeholders

+ +

And More

+
    +
  • Improved documentation of the class ChatMember by splitting it into 6 subclasses.
  • +
  • Renamed the method kickChatMember to banChatMember. The old method name can still be used.
  • +
  • Renamed the method getChatMembersCount to getChatMemberCount. The old method name can still be used.
  • +
  • Values of the field file_unique_id in objects of the type PhotoSize and of the fields small_file_unique_id and big_file_unique_id in objects of the type ChatPhoto were changed.
  • +
+
+
+

⚠️ WARNING! ⚠️
After one of the upcoming Bot API updates, user identifiers will become bigger than 2^31 - 1 and it will be no longer possible to store them in a signed 32-bit integer type. User identifiers will have up to 52 significant bits, so a 64-bit integer or double-precision float type would still be safe for storing them. Please make sure that your code can correctly handle such user identifiers.

+
+
+

April 26, 2021

+

Bot API 5.2

+
    +
  • Support for Payments 2.0, see this manual for more details about the Bot Payments API.
  • +
  • Added the type InputInvoiceMessageContent to support sending invoices as inline query results.
  • +
  • Allowed sending invoices to group, supergroup and channel chats.
  • +
  • Added the fields max_tip_amount and suggested_tip_amounts to the method sendInvoice to allow adding optional tips to the payment.
  • +
  • The parameter start_parameter of the method sendInvoice became optional. If the parameter isn't specified, the invoice can be paid directly from forwarded messages.
  • +
  • Added the field chat_type to the class InlineQuery, containing the type of the chat, from which the inline request was sent.
  • +
  • Added the type VoiceChatScheduled and the field voice_chat_scheduled to the class Message.
  • +
  • Fixed an error in sendChatAction documentation to correctly mention “record_voice” and “upload_voice” instead of “record_audio” and “upload_audio” for related to voice note actions. Old action names will still work for backward compatibility.
  • +
+
+
+

⚠️ WARNING! ⚠️
After the next Bot API update (Bot API 5.3) there will be a one-time change of the value of the field file_unique_id in objects of the type PhotoSize and of the fields small_file_unique_id and big_file_unique_id in objects of the type ChatPhoto.

+
+
+
+

⚠️ WARNING! ⚠️
Service messages about non-bot users joining the chat will be soon removed from large groups. We recommend using the “chat_member” update as a replacement.

+
+
+
+

⚠️ WARNING! ⚠️
After one of the upcoming Bot API updates, user identifiers will become bigger than 2^31 - 1 and it will be no longer possible to store them in a signed 32-bit integer type. User identifiers will have up to 52 significant bits, so a 64-bit integer or double-precision float type would still be safe for storing them. Please make sure that your code can correctly handle such user identifiers.

+
+
+

March 9, 2021

+

Bot API 5.1

+

Added two new update types

+
    +
  • Added updates about member status changes in chats, represented by the class ChatMemberUpdated and the fields my_chat_member and chat_member in the Update class. The bot must be an administrator in the chat to receive chat_member updates about other chat members. By default, only my_chat_member updates about the bot itself are received.
  • +
+

Improved Invite Links

+
    +
  • Added the class ChatInviteLink, representing an invite link to a chat.
  • +
  • Added the method createChatInviteLink, which can be used to create new invite links in addition to the primary invite link.
  • +
  • Added the method editChatInviteLink, which can be used to edit non-primary invite links created by the bot.
  • +
  • Added the method revokeChatInviteLink, which can be used to revoke invite links created by the bot.
  • +
+

Voice Chat Info

+ +

And More

+
    +
  • Added the type MessageAutoDeleteTimerChanged and the field message_auto_delete_timer_changed to the class Message.
  • +
  • Added the parameter revoke_messages to the method kickChatMember, allowing to delete all messages from a group for the user who is being removed.
  • +
  • Added the new administrator privilege can_manage_chat to the class ChatMember and parameter can_manage_chat to the method promoteChatMember. This administrator right is implied by any other administrator privilege.
  • +
  • Supported the new bowling animation for the random dice. Choose between different animations (dice, darts, basketball, football, bowling, slot machine) by specifying the emoji parameter in the method sendDice.
  • +
+
+
+

⚠️ WARNING! ⚠️
After one of the upcoming Bot API updates, some user identifiers will become bigger than 2^31 - 1 and it will be no longer possible to store them in a signed 32-bit integer type. User identifiers will have up to 52 significant bits, so a 64-bit integer or double-precision float type would still be safe for storing them. Please make sure that your code can correctly handle such user identifiers.

+
+
+

November 4, 2020

+

Introducing Bot API 5.0

+

Run Your Own Bot API Server

+
    +
  • Bot API source code is now available at telegram-bot-api. You can now run your own Bot API server locally, boosting your bots' performance.
  • +
  • Added the method logOut, which can be used to log out from the cloud Bot API server before launching your bot locally. You must log out the bot before running it locally, otherwise there is no guarantee that the bot will receive all updates.
  • +
  • Added the method close, which can be used to close the bot instance before moving it from one local server to another.
  • +
+

Transfer Bot Ownership

+
    +
  • You can now use @BotFather to transfer your existing bots to another Telegram account.
  • +
+

Webhooks

+
    +
  • Added the parameter ip_address to the method setWebhook, allowing to bypass DNS resolving and use the specified fixed IP address to send webhook requests.
  • +
  • Added the field ip_address to the class WebhookInfo, containing the current IP address used for webhook connections creation.
  • +
  • Added the ability to drop all pending updates when changing webhook URL using the parameter drop_pending_updates in the methods setWebhook and deleteWebhook.
  • +
+

Working with Groups

+
    +
  • The getChat request now returns the user's bio for private chats if available.
  • +
  • The getChat request now returns the identifier of the linked chat for supergroups and channels, i.e. the discussion group identifier for a channel and vice versa.
  • +
  • The getChat request now returns the location to which the supergroup is connected (see Local Groups). Added the class ChatLocation to represent the location.
  • +
  • Added the parameter only_if_banned to the method unbanChatMember to allow safe unban.
  • +
+

Working with Files

+
    +
  • Added the field file_name to the classes Audio and Video, containing the name of the original file.
  • +
  • Added the ability to disable server-side file content type detection using the parameter disable_content_type_detection in the method sendDocument and the class inputMediaDocument.
  • +
+

Multiple Pinned Messages

+
    +
  • Added the ability to pin messages in private chats.
  • +
  • Added the parameter message_id to the method unpinChatMessage to allow unpinning of the specific pinned message.
  • +
  • Added the method unpinAllChatMessages, which can be used to unpin all pinned messages in a chat.
  • +
+

File Albums

+
    +
  • Added support for sending and receiving audio and document albums in the method sendMediaGroup.
  • +
+

Live Locations

+ +

Anonymous Admins

+
    +
  • Added the field sender_chat to the class Message, containing the sender of a message which is a chat (group or channel). For backward compatibility in non-channel chats, the field from in such messages will contain the user 777000 for messages automatically forwarded to the discussion group and the user 1087968824 (@GroupAnonymousBot) for messages from anonymous group administrators.
  • +
  • Added the field is_anonymous to the class chatMember, which can be used to distinguish anonymous chat administrators.
  • +
  • Added the parameter is_anonymous to the method promoteChatMember, which allows to promote anonymous chat administrators. The bot itself should have the is_anonymous right to do this. Despite the fact that bots can have the is_anonymous right, they will never appear as anonymous in the chat. Bots can use the right only for passing to other administrators.
  • +
  • Added the custom title of an anonymous message sender to the class Message as author_signature.
  • +
+

And More

+ +

And Last but not Least

+
    +
  • Supported the new football and slot machine animations for the random dice. Choose between different animations (dice, darts, basketball, football, slot machine) by specifying the emoji parameter in the method sendDice.
  • +
+

June 4, 2020

+

Bot API 4.9

+
    +
  • Added the new field via_bot to the Message object. You can now know which bot was used to send a message.
  • +
  • Supported video thumbnails for inline GIF and MPEG4 animations.
  • +
  • Supported the new basketball animation for the random dice. Choose between different animations (dice, darts, basketball) by specifying the emoji parameter in the method sendDice.
  • +
+

April 24, 2020

+

Bot API 4.8

+
    +
  • Supported explanations for Quizzes 2.0. Add explanations by specifying the parameters explanation and explanation_parse_mode in the method sendPoll.
  • +
  • Added the fields explanation and explanation_entities to the Poll object.
  • +
  • Supported timed polls that automatically close at a certain date and time. Set up by specifying the parameter open_period or close_date in the method sendPoll.
  • +
  • Added the fields open_period and close_date to the Poll object.
  • +
  • Supported the new darts animation for the dice mini-game. Choose between the default dice animation and darts animation by specifying the parameter emoji in the method sendDice.
  • +
  • Added the field emoji to the Dice object.
  • +
+

March 30, 2020

+

Bot API 4.7

+
    +
  • Added the method sendDice for sending a dice message, which will have a random value from 1 to 6. (Yes, we're aware of the “proper” singular of die. But it's awkward, and we decided to help it change. One dice at a time!)
  • +
  • Added the field dice to the Message object.
  • +
  • Added the method getMyCommands for getting the current list of the bot's commands.
  • +
  • Added the method setMyCommands for changing the list of the bot's commands through the Bot API instead of @BotFather.
  • +
  • Added the ability to create animated sticker sets by specifying the parameter tgs_sticker instead of png_sticker in the method createNewStickerSet.
  • +
  • Added the ability to add animated stickers to sets created by the bot by specifying the parameter tgs_sticker instead of png_sticker in the method addStickerToSet.
  • +
  • Added the field thumb to the StickerSet object.
  • +
  • Added the ability to change thumbnails of sticker sets created by the bot using the method setStickerSetThumb.
  • +
+

January 23, 2020

+

Bot API 4.6

+
    +
  • Supported Polls 2.0.
  • +
  • Added the ability to send non-anonymous, multiple answer, and quiz-style polls: added the parameters is_anonymous, type, allows_multiple_answers, correct_option_id, is_closed options to the method sendPoll.
  • +
  • Added the object KeyboardButtonPollType and the field request_poll to the object KeyboardButton.
  • +
  • Added updates about changes of user answers in non-anonymous polls, represented by the object PollAnswer and the field poll_answer in the Update object.
  • +
  • Added the fields total_voter_count, is_anonymous, type, allows_multiple_answers, correct_option_id to the Poll object.
  • +
  • Bots can now send polls to private chats.
  • +
  • Added more information about the bot in response to the getMe request: added the fields can_join_groups, can_read_all_group_messages and supports_inline_queries to the User object.
  • +
  • Added the optional field language to the MessageEntity object.
  • +
+

December 31, 2019

+

Bot API 4.5

+
    +
  • Added support for two new MessageEntity types, underline and strikethrough.
  • +
  • Added support for nested MessageEntity objects. Entities can now contain other entities. If two entities have common characters then one of them is fully contained inside the other.
  • +
  • Added support for nested entities and the new tags <u>/<ins> (for underlined text) and <s>/<strike>/<del> (for strikethrough text) in parse mode HTML.
  • +
  • Added a new parse mode, MarkdownV2, which supports nested entities and two new entities __ (for underlined text) and ~ (for strikethrough text). Parse mode Markdown remains unchanged for backward compatibility.
  • +
  • Added the field file_unique_id to the objects Animation, Audio, Document, PassportFile, PhotoSize, Sticker, Video, VideoNote, Voice, File and the fields small_file_unique_id and big_file_unique_id to the object ChatPhoto. The new fields contain a unique file identifier, which is supposed to be the same over time and for different bots, but can't be used to download or reuse the file.
  • +
  • Added the field custom_title to the ChatMember object.
  • +
  • Added the new method setChatAdministratorCustomTitle to manage the custom titles of administrators promoted by the bot.
  • +
  • Added the field slow_mode_delay to the Chat object.
  • +
+

July 29, 2019

+

Bot API 4.4

+
    +
  • Added support for animated stickers. New field is_animated in Sticker and StickerSet objects, animated stickers can now be used in sendSticker and InlineQueryResultCachedSticker.
  • +
  • Added support for default permissions in groups. New object ChatPermissions, containing actions which a member can take in a chat. New field permissions in the Chat object; new method setChatPermissions.
  • +
  • The field all_members_are_administrators has been removed from the documentation for the Chat object. The field is still returned in the object for backward compatibility, but new bots should use the permissions field instead.
  • +
  • Added support for more permissions for group and supergroup members: added the new field can_send_polls to ChatMember object, added can_change_info, can_invite_users, can_pin_messages in ChatMember object for restricted users (previously available only for administrators).
  • +
  • The method restrictChatMember now takes the new user permissions in a single argument of the type ChatPermissions. The old way of passing parameters will keep working for a while for backward compatibility.
  • +
  • Added description support for basic groups (previously available in supergroups and channel chats). You can pass a group's chat_id to setChatDescription and receive the group's description in the Chat object in the response to getChat method.
  • +
  • Added invite_link support for basic groups (previously available in supergroups and channel chats). You can pass a group's chat_id to exportChatInviteLink and receive the group's invite link in the Chat object in the response to getChat method.
  • +
  • File identifiers from the ChatPhoto object are now invalidated and can no longer be used whenever the photo is changed.
  • +
  • All webhook requests from the Bot API are now coming from the subnets 149.154.160.0/20 and 91.108.4.0/22. Most users won't need to do anything to continue receiving webhooks. If you control inbound access with a firewall, you may need to update your configuration. You can always find the list of actual IP addresses of servers used to send webhooks there: https://core.telegram.org/bots/webhooks.
  • +
  • As of the next Bot API update (version 4.5), nested MessageEntity objects will be allowed in message texts and captions. Please make sure that your code can correctly handle such entities.
  • +
+

May 31, 2019

+

Bot API 4.3

+
    +
  • Added support for Seamless Telegram Login on external websites.
  • +
  • Added the new object LoginUrl and the new field login_url to the InlineKeyboardButton object which allows to automatically authorize users before they go to a URL specified by the bot. Users will be asked to confirm authorization in their Telegram app (needs version 5.7 or higher) when they press the button:
  • +
+
+ TITLE +
+ +

Also in this update:

+
    +
  • Added the field reply_markup to the Message object, containing the inline keyboard attached to the message.
  • +
  • If a message with an inline keyboard is forwarded, the forwarded message will now have an inline keyboard if the keyboard contained only url and login_url buttons or if the message was sent via a bot and the keyboard contained only url, login_url, switch_inline_query or switch_inline_query_current_chat buttons. In the latter case, switch_inline_query_current_chat buttons are replaced with switch_inline_query buttons.
  • +
  • Bots now receive the edited_message Update even if only Message.reply_markup has changed.
  • +
  • Bots that have the can_edit_messages right in a channel can now use the method editMessageReplyMarkup for messages written by other administrators forever without the 48 hours limit.
  • +
  • Don't forget that starting in July 2019, webhook requests from Bot API will be coming from the subnets 149.154.160.0/20 and 91.108.4.0/22. Most users won't need to do anything to continue receiving webhooks. If you control inbound access with a firewall, you may need to update your configuration. You can always find the list of actual IP addresses of servers used to send webhooks there: https://core.telegram.org/bots/webhooks.
  • +
+

April 14, 2019

+

Bot API 4.2

+
    +
  • Added support for native polls: added the object Poll, the methods sendPoll and stopPoll and the field poll in the Message and Update objects.
  • +
  • The method deleteMessage can now be used to delete messages sent by a user to the bot in private chats within 48 hours.
  • +
  • Added support for pinned messages in basic groups in addition to supergroups and channel chats: you can pass group's chat_id to pinChatMessage and unpinChatMessage, and receive the pinned group message in Chat object.
  • +
  • Added the field is_member to the ChatMember object, which can be used to find whether a restricted user is a member of the chat.
  • +
  • Added the field forward_sender_name to the Message object, containing name of the sender who has opted to hide their account.
  • +
  • Starting in July 2019, webhook requests from Bot API will be coming from the subnets 149.154.160.0/20 and 91.108.4.0/22. Most users won't need to do anything to continue receiving webhooks. If you control inbound access with a firewall, you may need to update your configuration. You can always find the list of actual IP addresses of servers used to send webhooks there: https://core.telegram.org/bots/webhooks.
  • +
  • Document thumbnails now should be inscribed in a 320x320 square instead of 90x90.
  • +
+

August 27, 2018

+

Bot API 4.1

+ +

July 26, 2018

+

Bot API 4.0.

+
    +
  • Added support for Telegram Passport. See the official announcement on the blog and the manual for details.
  • +
  • Added support for editing the media content of messages: added the method editMessageMedia and new types InputMediaAnimation, InputMediaAudio, and InputMediaDocument.
  • +
  • Added the field thumb to the Audio object to contain the thumbnail of the album cover to which the music file belongs.
  • +
  • Added support for attaching custom thumbnails to uploaded files. For animations, audios, videos and video notes, which are less than 10 MB in size, thumbnails are generated automatically.
  • +
  • tg:// URLs now can be used in inline keyboard url buttons and text_link message entities.
  • +
  • Added the method sendAnimation, which can be used instead of sendDocument to send animations, specifying their duration, width and height.
  • +
  • Added the field animation to the Message object. For backward compatibility, when this field is set, the document field will be also set.
  • +
  • Added two new MessageEntity types: cashtag and phone_number.
  • +
  • Added support for Foursquare venues: added the new field foursquare_type to the objects Venue, InlineQueryResultVenue and InputVenueMessageContent, and the parameter foursquare_type to the sendVenue method.
  • +
  • You can now create inline mentions of users, who have pressed your bot's callback buttons.
  • +
  • You can now use the Retry-After response header to configure the delay after which the Bot API will retry the request after an unsuccessful response from a webhook.
  • +
  • If a webhook returns the HTTP error 410 Gone for all requests for more than 23 hours successively, it can be automatically removed.
  • +
  • Added vCard support when sharing contacts: added the field vcard to the objects Contact, InlineQueryResultContact, InputContactMessageContent and the method sendContact.
  • +
+

February 13, 2018

+

Bot API 3.6.

+
    +
  • Supported text formatting in media captions. Specify the desired parse_mode (Markdown or HTML) when you provide a caption.
  • +
  • In supergroups, if the bot receives a message that is a reply, it will also receive the message to which that message is replying – even if the original message is inaccessible due to the bot's privacy settings. (In other words, replying to any message in a supergroup with a message that mentions the bot or features a command for it acts as forwarding the original message to the bot).
  • +
  • Added the new field connected_website to Message. The bot will receive a message with this field in a private chat when a user logs in on the bot's connected website using the Login Widget and allows sending messages from your bot.
  • +
  • Added the new parameter supports_streaming to the sendVideo method and a field with the same name to the InputMediaVideo object.
  • +
+

November 17, 2017

+

Bot API 3.5.

+ +

October 11, 2017

+

Bot API 3.4.

+ +

August 23, 2017

+

Bot API 3.3.

+
    +
  • Bots can now mention users via inline mentions, without using usernames.
  • +
  • getChat now also returns pinned messages in supergroups, if present. Added the new field pinned_message to the Chat object.
  • +
  • Added the new fields author_signature and forward_signature to the Message object.
  • +
  • Added the new field is_bot to the User object.
  • +
+

July 21, 2017

+

Bot API 3.2. Teach your bot to handle stickers and sticker sets.

+ +

June 30, 2017

+

Bot API 3.1. Build your own robotic police force for supergoups with these new methods for admin bots:

+ +

May 18, 2017

+

Introducing Bot API 3.0.

+

NEW Payment Platform

+

See Introduction to Bot Payments for a brief overview. If you're not a developer, you may like this user-friendly blog post better.

+ +

NEW Video Messages

+
    +
  • As of Telegram v.4.0, users can send short rounded video messages, using an interface similar to that of voice notes.
  • +
  • Added the sendVideoNote method, the new field video_note to Message, the fields record_video_note or upload_video_note to sendChatAction.
  • +
+

NEW Multilingual Bots

+
    +
  • The User object now may have a language_code field that contains the IETF language tag of the user's language.
  • +
  • Thanks to this, your bot can now offer localized responses to users that speak different languages.
  • +
+

More power to admin bots

+
    +
  • unbanChatMemeber now also works in channels!
  • +
  • New method deleteMessage that allows the bot to delete its own messages, as well as messages posted by other in groups and channels where the bot is an administrator.
  • +
+

Minor Changes

+
    +
  • Replaced the field new_chat_member in Message with new_chat_members (the old field will still be available for a while for compatibility purposes).
  • +
  • Inline keyboards with switch_inline_query and switch_inline_query_current_chat can no longer be sent to channels because they are useless there.
  • +
  • New fields gif_duration in InlineQueryResultGif and mpeg4_duration in InlineQueryResultMpeg4Gif.
  • +
+

December 4, 2016

+

Introducing Bot API 2.3.1, a nifty little update that will give you more control over how your bot gets its updates.

+
    +
  • Use the new field max_connections in setWebhook to optimize your bot's server load
  • +
  • Use allowed_updates in setWebhook and getUpdates to selectively subscribe to updates of a certain type. Among other things, this allows you to stop getting updates about new posts in channels where your bot is an admin.
  • +
  • deleteWebhook moved out of setWebhook to get a whole separate method for itself.
  • +
+

November 21, 2016

+

Bot API 2.3

+
    +
  • Modified bot privacy mode for the sake of consistency.
  • +
  • Your bot can now get updates about posts in channels. Added new fields channel_post and edited_channel_post to Update.

    +
  • +
  • You can now update high scores to a lower value by using the new force parameter in setGameScore. Handy for punishing cheaters or fixing errors in your game's High Score table.

    +
  • +
  • Starting today, messages with high scores will be updated with new high scores by default. Use disable_edit_message in setGameScore if you don't want this.
  • +
  • The edit_message parameter from setGameScore is no longer in use. For backward compatibility, it will be taken into account for a while, unless disable_edit_message is passed explicitly.
  • +
  • Added the new field forward_from_message_id to Message.
  • +
  • Added the new parameter cache_time to answerCallbackQuery. Will eventually work in Telegram apps — somewhere after version 3.14, maybe 3.15.
  • +
  • Renamed hide_keyboard to remove_keyboard in ReplyKeyboardRemove for clarity. hide_keyboard will still work for a while for backward compatibility.
  • +
+

October 3, 2016

+

Bot API 2.2. Introducing a new Gaming Platform! See this introduction for a brief overview.
If you're not a developer, you may like this user-friendly blog post better.

+ +

Other changes

+ +
    +
  • New field all_members_are_administrators in the Chat object.
  • +
  • Certain server responses may now contain the new parameters field with expanded info on errors that occurred while processing your requests.
  • +
+

May 25, 2016

+ +

May 22, 2016

+ +

May 12, 2016

+ +

May 6, 2016

+
    +
  • Added the field emoji to the Sticker object. Your bot can now know the emoji a sticker corresponds to.
  • +
  • Added the field forward_from_chat to the Message object for messages forwarded from channels.
  • +
+

April 9, 2016

+

Introducing Bot API 2.0. Check out this page for a review of this major update.

+ +

Inline bots

+
    +
  • Added support for all content types available on Telegram. 19 types of InlineQueryResult objects are now supported.
  • +
  • Inline bots can now substitute all kinds of content with text. Added 4 types of InputMessageContent objects.
  • +
  • Your inline bot can also ask users for permission to use their location. Added the new Botfather command /setinlinegeo, added field location to the InlineQuery object, added fields location and inline_message_id to the ChosenInlineResult object.
  • +
  • Added an easy way to switch between inline mode and a private chat with the bot – useful for settings, establishing external connections and teaching users how to use your bot in inline mode. Added parameters switch_pm_text and switch_pm_parameter to the method answerInlineQuery.
  • +
+

Miscellaneous

+ +

February 20, 2016

+
    +
  • Added the disable_notification parameter to all methods that send messages or any kind.
  • +
  • Removed backward compatibility from the method sendAudio. Voice messages now must be sent using the method sendVoice. There is no more need to specify a non-empty title or performer while sending the audio by file_id.
  • +
+

January 20, 2016

+
    +
  • By the way, you can use both HTML-style and markdown-style formatting in your bot's messages to send bold, italic or fixed-width text and inline links. All official Telegram clients support this. See Formatting options for details.
  • +
+

January 14, 2016

+
    +
  • You can now collect feedback on which results provided by your inline bot get chosen by the users. Added the setinlinefeedback command for Botfather, new type ChosenInlineResult, new field chosen_inline_result to the Update object.
  • +
+

January 4, 2016

+ +

November, 2015

+
    +
  • Added support for supergroups. The Type field in the Chat object can now contain 'supergroup'.
  • +
  • New optional fields added to the Message object: supergroup_chat_created, migrate_to_chat_id, migrate_from_chat_id and channel_chat_created.
  • +
+

October 8, 2015

+
    +
  • Added initial channel support for bots (no Telegram clients support this at the moment, please wait for updates):
  • +
  • The Chat field in the Message is now of the new type Chat.
  • +
  • You can now pass a channel username (in the format @channelusername) in the place of chat_id in all methods (and instead of from_chat_id in forwardMessage). For this to work, the bot must be an administrator in the channel (and that's exactly what Telegram clients don't support yet — adding bots as administrators coming soon).
  • +
+

September 18, 2015

+
    +
  • Bots can now download files and media sent by users.
  • +
  • Added getFile and File.
  • +
+

September 7, 2015

+
    +
  • You can now pass parameters using application/json (please note that this doesn't work for file uploads: use multipart/form-data to upload files).
  • +
  • Added very basic markdown support. New field parse_mode added to sendMessage. For the moment messages with markdown will be displayed correctly only in Telegram for Android. Other official apps will catch up soon.
  • +
+

August 29, 2015

+
    +
  • Added support for self-signed certificates: upload your certificate using the certificate parameter in the setWebhook method.
  • +
  • You can now make new requests when responding to webhook updates.
  • +
+

August 15, 2015

+
    +
  • Added new type Voice and new method sendVoice for sending voice messages.
  • +
  • Earlier Audio and sendAudio should now be used for sending music files. Telegram clients will show such files in the in-app music player. If you were using sendAudio for your bot to send voice messages, please use sendVoice instead.
  • +
  • Added optional fields performer, title to the Audio object and sendAudio method.
  • +
  • Added optional field voice to the Message object.
  • +
+

July 2015

+
    +
  • The thumb field is now optional for Video, Sticker and Document objects
  • +
  • The API now supports both video and photo captions. The caption field has been removed from the Video object and added to the Message object instead.
  • +
  • caption and duration optional fields have been added to the sendVideo method.
  • +
  • Fixed typo: user_id in the Contact object is now correctly labeled as Integer, not String
  • +
+

June 24, 2015

+

The bot platform was officially launched.

+
+

Back to the Bot API Manual »

+
+
+ +
+ +
+
+ +
+ + + + + + + + diff --git a/data/core.telegram.org/constructor/decryptedMessageActionDeleteMessages.html b/data/core.telegram.org/constructor/decryptedMessageActionDeleteMessages.html new file mode 100644 index 0000000000..f4207360ca --- /dev/null +++ b/data/core.telegram.org/constructor/decryptedMessageActionDeleteMessages.html @@ -0,0 +1,148 @@ + + + + + decryptedMessageActionDeleteMessages + + + + + + + + + + + + + +
+ +
+
+
+ +

decryptedMessageActionDeleteMessages

+ +

Deleted messages.

+

+ +
+
===8===
+decryptedMessageActionDeleteMessages#65614304 random_ids:Vector<long> = DecryptedMessageAction;

+

Parameters

+ + + + + + + + + + + + + + + +
NameTypeDescription
random_idsVector<long>List of deleted message IDs
+

Type

+

DecryptedMessageAction

+ +
+ +
+
+ +
+ + + + + + diff --git a/data/core.telegram.org/constructor/decryptedMessageActionReadMessages.html b/data/core.telegram.org/constructor/decryptedMessageActionReadMessages.html new file mode 100644 index 0000000000..cc25000388 --- /dev/null +++ b/data/core.telegram.org/constructor/decryptedMessageActionReadMessages.html @@ -0,0 +1,148 @@ + + + + + decryptedMessageActionReadMessages + + + + + + + + + + + + + +
+ +
+
+
+ +

decryptedMessageActionReadMessages

+ +

Messages marked as read.

+

+ +
+
===8===
+decryptedMessageActionReadMessages#c4f40be random_ids:Vector<long> = DecryptedMessageAction;

+

Parameters

+ + + + + + + + + + + + + + + +
NameTypeDescription
random_idsVector<long>List of message IDs
+

Type

+

DecryptedMessageAction

+ +
+ +
+
+ +
+ + + + + + diff --git a/data/core.telegram.org/mtproto/description_v1.html b/data/core.telegram.org/mtproto/description_v1.html new file mode 100644 index 0000000000..73c7fb0de0 --- /dev/null +++ b/data/core.telegram.org/mtproto/description_v1.html @@ -0,0 +1,205 @@ + + + + + Mobile Protocol: Detailed Description (v.1.0, DEPRECATED) + + + + + + + + + + + + + +
+ +
+
+
+ +

Mobile Protocol: Detailed Description (v.1.0, DEPRECATED)

+ +
+

This document describes MTProto v.1.0, its status is DEPRECATED. +For information on encryption used in up-to-date Telegram clients, kindly see this document.

+
+

Prior to a message (or a multipart message) being transmitted over a network using a transport protocol, it is encrypted in a certain way, and an external header is added at the top of the message which is: a 64-bit key identifier (that uniquely identifies an authorization key for the server as well as the user) and a 128-bit message key.

+

A user key together with the message key define an actual 256-bit key and a 256-bit initialization vector, which is what encrypts the message using AES-256 encryption with infinite garble extension (IGE). Note that the initial part of the message to be encrypted contains variable data (session, message ID, sequence number, server salt) that obviously influences the message key (and thus the AES key and iv). The message key is defined as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.) Multipart messages are encrypted as a single message.

+ +

Terminology

+

Authorization Key

+

a 2048-bit key shared by the client device and the server, created upon user registration directly on the client device be exchanging Diffie-Hellman keys, and never transmitted over a network. Each authorization key is user-specific. There is nothing that prevents a user from having several keys (that correspond to “permanent sessions” on different devices), and some of these may be locked forever in the event the device is lost. See also Creating an Authorization Key.

+

Server Key

+

a 2048-bit RSA key used by the server digitally to sign its own messages while registration is underway and the authorization key is being generated. The application has a built-in public server key which can be used to verify a signature but cannot be used to sign messages. A private server key is stored on the server and changed very infrequently.

+

Key Identifier

+

The 64 lower-order bits of the SHA1 hash of the authorization key are used to indicate which particular key was used to encrypt a message. Keys must be uniquely defined by the 64 lower-order bits of their SHA1, and in the event of a collision, an authorization key is regenerated. A zero key identifier means that encryption is not used which is permissible for a limited set of message types used during registration to generate an authorization key based on a Diffie-Hellman exchange.

+

Session

+

a (random) 64-bit number generated by the client to distinguish between individual sessions (for example, between different instances of the application, created with the same authorization key). The session in conjunction with the key identifier corresponds to an application instance. The server can maintain session state. Under no circumstances can a message meant for one session be sent into a different session. The server may unilaterally forget any client sessions; clients should be able to handle this.

+

Server Salt

+

a (random) 64-bit number periodically (say, every 24 hours) changed (separately for each session) at the request of the server. All subsequent messages must contain the new salt (although, messages with the old salt are still accepted for a further 300 seconds). Required to protect against replay attacks and certain tricks associated with adjusting the client clock to a moment in the distant future.

+

Message Identifier (msg_id)

+

a (time-dependent) 64-bit number used uniquely to identify a message within a session. Client message identifiers are divisible by 4, server message identifiers modulo 4 yield 1 if the message is a response to a client message, and 3 otherwise. Client message identifiers must increase monotonically (within a single session), the same as server message identifiers, and must approximately equal unixtime*2^32. This way, a message identifier points to the approximate moment in time the message was created. A message is rejected over 300 seconds after it is created or 30 seconds before it is created (this is needed to protect from replay attacks). In this situation, it must be re-sent with a different identifier (or placed in a container with a higher identifier). The identifier of a message container must be strictly greater than those of its nested messages.

+

Important: to counter replay-attacks the lower 32 bits of msg_id passed by the client must not be empty and must present a fractional part of the time point when the message was created. At some point in the nearest future the server will start ignoring messages, in which the lower 32 bits of msg_id contain too many zeroes.

+

Content-related Message

+

A message requiring an explicit acknowledgment. These include all the user and many service messages, virtually all with the exception of containers and acknowledgments.

+

Message Sequence Number (msg_seqno)

+

a 32-bit number equal to twice the number of “content-related” messages (those requiring acknowledgment, and in particular those that are not containers) created by the sender prior to this message and subsequently incremented by one if the current message is a content-related message. A container is always generated after its entire contents; therefore, its sequence number is greater than or equal to the sequence numbers of the messages contained in it.

+

Message Key

+

The lower-order 128 bits of the SHA1 hash of the part of the message to be encrypted (including the internal header and excluding the alignment bytes).

+

Internal (cryptographic) Header

+

A header (16 bytes) added before a message or a container before it is all encrypted together. Consists of the server salt (64 bits) and the session (64 bits).

+

External (cryptographic) Header

+

A header (24 bytes) added before an encrypted message or a container. Consists of a key identifier (64 bits) and a message key (128 bits).

+

Payload

+

External header + encrypted message or container.

+

Defining AES Key and Initialization Vector

+

The 2048-bit authorization key (auth_key) and the 128-bit message key (msg_key) are used to compute a 256-bit AES key (aes_key) and a 256-bit initialization vector (aes_iv) which are subsequently used to encrypt the part of the message to be encrypted (i. e. everything with the exception of the external header which is added later) with AES-256 in infinite garble extension (IGE) mode.

+

The algorithm for computing aes_key and aes_iv from auth_key and msg_key is as follows:

+
    +
  • msg_key = substr (SHA1 (plaintext), 4, 16);
  • +
  • sha1_a = SHA1 (msg_key + substr (auth_key, x, 32));
  • +
  • sha1_b = SHA1 (substr (auth_key, 32+x, 16) + msg_key + substr (auth_key, 48+x, 16));
  • +
  • sha1_с = SHA1 (substr (auth_key, 64+x, 32) + msg_key);
  • +
  • sha1_d = SHA1 (msg_key + substr (auth_key, 96+x, 32));
  • +
  • aes_key = substr (sha1_a, 0, 8) + substr (sha1_b, 8, 12) + substr (sha1_c, 4, 12);
  • +
  • aes_iv = substr (sha1_a, 8, 12) + substr (sha1_b, 0, 8) + substr (sha1_c, 16, 4) + substr (sha1_d, 0, 8);
  • +
+

where x = 0 for messages from client to server and x = 8 for those from server to client.

+

The lower-order 1024 bits of auth_key are not involved in the computation. They may (together with the remaining bits or separately) be used on the client device to encrypt the local copy of the data received from the server. The 512 lower-order bits of auth_key are not stored on the server; therefore, if the client device uses them to encrypt local data and the user loses the key or the password, data decryption of local data is impossible (even if data from the server could be obtained).

+

When AES is used to encrypt a block of data of a length not divisible by 16 bytes, the data is padded with random bytes to the smallest length divisible by 16 bytes immediately prior to being encrypted.

+

Important Tests

+

When an encrypted message is received, it must be checked that msg_key is in fact equal to the 128 lower-order bits of the SHA1 hash of the previously encrypted portion, and that msg_id has even parity for messages from client to server, and odd parity for messages from server to client.

+

In addition, the identifiers (msg_id) of the last N messages received from the other side must be stored, and if a message comes in with msg_id lower than all or equal to any of the stored values, the message is to be ignored. Otherwise, the new message msg_id is added to the set, and, if the number of stored msg_id values is greater than N, the oldest (i. e. the lowest) is forgotten.

+

In addition, msg_id values that belong over 30 seconds in the future or over 300 seconds in the past are to be ignored. This is especially important for the server. The client would also find this useful (to protect from a replay attack), but only if it is certain of its time (for example, if its time has been synchronized with that of the server).

+

Certain client-to-server service messages containing data sent by the client to the server (for example, msg_id of a recent client query) may, nonetheless, be processed on the client even if the time appears to be “incorrect”. This is especially true of messages to change server_salt and notifications of invalid client time. See Mobile Protocol: Service Messages.

+

Storing an Authorization Key on a Client Device

+

It may be suggested to users concerned with security that they password protect the authorization key in approximately the same way as in ssh. This is accomplished by adding the SHA1 of the key to the front of the key, following which the entire string is encrypted using AES in CBC mode and a key equal to the user’s (text) password. When the user inputs the password, the stored protected password is decrypted and verified by being compared with SHA1. From the user’s standpoint, this is practically the same as using an application or a website password.

+

Unencrypted Messages

+

Special plain-text messages may be used to create an authorization key as well as to perform a time synchronization. They begin with auth_key_id = 0 (64 bits) which means that there is no auth_key. This is followed directly by the message body in serialized format without internal or external headers. A message identifier (64 bits) and body length in bytes (32 bytes) are added before the message body.

+

Only a very limited number of messages of special types can be transmitted as plain text.

+

Schematic Presentation of Messages

+

Encrypted Message

+ + + + +
auth_key_id
int64
msg_key
int128
encrypted_data
bytes
+

Encrypted Message: encrypted_data

+

Contains the cypher text for the following data:

+ + + + + + + + +
salt
int64
session_id
int64
message_id
int64
seq_no
int32
message_data_length
int32
message_data
bytes
padding 0..15
bytes
+

Unencrypted Message

+ + + + + +
auth_key_id = 0
int64
message_id
int64
message_data_length
int32
message_data
bytes
+

Creating an Authorization Key

+

An authorization key is normally created once for every user during the application installation process immediately prior to registration. Registration itself, in actuality, occurs after the authorization key is created. However, a user may be prompted to complete the registration form while the authorization key is being generated in the background. Intervals between user key strokes may be used as a source of entropy in the generation of high-quality random numbers required for the creation of an authorization key.

+

See Creating an Authorization Key.

+

During the creation of the authorization key, the client obtains its server salt (to be used with the new key for all communication in the near future). The client then creates an encrypted session using the newly generated key, and subsequent communication occurs within that session (including the transmission of the user's registration information and phone number validation) unless the client creates a new session. The client is free to create new or additional sessions at any time by choosing a new random session_id.

+ +
+ +
+
+ +
+ + + + + +