A user has joined or left a specific basic group »: this update can only be received by bots, see here » for the user version of this update.
Constructor schema is available as of layer 133. Switch »| Name | Type | Description |
|---|---|---|
| flags | # | Flags, see TL conditional fields |
| chat_id | long | Chat ID |
| date | int | When did this event occur |
| actor_id | long | User that triggered the change (inviter, admin that kicked the user, or the even the user_id itself) |
| user_id | long | User that was affected by the change |
| prev_participant | flags.0?ChatParticipant | Previous participant info (empty if this participant just joined) |
| new_participant | flags.1?ChatParticipant | New participant info (empty if this participant just left) |
| invite | flags.2?ExportedChatInvite | The invite that was used to join the group |
| qts | int | New qts value, see updates » for more info. |
How to handle channels, supergroups, gigagroups, basic groups, and what's the difference between them.
How to subscribe to updates and handle them properly.
Many constructors in the API need to be stored in a local database upon reception and should only ever be updated reactively (passively) when received via updates or by other means (as specified in the documentation), to avoid overloading the server by continuously requesting changes for the same unchanged information.