The three transports#
| Transport | Carries | Requires |
|---|---|---|
| Gateway | Most events, including messages, joins, reactions, and voice state | A persistent WebSocket connection |
| Webhook events | A small set unavailable elsewhere, such as Application Authorized | A public HTTPS endpoint |
| Embedded App SDK | Activity-scoped events such as voice status and screen orientation | An Activity using the SDK |
Gateway events#
The Gateway is the primary way apps receive events. Most events related to channels, guilds, roles, and messages are available only over a Gateway connection.
Gateway events travel over a WebSocket connection your app opens and maintains. That connection has a lifecycle: identify, heartbeat, resume after a disconnect, and reconnect when Discord asks.
Use a community library rather than implementing that loop yourself. Libraries handle heartbeats, resumes, and Gateway rate limits, which are the parts that fail quietly in production.
Webhook events#
Webhook events arrive at your app's Webhook Event URL over HTTP. Few events support this transport, but some exist nowhere else, including Application Authorized, which fires when your app is installed to a user or a server.
This suits serverless apps that otherwise have no reason to hold a connection open.
Embedded App SDK events#
Activities subscribe to SDK events with subscribe() and the event name. These cover the Activity's own context, such as a user's voice status or screen orientation.
Intents#
Gateway events are gated by intents, and some are privileged. Request only the intents your app uses: privileged intents require review once an app reaches verification, and asking for what you do not need turns into a rejection or a delay.
Next steps#
- Choosing a transport — Gateway or HTTP for interactions
- API reference — versions, authentication, and rate limits
- Interactions overview — the user-initiated half of the platform