Dispatch envelope
Every Gateway frame has an op field. Dispatch events additionally carry d for the payload and a monotonically increasing s sequence within the current session. Store the latest sequence only after your handler has durably accepted the event.
json
{
"op": "MESSAGE_CREATE",
"s": 42,
"d": {
"id": "<message_id>",
"channel_id": "<channel_id>",
"content": "Hello"
}
}Common event families
| Family | Examples | Intent |
|---|---|---|
| Community structure | GUILD_CREATE, GUILD_UPDATE, CHANNEL_CREATE, ROLE_UPDATE | GUILDS |
| Members | GUILD_MEMBER_ADD, GUILD_MEMBER_UPDATE, GUILD_MEMBER_REMOVE | GUILD_MEMBERS |
| Messages | MESSAGE_CREATE, MESSAGE_UPDATE, MESSAGE_DELETE | GUILD_MESSAGES or DIRECT_MESSAGES |
| Reactions | MESSAGE_REACTION_ADD, MESSAGE_REACTION_REMOVE | Matching reaction intent |
| Interactions | INTERACTION_CREATE | GUILDS plus application installation |
| Presence and typing | PRESENCE_UPDATE, TYPING_START | Explicit high-volume intents |
Delivery semantics
- Dispatch is ordered within one live session
- A resumed session can replay buffered frames after last_seq
- Replay is bounded by time, count and bytes; INVALID_SESSION requires REST reconciliation
- Handlers should be idempotent by resource ID and event sequence
- Unknown payload fields and event names must be ignored for forward compatibility
REST remains authoritative
Gateway events are change notifications, not a permanent event log. After a missed replay window, fetch the affected resource through REST before processing new events.