Gateway events

Events arrive over the gateway as dispatch messages. Each one carries the name in t and its data in d. Objects inside events have the same shape as in the REST API.

#Events by intent

#Connection

#READY

Sent once after identify.

{ "v": 1, "session_id": "…", "user": { "id": "…", "username": "app_…", "name": "My bot", "avatar_id": null, "bot": true },
  "application": { "id": "…", "name": "My bot" }, "intents": ["guilds", "guild_messages"],
  "guilds": [{ "id": "…", "unavailable": true }] }

intents is what the connection asked for. What each server allows is in its GUILD_CREATE.

#Servers

#GUILD_CREATE

Sent for each server after READY, and when the app is installed while connected. d is the server snapshot plus scopes and intents for this server and emojis ([{ id, name, animated, available, image_id }]).

#GUILD_UPDATE

The server's settings, channels or roles changed. Same shape as GUILD_CREATE. Changes close together are sent as one update, at most every 300 ms.

#GUILD_DELETE

{ "id": "…" }. The app was removed from the server: uninstalled, its bot kicked or banned, or the server deleted.

#Messages

#MESSAGE_CREATE and MESSAGE_UPDATE

The message object. Without message_content, the text is empty unless the message mentions the bot or the bot wrote it.

#MESSAGE_DELETE

{ "id", "channel_id", "guild_id" }

#MESSAGE_DELETE_BULK

{ "ids", "channel_id", "guild_id" }. Only ids of messages the bot could see.

#MESSAGE_REACTION_ADD and MESSAGE_REACTION_REMOVE

{ "channel_id", "guild_id", "message_id", "user_id", "emoji" }

#Members

#GUILD_MEMBER_ADD and GUILD_MEMBER_UPDATE

{ "guild_id", "user", "nickname", "joined_at", "roles" }, the member object. Joining by invite and app installs are adds; nickname and role changes are updates.

With moderation access the member also has communication_disabled_until: when their timeout ends, in Unix milliseconds, or null. Starting or ending a timeout then sends an update. Without moderation access, timeouts send nothing.

#GUILD_MEMBER_REMOVE

{ "guild_id", "user" }. Leaving, kicks, bans, prunes and app removals. Without moderation access, a kick or ban looks like any other leave.

#Moderation

#GUILD_BAN_ADD and GUILD_BAN_REMOVE

{ "guild_id", "user" }

#GUILD_AUDIT_LOG_ENTRY_CREATE

The same entry as GET /guilds/{guild_id}/audit-logs:

{ "id": "…", "guild_id": "…", "action_type": 22, "action": "member_banned", "user_id": "…", "target_id": "…",
  "reason": "Spam", "options": {}, "changes": [], "created_at": 1759312800000 }

#Moderation access

Moderation events need the guild_moderation intent and the View audit log permission (or Administrator) on the bot's role in that server, checked on every event. In Lamma only people who can open the audit log see timeouts, bans and who did what, so bots need the same.

#Roles and channels

#GUILD_ROLE_CREATE and GUILD_ROLE_UPDATE

{ "guild_id", "role" }. Reordering roles sends an update for every role.

#GUILD_ROLE_DELETE

{ "guild_id", "role_id" }

#CHANNEL_CREATE and CHANNEL_UPDATE

The channel object, only for channels the bot can see. When a channel changes so the bot can no longer see it, the bot gets CHANNEL_DELETE; when it changes so the bot can now see it, CHANNEL_CREATE.

#CHANNEL_DELETE

{ "id", "guild_id" }

#Emoji

#GUILD_EMOJIS_UPDATE

{ "guild_id", "emojis" }, the server's whole list of custom emoji.

#Commands

#INTERACTION_CREATE

Someone used one of the app's slash commands. See Slash commands.

#Order and delivery

Server events come from the server's audit log, after each change is saved, in order within each server. Access is checked when the event goes out: if the bot loses sight of a channel or the View audit log permission first, it doesn't get the restricted parts. A change that was undone before it was saved sends nothing.