A new release of the Discord Social SDK is now available, with the following updates:
✨ New Features
- When calling
Client::GetGuildChannels, channels are now sorted by theirpositionfield, which matches how they are sorted in the Discord client. - Messages received via the Social SDK, no longer create notifications in a Discord client for the same user, to avoid double notification on the same machine.
- Game Profile Integration: New functionality to display game data on Discord user profiles. This includes
UserApplicationProfilesupport with two new methods:Client::GetUserApplicationProfilesandClient::GetUserApplicationProfilesNoLockon the Users class, which retrieve game identity data from external authentication providers. - In-Discord Authentication Flow: Support for users to start account linking directly from Discord (rather than having to initiate it from within your game). Added
Client::RegisterAuthorizeRequestCallbackandClient::RemoveAuthorizeRequestCallbackmethods to handle authentication requests that originate from various Discord entry points. These functions support upcoming Discord client experiments that will be gradually rolled out to users over time.
⚠️ Deprecations
This deprecation aims to improve consistence across the SDK’s API surface as well as provide a safer implementation that has fewer edge cases and less potential for accidental misuse.- Deprecated
Client::GetCurrentUserAPI in favor ofClient::GetCurrentUserV2which returns optional values instead of potentially invalid handles.
🚀 Performance Improvements
- This update implements caching capabilities for the
Client::GetUserMessagesWithLimitfunction to avoid unnecessary remote API calls when sufficient messages are already cached locally.
🎤 Voice Communications Fixes and Improvements
Fixes several critical bugs with the voice communications system, as well as improved overall reliability, and noise and echo suppression and cancellation.- Fixed an issue where voice calls would sometimes transition to
Disconnectedstate instead of reconnecting properly after a network interruption. - Extended AGC2 (Automatic Gain Control 2) support to mobile platforms
🐛 General Stability and Bug Fixes
Multiple general critical bugs that can cause crashes and panics. We highly recommend upgrading to 1.6 to avoid them in your game.- Fixed critical bug where activity party privacy wasn’t properly set, causing “ask to join” to appear instead of “join” for public parties.
- Fixed critical memory safety issue preventing connection objects from being deallocated during timer callbacks.
- Fixed C# marshaling alignment bugs and double-free crashes.
- Improved gateway resilience with fallback to generic URLs on zonal gateway failures.
- Fixed WebSocket write-after-close errors preventing connection issues.
We’ve added more components to modals! All select menus (User, Role, Mentionable, Channel) are now fully supported in modals. In order to use a select menu in a modal, it must be placed inside a Label component. We’ve also added the Text Display component with markdown support as a top-level component in modals.
Components Now Supported in Modals:
Getting Started
- Using Modal Components - Dive into creating a modal
Developer Resources
Check out our Component Reference for details on all available components.As of September 10, 2025, bots can set
banner, avatar, and bio fields using the modify current member route.We started work on end-to-end encryption for Discord over two years ago to enhance our user privacy and security. With
DAVE now supported across all platforms, we’re very close to making every call fully end-to-end encrypted.
Developer Impact
To support our long-term privacy goals, we will only support E2EE calls starting on March 1st, 2026 for all audio and video conversations in direct messages (DMs), group messages (GDMs), voice channels, and Go Live streams on Discord. After that date, any client or application not updated for DAVE support will no longer be able to participate in Discord calls.Implementing E2EE Voice
For developers working with Discord’s voice APIs, you can consult the updated voice documentation and the implementation examples available in our open-source repository as well as the protocol whitepaper.The Discord Developers community is also a great place to find assistance and answers to any integration questions you may have.We’re committed to making this transition as smooth as possible while delivering the enhanced privacy and security that DAVE provides to all Discord users.A new release of the Discord Social SDK is now available, with the following updates:
Unity Plugin
- Fixed a crash primarily affecting low-end Android devices (those with armv7 architecture) in
Client::CreateOrJoinLobbyWithMetadata - Fixed a crash when passing large amounts of metadata in
Client::CreateOrJoinLobbyWithMetadata
You asked for them, and now they’re here! Modals are getting new components!!
What’s New
We’re introducing a new top-level Label component for modals that have alabel, description, and can contain a Text Input or a String Select! You heard right, String Selects now work in modals!- String Selects now work in modals when placed inside a Label component
- Text Inputs can also be used inside a Label component
- When a Text Input is used in a Label component the
labelfield on the Text Input is not allowed in favor oflabelon the Label component - ActionRow + TextInput is now deprecated in favor of the new Label component for better accessibility
- The
requiredfield is now available on String Selects (defaults to true in modals, ignored in messages) - The
disabledfield on String Selects is not currently allowed in modals, and will trigger an error if used
New Layout Component
- Label - A new top-level component that lets you add a title and description to your modal components!
Updates to Modal Components
- Text Input - Text Input can now be used in a Label
- String Select - String Selects can be used in modals! Place them in a Label
Getting Started
- Using Modal Components - Dive into creating a modal
Developer Resources
Check out our Component Reference for details on all available components.Pinning and unpinning messages now has its own permission. We split
PIN_MESSAGES out of MANAGE_MESSAGES to give more granular control over who can pin messages in a channel. This is effective immediately for both users and apps. This change will be backwards compatible until January 12th 2026 when MANAGE_MESSAGES will no longer grant the ability to pin or unpin messages.A new release of the Discord Social SDK is now available, with the following updates:
DM History Support
With the release of DM chat history this patch, the Social SDK can now fully support asynchronous player communication between individual players and in larger chat rooms. Players who go offline or background the game can come back to the history of the chat room and get caught up with what’s happening.- Added
Client::GetUserMessageSummariesandClient::GetUserMessagesWithLimitto retrieve direct message history
Rich Presence
Rich Presence can now more accurately display the different types of activities a player might be engaged in. Specifically, the “Competing” status may be valuable for games that host tournaments, weekend brackets, or other competitive play. Also, when you receive game invites, you can now accept them cross-device; don’t miss the group forming even if you’re AFK.- Added support for additional activity types (Listening, Watching, Competing)
- Added support for new clickable URL fields and additional user status customization
- Support for server-to-server rich presence invites and gateway-based invite handling. This means an invite can be accepted on a different device and the
Client::SetActivityInviteCreatedCallbackwill be invoked on connected SDK sessions.
Linked Channels
Linked channels are all about keeping groups of friends connected in and outside the game. You can now join a player to channel’s linked Discord server from in-game, helping them bridge that gap and stay connected with friends even when they stop playing.- Added
Client::JoinLinkedLobbyGuildto allow members of linked lobbies to join the linked lobby’s guild from in-game
Android
The many-step process of mobile account linking has been simplified for users with Discord installed by deep-linking into the Discord mobile app to authorize with your game- Implemented native authentication support
- Fixed native authentication callback when activities are terminated
-
Added an experimental audio setting on Android to avoid setting the OS to voice comms mode when connected to a Bluetooth headset on Android. This may be used if you wish to avoid the transition to voice volume controls and other related changes when connected to Bluetooth. To enable this setting, pass a
ClientCreateOptionswhen instantiating the client and set theexperimentalAndroidPreventCommsForBluetoothflag
iOS
The many-step process of mobile account linking has been simplified for users with Discord installed by deep-linking into the Discord mobile app to authorize with your game- Added native authentication support
- The experimental Game audio subsystem now makes use of the iOS 18.2+ echo canceller when available and falls back to Standard mode otherwise.
Windows
- Added ARM64 support
Linux
- Ensured glibc 2.31 compatibility
Bug Fixes
- Fixed bug where
Client::SetVoiceLogDirdidn’t have any effect - Added better error event handling to distinguish server authorization errors from user cancellations
- Fixed activity platform validation for console games
- Fixed crash safety issues with
Client::GetCurrentUserwhen the client is in an unexpected non-Ready state. AddedClient::GetCurrentUserV2which explicitly returns an optional handle instead of dummy data in this situation. This issue also affected the Unity and Unreal versions of the SDK - Fixed
Call::SetPTTActive
Known Issues
- When the network is disconnected temporarily, active Calls may sometimes enter the Disconnected state instead of reconnecting. If a Call reaches Disconnected state, you must end and rejoin the call to reconnect if desired.
- For DM chat history
- No SDK-side caching for
Client::GetUserMessagesWithLimit- Every invocation of
Client::GetUserMessagesWithLimitwill directly query the backend rather than using local SDK-side caching. This may have performance implications, particularly under high-frequency usage.
- Every invocation of
- Provisional account merge message retrieval
- After a provisional account is merged into a full account, messages sent while the user was on the provisional account cannot be retrieved.
- No SDK-side caching for
We’re introducing a change to the Request Guild Members gateway opcode.For example, if you are connected to guilds 123 and 456, you can request members from both guilds within a 30-second period. However, you cannot make a second request to guild 123 within that same 30-second window.
What’s changing?
We are implementing a rate limit on the Request Guild Members opcode. This limit specifically affects requests for ALL guild members, when developers setlimit to 0 and use an empty string for query.Note: This rate limit applies only to the initial request when requesting ALL Guild Members, not to the Guild Members Chunk events that are sent in response.
- Rate Limit: 1 request per guild per bot every 30 seconds
- Scope: The limit applies per guild per bot (one bot can request members for different guilds within the 30-second window)
- Behavior: Requests that exceed this limit will receive a
RATE_LIMITEDevent as a response:
Impact on Applications
A small number of applications are currently exceeding this rate limit. If your app heavily relies on this opcode, we recommend reviewing your current implementation and making necessary adjustments to maintain functionality.Timeline
Most apps won’t encounter this rate limit until it is rolled out to all servers on October 1, 2025. However, if you are the developer of an app that is requesting all guild members in very large guilds then you may start seeing this as soon as today, so we can ensure platform stability.What you need to do
If your application uses Request Guild Members to request all members, we recommend:- Implement caching mechanisms for member data
- Update your cache using the
GUILD_MEMBER_ADD,GUILD_MEMBER_UPDATE, andGUILD_MEMBER_REMOVEgateway events
RATE_LIMITED event as a response.Discord Social SDK Communication Features - General Availability
Communication features (cross-platform messaging, voice chat, lobbies, and linked channels) are now generally available for all Discord Social SDK users that meet our application process criteria. Previously available only in closed beta, these features enable seamless player interaction within your game.- Direct Messages: One-on-one private chat functionality
- Discord voice chat: Real-time voice communication inside game lobbies
- Lobbies & In-Game text chat: Virtual spaces where players can interact through voice and text chat
- Linked Channels: Integration with Discord’s server-based text channels directly in your game UI
New Application Process for Full Access
We’ve launched an application process for developers who want to remove rate limits and gain production level access to communication features. Developers can now apply through our developer portal with detailed game information and usage projections to unlock production-level capacity.As part of documenting this application process, we have also documented pre-approval rate limits, so you can build, test and develop against the Social SDK with confidence.Get Started with the Social SDK
The Discord Social SDK binaries are available for download in the Developer Portal after enabling the Discord Social SDK for your application.To learn more about building with the Discord Social SDK, check out the Discord Social SDK Overview.We’ve made a few improvements to the Embedded App SDK for version 2.2.0, here are the highlights:
Changes in version 2.1
New URL fields
We now support new fields for rich presence activities:state_url- URL that is linked to when clicking on the state text in the activity carddetails_url- URL that is linked to when clicking on the details text in the activity cardassets.large_url- URL that is linked to when clicking on the large image in the activity cardassets.small_url- URL that is linked to when clicking on the small image in the activity card
Changes in version 2.2
patchUrlMappings
In line with the recent change to remove the.proxy/ path from Discord Activity proxy URLs, the patchUrlMappings utility has been updated to generate simplified URLs by default. It will now create mappings without the .proxy/ prefix.The Embedded App SDK is available via npm and GitHub. You can check out our installation guide and reference to get started with it!We’ve updated the Content Security Policy (CSP) for Discord Activities to remove the
.proxy/ path requirement when making requests through the discordsays.com proxy. This change simplifies the developer experience while maintaining full backwards compatibility. This was made possible by resolving the underlying privacy considerations that originally required the .proxy/ path restriction.Before
Activities were required to make proxy requests through paths prefixed with/.proxy/:After
Activities can now make proxy requests directly without the/.proxy/ prefix:Technical Details
- CSP Update: The Content Security Policy now allows requests to
https://<app_id>.discordsays.com/*instead of the more restrictivehttps://<app_id>.discordsays.com/.proxy/* - Proxy Behavior: Both URL patterns work identically - your existing proxy mappings (e.g.,
/api -> example.com) will function the same way regardless of whether you use/.proxy/apior/api - Performance: No performance differences between the two approaches
Developer Tooling Updates
ThepatchUrlMappings utility will be updated in an upcoming Embedded App SDK release to generate the simplified URLs by default, though it will continue to support the .proxy/ format for backward compatibility.Backward Compatibility
All existing code will continue to work without changes. The/.proxy/ path prefix is still fully supported and will be maintained indefinitely. You can:- Continue using existing
/.proxy/URLs - Switch to the new, simplified URLs
- Use both patterns simultaneously in the same application
Apps can no longer create guilds. The documentation for these endpoints has been removed and the endpoints have been removed from the OpenAPI specification.See our earlier changelog entry for more information.
We’ve added new functionality to Rich Presences to give users of your application a more interactive and flexible experience. There are two big changes as part of this:
- You can now add clickable links to the state text, details text, large image & small image
- You can now choose which field (name, state, or details) is used in users’ status text in the member list (e.g. instead of “Listening to MyMusic” you can now have your status text show “Listening to Rick Astley”)
We’ve documented gradient role colors and guild tags in the API. Guild tags let users rep their favorite server with a 1-4 character badge next to their display name. They can be accessed using the
primary_guild field on the user object. Servers can now give gradient colors to their roles instead of a single, solid color. Gradient colors use the new colors field on the role object. As part of this change, the color field on roles is now deprecated, but it will still work for backwards compatibility.Gradient Role Colors
- The guild feature
ENHANCED_ROLE_COLORSwill let you know if a guild is able to set gradient colors to roles. - Guild roles now have
colorsas part of the structure. coloron guild roles is deprecated but will still be returned by the API and continues to work for backwards compatibility.- Role color structure
Guild Tags
- Guild tags can be retrieved through the
primary_guildfield on the user object. - User Primary Guild
A new release of the Discord Social SDK is now available, with the following updates:
Lobby Chat History
- Added
Client::GetLobbyMessagesWithLimitto retrieve lobby message histories based on a provided lobby ID, with a maximum of 200 messages and up to 72 hours. - Only messages from lobbies the user is currently a member of can be retrieved.
- DM history will be coming soon too!
Unified Friends List
- Added
Client::GetRelationshipsByGroupwhich both logically groups a user’s relationships for the purpose of rendering a friends list and sorts users based on our Unified Friends List design guidelines. Before, it was necessary to callClient::GetRelationshipsand manually partition each relationship into the appropriate friend group, as well as write your own sorting operations. - Added
Client::SetRelationshipGroupsUpdatedCallbackwhich fires whenever a user change occurs which could invalidate a previously sorted friends list retrieved fromClient::GetRelationshipsByGroup. CallClient::GetRelationshipsByGroupagain to maintain an up-to-date friends list. - Added
IsSpamRequesttoRelationshipHandle, returnstrueif Discord believes the request to be spam.
Audio Changes
- A new experimental audio mode has been added for mobile devices which uses standard media audio streams instead of
voice-specific processing. On iOS this causes the voice engine to use the Remote I/O Audio Unit instead of Voice
Processing I/O and likewise on Android, media stream types are used instead of voice communication types. This mode
may be enabled by creating a Client with a
ClientCreateOptionsparameter whoseexperimentalAudioSystemproperty is set toAudioSystem::Game. In this case, you should also setClient::SetEngineManagedAudioSessionto true. We do not recommend using this for production - however, if you are interested in trying it out, we are looking for feedback! - Added
Client::SetAecDumpto enable recording of audio diagnostic information.
Auth
- Publisher Auth
- Publisher Auth is a new feature which makes authorization easier for publishers with multiple games. This is an early release of this feature and only available to a limited number of partners for now.
- Added
Client::ExchangeChildTokento facilitate child token exchange for public clients. Confidential clients will require a server to server implementation, but this method may be useful for development. - Invites from sibling applications will be visible to the SDK. They can be identified by the
applicationIdfield on theActivityInvitepayload. - Messages sent from other sibling applications will be visible to the SDK. They can be identified by the
ApplicationIdmethod on theMessageHandle.
- Added
Client::RevokeTokenandClient::UnmergeIntoProvisionalAccountto allow games leveraging Public Clients to perform token revocation or unmerge operations directly from clients.
Android
- The SDK is now compatible with 16KB page size.
Misc
- Improved activity serialization, avoiding including null/empty keys in the JSON payload.
We’ve added new endpoints to manage paginated pins in channels. The Get Channel Pins endpoint allows you to retrieve and manage pinned messages in a more efficient way, especially for channels with a large number of pinned messages. Both Pin and Unpin endpoints remain the same with a new route. As part of this change we have deprecated the old endpoints for pinned messages. Switching to the new endpoints should be straightforward, as they maintain similar functionality but with improved pagination support.
New Endpoints
Get Channel Pins: Retrieve a list of pinned messages in a channel with pagination support:GET/channels/{channel.id}/messages/pins
Pin Message: Pin a message in a channel:PUT/channels/{channel.id}/messages/pins/{message.id}
Unpin Message: Unpin a message in a channel:DELETE/channels/{channel.id}/messages/pins/{message.id}
Deprecated Endpoints
Get Pinned Messages:GET/channels/{channel.id}/pins
Pin Message:PUT/channels/{channel.id}/pins/{message.id}
Unpin Message:DELETE/channels/{channel.id}/pins/{message.id}
A new release of the Discord Social SDK is now available, with the following updates:
Authentication
- Added an
APPLICATION_DEAUTHORIZEDwebhook event which can be configured in the developer portal. When a user unlinks their account or revokes authorization for your application in any way, this event will be sent to configured webhooks. The payload will contain serialized user information. See Webhook Events docs for more information on configuring webhook events.
PC
- Added configurable request timeout SDK HTTP client requests. Support is on PC in this release with console and mobile support coming in future release. Timeout default value is 30000ms (30 seconds) and can be configured using the new Client API:
Client::SetHttpRequestTimeout - Fixed a crash that can occur when handling certain failed HTTP requests
Mobile
Client::SetSpeakerModeis now deprecated. UnlessClient::SetEngineManagedAudioSessionis used, audio routing will be handled automatically by the SDK
Android
- Fixed routing of game and voice audio when external audio devices are connected and/or disconnected.
Client::SetEngineManagedAudioSessionhas been added to communicate that the SDK should not manage audio routing and automatically enter and leaveMODE_IN_COMMUNICATIONwhen joining and leaving calls. - Fixed an issue with the Authorize method when a device configuration change needs to restart the activity
iOS
- Various fixes for audio routing and session management. When using the Unity plugin, game audio will no longer stop playing when ending a call. For standalone SDK use, a method
Client::SetEngineManagedAudioSessionhas been added to communicate that the SDK should not automatically start and stop theAVAudioSessionwhen joining and leaving calls. - Corrected supported platform values in
Info.plistfor iOS .frameworks.
Consoles
- Standalone archives now only contain console-specific files, like the Unity and Unreal Engine archives
Misc
- Fixed a thread safety issue with
Client::AddLogCallback - Added [Flags] declaration for bit flags enums in C#
A new release of the Discord Social SDK is now available, with the following updates:
Rich Presence
- Added support for adding custom buttons on activity cards via
Activity::AddButton
Packaging
- Unity and Unreal plugin artifacts now contain just the additional files for console support so they can be extracted on top of the base plugin
- Unity plugin is now packaged as a .zip that you should extract inside the Packages directory of your project to enable the above
- Console archives now contain a small README with some console-specific documentation
Misc
- Added
Client::OpenConnectedGamesSettingsInDiscordfor deeplinking into Discord’s settings for connected games, which provides players some control over who can DM them - Fixed a hang that could occur on Linux in
Client::RegisterLaunchCommandandClient::RegisterLaunchSteamApplication Client::RegisterLaunchCommandandClient::RegisterLaunchSteamApplicationnow work from inside the Steam Runtime on Linux- Fixed a crash on exit that could occur when there were pending callbacks in the queue
We’re removing the top level component limit and raising the limit on number of components in a message to 40 when using the
IS_COMPONENTS_V2 message flag! We’re also removing the limit on the number of components in a Container Component. Legacy messages have not changed and continue to allow up to 5 action rows.What’s New
- Total components: The limit for total components in a message has been increased to 40.
- Top-level components: There is no longer a limit on top level components in a message (previously it was 10).
- Container Component: There is no longer a limit on the number of components in a Container Component (previously it was 10).
Developer Resources
- Check out our Component Reference for detailed specifications on all available components.
- Learn how to build rich message layouts with components with Using Message Components.
We’re bringing new components to messages that you can use in your apps. They allow you to have full control over the layout of your messages.
Why We Built Components V2
Our previous components system, while functional, had limitations:- Content, attachments, embeds, and components had to follow fixed vertical positioning rules
- Visual styling options were limited
- It was difficult to make visually cohesive experiences that combined the various functionalities of messages given they were expressed in a non-unified system
What’s New
Components V2 introduces several new component types that can be used in messages:New Layout Components
- Section - Combine text with an accessory component for contextually linked elements
- Container - Create visually distinct groupings with a customizable accent color
- Separator - Add visual spacing and dividers between components
New Content Components
- Text Display - Add rich markdown-formatted text anywhere in your messages
- Thumbnail - An image used in a section
- Media Gallery - Present collections of images and videos in an organized grid
- File - Embed file attachments as part of your message layout
Getting Started
To use the new components, you’ll need to send the message flag1 << 15 (IS_COMPONENTS_V2) which activates the components system on a per-message basis.We’ve created guides to help you implement these new features:- Using Message Components - Learn how to build rich message layouts with components
- Using Modal Components - Create interactive forms and dialogs
Compatibility Notes
Legacy component behavior will continue to work as before, so your existing integrations won’t break. However, when using the Components V2 flag, you’ll need to adapt to a few changes:- The
contentandembedsfields will no longer work but you’ll be able to use Text Display and Container as replacements - Attachments need to be exposed through components to be visible. You can use a Media Gallery, Thumbnail, or File component to display them
- The
pollandstickersfields are disabled - A max of 10 top-level components and 30 total components in a message
Developer Resources
Check out our Component Reference for detailed specifications on all available components.We can’t wait to see what you build!A new release of the Discord Social SDK is now available, with the following updates:
Platforms
- Playstation standalone archives now include linker stubs
Voice
- Fixed a regression in audio playback on Linux
A new release of the Discord Social SDK is now available, with the following updates:
Platforms
- Added Xbox One and PS4 console support
Auth
- Added support for Unity Services as an external auth provider
Voice
Client::StartCallWithAudioCallbacksnow permits sample data to be modified during record and playback for custom effects processing- Fixed a bug where the speaking state for a user could be stuck in the “on” state
- Added
Call::GetPTTReleaseDelay - Initialization of the voice engine is now delayed until it’s needed
- Fixed a deadlock with the Linux PulseAudio backend where malfunctioning audio devices could cause a voice engine lockup
Rich Presence
- Added support for sending rich presence updates and invites without connecting to the Discord gateway on desktop
Misc
- Added Linux support for
Client::RegisterLaunchCommandandClient::RegisterLaunchSteamApplication - Fixed a crash when a Unity Editor scripting domain reload (e.g. entering/exiting play mode) happens while an async completion callback is pending
- Fixed
Client::RemoveDiscordAndGameFriendonly working if you’re Discord friends - Reduced some log spam from desktop client RPC message handling
Breaking Change
To address security concerns, we are deprecating the ability for applications to create guilds using theCreate Guild
endpoint.What’s Changing
- The Create Guild endpoint (
POST /guilds) will be restricted for applications starting July 15, 2025 - Existing Guilds owned by bots will have their ownership transferred to a real user
- After the deprecation date, the endpoint will no longer be available
Timeline
- April 15, 2025: Deprecation announcement
- June 15, 2025: System DM/Email notifications sent to affected app owners and designated guild members
- July 15, 2025:
Create Guildendpoint will no longer be available
Custom Incentivized Links for Activities
Custom Incentivized Links are used to customize how your incentivized link embed appears to users. You can create them in the developer portal or generate them from within your activity. Incentivized Links can be used as referral links, promotions, deep-linking into your activity, and more.- shareLink will now let you attach custom params to links you share about your game using
custom_id. - Removed
referrer_idfrom shareLink API. Any uses ofreferrer_idshould be moved over to usecustom_idinstead. Passingreferrer_idto shareLink will silently fail.
Starting today, file upload limits for apps are checked per-attachment rather than per-message. This change makes the app attachment behavior the same as when a user uploads multiple attachments on a single message.
- File size limits now apply to each individual attachment
- Previously, limits were applied to the combined size of all attachments in a message
- This aligns app attachment handling with user attachment behavior
attachment_size_limit key that specifies the maximum allowed attachment size. This limit may be higher than the default attachment size limit, depending on the guild’s boost status or the invoking user’s Nitro status.For more information, check out our documentation on file uploads.Developers can now use the Discord Social SDK to build social features into their games, enabling friends lists, cross-platform messaging, voice and more for all players — with or without a Discord account.Discord Social SDK offers features that enhance connectivity and player engagement, including:
- Account Linking
- Provisional Accounts
- Rich Presence
- Deeplink Game Invites
- Cross-Platform Messaging
- Linked Channels
- Voice Chat
Discord Social SDK Developer Resources
New resources are available in the Developer Portal to help you get started with the Discord Social SDK:- Getting Started Guides for C++, Unity and Unreal Engine.
- Development Guides for building your game’s social features.
- Design Guidelines for designing your game’s social features.
- SDK Reference is now available.
- The Discord Social SDK binaries are available for download in the Developer Portal after enabling the Discord Social SDK for your application.
On January 16, 2025, the default file upload limit will change from 25 MiB to 10 MiB.While this limit is already active for users and bot users, it hasn’t yet been applied to webhooks.
- This change will take effect on January 16, 2025.
- The 10 MiB limit will apply to both webhooks and interaction responses.
The entitlement migration which began on October 1, 2024, has been successfully completed as of November 1, 2024.
What’s Changed
- The documentation has been updated to reflect the new entitlement system as the standard behavior.
ENTITLEMENT_UPDATEevent for subscription-related entitlements now only occur when the subscription ends.- The
ends_atvalue on the entitlement object is now set when the subscription ends. - To determine when a subscription was canceled, listen for
SUBSCRIPTION_UPDATEevents or use the Subscription API to retrieve the subscription’sstatusandcanceled_attimestamp.
You can now subscribe to a limited number of HTTP-based outgoing webhook events after configuring a webhook events URL. Currently, 3 events are available:
APPLICATION_AUTHORIZED, ENTITLEMENT_CREATE, and QUEST_USER_ENROLLMENT. Read the webhook events documentation for details on subscribing and using webhook events.When developing user-installable apps, Application Authorized (which is not available via the Gateway) is useful to receive events when your app was installed to a user or server.
ENTITLEMENT_CREATE is the only monetization-related event available using webhook events, so you should still use the Gateway for entitlement-related events. Other monetization-related events will be supported via webhook events soon.The entitlement migration started on October 1, 2024 and will continue through 11:59PM PST on November 1, 2024.We updated our previous entitlement migration guide to provide more up-to-date information on impacts of developer impacts. Here’s a summary of the changes we made:
- The migration will run through November 1, 2024 to ensure that any entitlements that are set to renew in October will be properly migrated to the new entitlement system upon renewal.
ENTITLEMENT_UPDATEevents will only occur when a subscription ends.- The value of the
ends_atinENTITLEMENT_UPDATEevents indicate the timestamp for when the entitlement is no longer valid. - The
ends_atvalue on the entitlement object is set when the subscription ends. - To receive the value of when a subscription was canceled, you should listen for the
SUBSCRIPTION_UPDATEevents or use the Subscription API.
Following up on the rollout of the App Launcher, we’re excited to announce that Activities are now generally available for developers. In addition to API stability, this means that apps with Activities can now be verified, discoverable in the App Directory, and implement monetization.
Recent API Updates
Since the developer preview was announced, there have been a few important API updates:- Activities can now enable and implement monetization features, and
getEntitlements,getSkus, andstartPurchaseare generally available in the Embedded App SDK. - New Get Application Activity Instance endpoint to make managing Activity instances easier.
- Apps with Activities can create an Entry Point command (type
4), which are the primary entry point for Activities in the App Launcher. When new apps enable Activities, a default Entry Point command will be created for the app. Read the original change log and the Entry Point command guide for details. - Activities can now be launched in response to interactions using the
LAUNCH_ACTIVITY(type12) interaction callback type forAPPLICATION_COMMAND,MESSAGE_COMPONENT, andMODAL_SUBMITinteraction types. - Apps can now be installed to users (in addition to servers). After setting up your installation contexts, make sure to request the
application.commandsscope when authorizing with users to make sure your Activity is available for them across their Discord servers, DMs, and Group DMs. - In August, there were updates to the Content Security Policy (CSP) for Activities that limits how you can make requests to external resources when building Activities. Read the change log and the guide on using external resources for details.
Documentation Updates
We’ve also added and improved the documentation for Activities and the Embedded App SDK to make it easier to build:- New reference documentation for Monetization SDK commands:
getEntitlements,getSkus, andstartPurchase - Updated Embedded App SDK Reference documentation that adds signatures and arguments
- Updated development guides for Activity Instance Management and Activity Proxy Considerations when using external resources
- New guide on implementing In-App Purchases (IAP) for Activities
- New guides for Verification and Discovery Surfaces
- New guide on Using Rich Presence with the Embedded App SDK
Soundboard is now available in the API! Apps can now get soundboard sounds, modify them, send them in voice channels, and listen to other users playing them!
Introduced high-level documentation for Discord’s Audio and Video End-to-End Encryption (DAVE) protocol, and the new voice gateway opcodes required to support it
Developer Impact
Starting September 2024, Discord is migrating voice and video in DMs, Group DMs, voice channels, and Go Live streams to use end-to-end encryption (E2EE).Who this affects: Any libraries or apps that support Voice Connections.You are not immediately required to support the E2EE protocol, as calls will automatically upgrade/downgrade to/from E2EE depending on the support of clients in the call.Implementing E2EE Voice
We have added high-level documentation for Discord’s Audio and Video End-to-End Encryption (DAVE) protocol, and the new voice gateway opcodes required to support it.The most thorough documentation on the DAVE protocol is found in the Protocol Whitepaper. You can also use our open-source library libdave to assist with your implementation. The exact format of the DAVE protocol opcodes is detailed in the Voice Gateway Opcodes section of the protocol whitepaper.Future Deprecation and Discontinuation of Non-E2EE Voice
Non-E2EE connections to voice in DMs, Group DMs, voice channels, and Go Live streams will eventually be deprecated and discontinued.In 2025, all official Discord clients will support the protocol and it will be an enforced requirement to connect to the end-to-end encryption-eligible audio/video session types listed above.Once a timeline for deprecation and discontinuation is finalized, we will share details and developers will have at least six months to implement before we sunset non-E2EE voice connections.Read more about Discord’s Audio and Video End-to-End Encryption (DAVE) protocol:You can now create a poll while editing a deferred interaction response with the Edit Original Interaction Response endpoint. Poll away!
Activities can now be launched as a response to interactions using the
LAUNCH_ACTIVITY (type 12) interaction callback type. LAUNCH_ACTIVITY can be used in response to APPLICATION_COMMAND, MESSAGE_COMPONENT, and MODAL_SUBMIT interaction types.Apps with Activities enabled can now create Entry Point commands using the
PRIMARY_ENTRY_POINT (type 4) command type. Apps are limited to one globally-scoped Entry Point command, which appears in the App Launcher.When creating or updating an Entry Point command, an Entry Point handler can be defined using the handler field. The handler field determines whether your app wants to manually handle responding to the interaction:- If the value is
DISCORD_LAUNCH_ACTIVITY(2), Discord will automatically handle the interaction and send a follow-up message to the channel where the Entry Point command was invoked from. - If the value is
APP_HANDLER(1), your app will receive an interaction token and will be responsible for responding to the interaction. In this case, you can launch your Activity using theLAUNCH_ACTIVITY(type12) interaction callback.
Default Entry Point Commands
Starting today, when you enable Activities in your app’s settings, a default Entry Point command called “Launch” will automatically be created for your app. This can be customized or deleted like other commands if you want to update the name or handler type.Added documentation for voice encryption modes
aead_aes256_gcm_rtpsize and aead_xchacha20_poly1305_rtpsize while announcing the deprecation of all xsalsa20_poly1305* variants and aead_aes256_gcm. Deprecated encryption modes will be discontinued as of November 18th, 2024.Deprecated encryption modes will be discontinued as of November 18th, 2024.
We are officially deprecating some very old voice gateway versions (> 7 years ago).
- The voice gateway now supports a resume which re-sends lost messages. Use voice gateway version 8 and refer to Buffered Resume.
- We have removed the default option for voice gateway version. Once this is deprecated, you must pass a voice gateway version.
You will be required to pass a voice gateway version and deprecated voice gateway versions will be discontinued as of November 18th, 2024. See Voice Gateway Versioning for futher details.
Need to get just one role, not the whole role list? Use the new Get Guild Role endpoint to fetch a single role by ID.
We’ve added an approximate user install count to the Application object for user-installable apps. You can also view an app’s install counts in the developer portal.
Voice states can now be accessed over the HTTP API! Apps can use the new Get Current User Voice State and Get User Voice State endpoints to fetch a user’s voice state without a Gateway connection.
The
SET_ACTIVITY RPC command has been updated to support 3 additional activity types: Listening (2), Watching (3), and Competing (5). Previously, it only accepted Playing (0).The Game SDK has not been updated to support setting
ActivityType, and is still limited to read-only (to handle events that you receive from Discord).You can now upload emojis for your application in your app’s settings and use them as custom emojis anywhere on Discord.
- Up to 2000 emojis per app
- Support for user-installable apps
- Can be managed via the API with a bot token
This change is outdated. We have since updated the Activities Proxy CSP and the use of
/.proxy/ is no longer required. For the latest information, please refer to this changelog.https://<application_id>.discordsays.com). This represents a breaking change for all Activities, and as such we have a migration plan in order.our CSP will be updated as follows:- all requests must be made through
https://<application_id>.discordsays.com/.proxy/, and requests to other paths on thediscordsays.comdomain will be blocked. - requests to
https://discord.com/api/will be permitted, but other paths on thediscord.comdomain will be blocked. - Only allowed paths on
cdn.discordapp.comandmedia.discordapp.netwill be permitted such as/attachments/,/icons/, and/avatars/. - nested child iframes must also mount paths prepended by
/.proxy/
patchUrlMappings to automatically route requests through /.proxy/, so updating your SDK version calling patchUrlMappings is a good first step. If you are unfamiliar with patchUrlMappings, please consult the documentation.All Application IDs created after 07/17/2024 12:00:00 UTC (applicationID greater than 1263102905548800000) will also automatically have the new CSP applied. Testing your production code on a new application created after this date is a suggested way for developers to test compliance with this new CSP.Apps can now access guild member profile banners via the API and Gateway! The guild member object now includes a
banner field which can be used to create the guild member banner URL.We are slowly rolling out the message forwarding feature to users. This feature allows callers to create a message using We have applied stricter rate limits for this feature based on the following:
message_reference.type = FORWARD and have the API generate a message_snapshot for the sent message. The feature has some limitations and the snapshot is a minimal version of a standard MessageObject, but does capture the core parts of a message.The resulting message will look something like:- number of forwards sent by the user
- total attachment size
API Updates since preview
This was previously announced but note that the final API has a few changes since the API was first previewed:message snapshotobjects don’t include aguildfield anymore since themessage_referencealready provides that information- forwarded messages have a distinctive
message_referencetype ofFORWARDnow
GET /users/@me/guilds now includes each guild’s banner field! This enables apps using OAuth2 with the guilds scope to display guild banners.Back in March, we announced the beta for user-installed apps. After listening and making updates based on feedback from developers and modmins, we’re excited to announce that user-installed apps are now considered generally available and can be used in all servers (regardless of size).With this update, there are a few API and behavioral updates for user-installed apps.New
A new
API Updates
user_idhas been removed from theinteraction_metadatafield on messages. Instead, you can use theidfield in the nesteduserobject. See the Message Interaction Metadata Object for details.- User-installed apps are now limited to creating a maximum of 5 follow-ups when responding to interactions. This only affects the Create Followup Message endpoint, and apps installed to the server are unaffected.
- On Interactions, the value of
authorizing_integration_ownersis now correctly serialized as a string. Previously, the"0"value was incorrectly serialized as a number. app_permissionson Interactions now correctly represents the permissions for user-installed apps. Previously, the value was incorrect for user-installed apps.- Updating a message can result in a
400response if the content of the message was blocked by AutoMod, which may be particularly important for deferred messages. - Interaction responses are no longer forced to be ephemeral for servers with over 25 members.
New Use External Apps Permission
A new USE_EXTERNAL_APPS (1 << 50) permission was added, and is enabled for servers by default. The new permission lets modmins control whether user-installed apps can post public replies in a server. If Use External Apps is disabled and your app is not installed to the server, your app’s responses will be ephemeral for the end user.Read more in the Moderating Apps on Discord Help Center article.Updated Defaults for New Apps
- Newly-created apps now default to having both “User Install” and “Guild Install” installation contexts enabled. This can be updated in the Installation tab in an app’s settings.
- Newly-created apps now default to using the “Discord Provided Link” install link. This can be updated in the Installation tab in an app’s settings.
- If Discord Provided Link is selected as the install link type,
application.commandsscope is added to both installation contexts.
- Add Auto Moderation
MEMBER_PROFILErule trigger_type. This rule type will check if a member’s profile contains disallowed keywords. - Add Auto Moderation
BLOCK_MEMBER_INTERACTIONaction type currently available for theMEMBER_PROFILErule trigger_type. This action will “quarantine” the member to some extent and prevent them from performing most interactions within a specific server.
Update permissions necessary to modify the
flags field when calling the Modify Guild Member endpoint.Discord Activities: Developer Preview of the Embedded App SDK
Embedded App SDKActivities
March 18, 2024
Discord Developers can now build Activities!Activities are interactive, multiplayer experiences that run in an iframe in Discord. In order to make the communication between your experience and Discord, we’ve introduced the Embedded App SDK to assist in communicating between your app and the Discord client.
- New Discord Activities developer docs with a tutorial, code samples, development guides, and design principles.
- The Embedded App SDK is now available via npm and GitHub.
- The Embedded App SDK Reference is now available.
Apps can now be installed to users—making them easier to install, discover, and access across Discord. User-installed apps can be used across all of a user’s servers, within their (G)DMs, and in DMs with the app’s bot user.When creating or updating your app, you can choose which installation types your app supports on the Installation page in your app’s settings. To quickly get started, you can follow the new Developing a User-Installable App tutorial or read details about the new changes below.This change introduces new concepts and fields across the API that apps will now encounter.
API Changes
Concepts:- Installation context defines how an app was installed: to a user, a guild (server), or both. Currently, apps will default to only support the guild installation context, but the default may change in the future.
- Commands can also support one or both installation contexts, with the default being the same as the app’s supported installation context(s) at the time of command creation.
- Interaction context defines where a command can be used in Discord—within guilds, DM with your app’s bot user, and/or within group DMs and DMs other than with your app’s bot user.
- The installation flow for apps have been updated so users can select whether they want to install an app to their account or to a server.
- New
integration_types_configfield for Applications include the default scopes and permissions for app’s supported installation contexts - New
integration_typesandcontextsfields for Commands are the supported installation and interaction contexts (respectively) for the command. Read command contexts documentation for details. - New
contextfield for Interactions indicates the interaction context where an interaction was triggered from. - New
authorizing_integration_ownersfield for Interactions includes a mapping of installation contexts that the interaction was authorized for, to related snowflakes for that context. Read Authorizing Integration Owners Object for details. app_permissionsis now always serialized for interactions to indicate what permissions your app has access to in the context its’ responding. For (G)DMs with other users, it will include theATTACH_FILES | EMBED_LINKS | MENTION_EVERYONE, and for DMs with the app’s bot user it will also containUSE_EXTERNAL_EMOJISfor the bot’s DM- New
interaction_metadataon Messages that are created as part of an interaction response (either a response or follow-up). See Message Interaction Metadata Object for details. dm_permissionfield for Commands is deprecated. Apps should usecontextsinstead.interactionfield for Messages is deprecated. Apps should useinteraction_metadatainstead.
Limitations and Known Issues
- During the preview, interaction responses for the user installation context will be forced to be ephemeral in servers with over 25 members. Forced ephemerality is enforced at the client-level, so your app does not need to manually pay attention to server size, and will not receive errors via the API.
- All follow-up messages are currently forced to be ephemeral in DMs
- Follow-up messages have a bug where they will not correctly respect user permissions
The Get Guild Prune Count and Begin Guild Prune
endpoints now require the
MANAGE_GUILD permission alongside the existing KICK_MEMBERS requirement.The Create message endpoint now supports an
enforce_nonce parameter. When set to true, the message will be deduped for the same sender within a few minutes. If a message was created with the same nonce, no new message will be created and the previous message will be returned instead. This behavior will become the default for this endpoint in a future API version.Embed objects are now limited more explicitly to 25 embed fields. If you pass more than 25 fields within the an embed’s
fields property, an error will be returned.Previously, only the first 25 embed fields would be displayed within the embed but no error was returned.The existing behavior for
MANAGE_GUILD_EXPRESSIONS and MANAGE_EVENTS will not be changing. These permissions will continue to allow your bot users to create, update and delete expressions/events. No action will be needed if you plan to continue using these permissions.CREATE_GUILD_EXPRESSIONS:1 << 43CREATE_EVENTS:1 << 44
These were rolled out in July 2023 to users and roles and have been added to our developer documentation but are not yet available to app developers. We will share an update here when these new permissions are available in your apps.
What’s Happening?
As outlined in a blog post earlier this year, we are experimenting with end-to-end encryption (e2ee) for voice and video channels.End-to-end encryption is designed to only allow the participants in a call to decipher its contents. One of the protocols we’re experimenting with is called Messaging Layer Security, which we believe would allow us to deliver end-to-end encryption at scale. Intermediaries, including platforms like Discord, are unable to access the content of communications encrypted with end-to-end encryption.How do I prepare for the changes?
During this testing phase, there is nothing developers need to do to support end-to-end encryption. Voice channels will automatically downgrade to documented, non-e2ee protocols when a bot user joins the channel. This is transparent to the connecting client but may result in a slight delay between establishing a connection and receiving audio.What is planned for the future?
We will be continuing our testing and will share updates along with developer documentation and sample code once it is available.Once this information is published, we will provide developers with a substantial timeframe to implement end-to-end encryption when interacting with voice and video.Behavior for message edit interaction response actions like updating interaction responses and sending follow-up messages have been updated to follow a bot user’s permissions.Previously, some message edit interaction response actions would use the default permissions rather than a bot user’s permissions.
We have added a global rate limit for API requests made to
discordapp.com/* and may further restrict requests in the future.To limit impact on your app, please make sure you are making calls to discord.com/*.This does not apply for cdn.discordapp.com.Refer to the API Reference for more info on which url(s) to use when building on the REST API- February 14, 2022 Change Log: Requests to v10 and higher will no longer be supported on
discordapp.com(this does not affectcdn.discordapp.com) - May 4, 2020 #api-announcements
You can now select roles other than admin when inviting users or configuring members of a team. There are four role types that a team member can be assigned: owner, admin, developer, or read-only. The team member object now has an additional
role field, which is a string representing the member’s current role.Details about team member roles are in the updated Teams documentation.We’ve released a new Embed Debugger tool that shows you how a URL’s metadata will be parsed and rendered as a link embed within the Discord client. Use it to preview your site’s embed, or debug why your site’s link embed isn’t working as expected.
The
state field in activity objects can now be set when updating presence for a bot user. The value of state will appear as a custom status for the bot user when an activity’s type is set to 4, or as additional data under an activity’s name for other activity types.We’re introducing an OpenAPI 3.1 spec in public preview to make it easier and more reliable to develop with the HTTP API. While our current developer documentation requires manual reviews and updates, the OpenAPI spec is generated from the source code which means it better reflects the nooks, crannies, and nuances of the Discord API.The public spec can be found in the new
The public preview of the OpenAPI spec is subject to breaking changes without advance notice, and should not be used within production environments. If you see something that looks incorrect or can be improved, you can open an issue.
discord-api-spec repository on GitHub.- Add the
GUILD_MEDIA(16) channel type.GUILD_MEDIAchannels only support threads, similar toGUILD_FORUMchannels.
- Add Auto Moderation
mention_raid_protection_enabledtrigger_metadata field for theMENTION_SPAMtrigger_type. If this field and its parentMENTION_SPAMrule are enabled, Auto Moderation provides baseline detection against sudden spikes in mention activity that are normally indicative of mention raids. - Add
safety_alerts_channel_idguild field andRAID_ALERTS_DISABLEDguild feature flag which are associated with join raid protection
Bot users will stay on the legacy username system for now. More details can be found on the Developer Help Center article.
Identifying migrated users
The new username system will rollout to users over time rather than all at once. The value of a single zero ("0") in the discriminator field on a user will indicate that the user has been migrated to the new username system. Note that the discriminator for migrated users will not be 4-digits like a standard discriminator (it is "0", not "0000"). The value of the username field will become the migrated user’s unique username.After migration of all users is complete, the discriminator field may be removed.Example migrated user
Display names
As part of the new username system, standard Discord users can define a non-unique display name. This value will be a newglobal_name field with a max length of 32 characters. If the user has not set a display name, global_name will be null.Default avatars
For users with migrated accounts, default avatar URLs will be based on the user ID instead of the discriminator. The URL can now be calculated using(user_id >> 22) % 6. Users on the legacy username system will continue using discriminator % 5.Starting today, bot users will be added to all newly-created apps. Settings and configuration options for bot users remain the same, and can still be accessed on the Bot page within your app’s settings.If your app doesn’t need or want a bot user associated with it, you can refrain from adding the
bot scope when installing your app.Interactions now contain a
channel field which is a partial channel object and guaranteed to contain id and type. We recommend that you begin using this channel field to identify the source channel of the interaction, and may deprecate the existing channel_id field in the future. See the interaction documentation for more details.Add new
custom_message action metadata for the BLOCK_MESSAGE action type). You can now specify a custom string for every Auto Moderation rule that will be shown to members whenever the rule blocks their message. This can be used as an additional explanation for why a message was blocked and as a chance to help members understand your server’s rules and guidelines.Upcoming Changes
Currently, threads in Discord (including forum posts) can either be archived or both locked and archived. Starting on March 6, 2023, threads will be able to be locked without being archived, which will slightly change the meaning of thelocked field.locked currently indicates that a thread cannot be reopened by a user without the MANAGE_THREADS (1 << 34) permission, but it doesn’t restrict user activity within active (meaning non-archived) threads. After this change, users (including bot users) without the MANAGE_THREADS permission will be more restricted in locked threads. Users won’t be able to create or update messages in locked threads, or update properties like its title or tags. Additionally, some user activity like deleting messages and adding or removing reactions will only be allowed in locked threads if that thread is also active (or un-archived).If a user or bot user has the MANAGE_THREADS permission, they will still be able to make changes to the thread and messages. The upcoming change does not affect the meaning of the archived field or the behavior of a thread that is both locked and archived.How do I prepare for this change?
If your app is interacting with threads (including forum posts), it should check the state of thelocked and/or archived field for the thread to understand which actions it can or cannot perform. It should also be prepared to handle any errors that it may receive when a thread is locked.- Increase maximum number of rules with
KEYWORDtrigger_type per guild from 5 to 6 - Increase maximum length for each keyword in the
keyword_filterandallow_listtrigger_metadata fields from 30 to 60.
At long last, a new
GUILD_AUDIT_LOG_ENTRY_CREATE event has been added to the gateway, allowing your application to react to moderation actions in guilds. The VIEW_AUDIT_LOG permission is required in order to receive these events, and the GUILD_MODERATION intent needs to be set when connecting to the gateway.A new
member field was added to the thread member object. member is a guild member object that will be included within returned thread member objects when the new with_member field is set to true in the List Thread Members (GET /channels/<channel_id>/thread-members) and Get Thread Member (GET /channels/<channel_id>/thread-members/<user_id>) endpoints.Setting with_member to true will also enable pagination for the List Thread Members endpoint. When the results are paginated, you can use the new after and limit fields to fetch additional thread members and limit the number of thread members returned. By default, limit is 100.Upcoming Changes
Starting in API v11, List Thread Members (GET /channels/<channel_id>/thread-members) will always return paginated results, regardless of whether with_member is passed or not.default_forum_layout is an optional field in the channel object that indicates the default layout for posts in a forum channel. A value of 1 (LIST_VIEW) indicates that posts will be displayed as a chronological list, and 2 (GALLERY_VIEW) indicates they will be displayed as a collection of tiles. If default_forum_layout hasn’t been set, the value will be 0.Setting default_forum_layout requires the MANAGE_CHANNELS permission.Introducing linked roles as well as the ability for all developers to set up their own linked roles with an application. This includes:
- New
role_connections_verification_urlthat can be set in the developer portal in order for the application to render as potential verification option for linked roles. - Application metadata to specify more detailed linked role requirements.
- New endpoints to retrieve (
GET /applications/<application.id>/role-connections/metadata) and update (PUT /applications/<application.id>/role-connections/metadata) application connection metadata. - New
role_connections.writeOAuth2 scope required to authenticate the below requests. - Endpoints to retrieve (
GET /users/@me/applications/{application.id}/role-connection) and update (PUT /users/@me/applications/{application.id}/role-connection) a user’s role connections, both of which return an application role connection object.
For a quick rundown on how to get started using linked roles, refer to the tutorial.
Add Auto Moderation Allow List for Keyword Rules and Increase Max Keyword Rules Per Guild Limit
November 22, 2022
- Auto Moderation rules with trigger_type
KEYWORDnow support anallow_listfield in its trigger_metadata. Any message content that matches anallow_listkeyword will be ignored by the Auto ModerationKEYWORDrule. Eachallow_listkeyword can be a multi-word phrase and can contain wildcard symbols. - Increase maximum number of rules with
KEYWORDtrigger_type per guild from 3 to 5 - Increase maximum length for each regex pattern in the
regex_patternstrigger_metadata field from 75 to 260.
Based on feedback, we’re updating permissions for application commands to simplify permission management and to make command permissions more closely resemble other permissions systems in Discord.Server admins can begin to opt-in to the command permission changes outlined here on a per-server basis starting on December 16, 2022. However, changes will not be applied to all servers until late January or early February.These changes are focused on how configured permissions are used by Discord clients, so most apps will be unaffected. However, if your app uses the Update Permissions endpoint (Discord’s clients determine whether a user can see or invoke a command based on three different permission configurations:
2.
We added a new 2. Modify the behavior based on your use caseAfter you know what permissions behavior the server is using, you should update how you handle that server specifically.To understand what changes you need to make, you should look at the assumptions users have when your app updates their server’s commands permissions. Do you have a web dashboard where admins update permissions? If so, analyze the logic of that dashboard and what your permission configurations are trying to do to map them to the new permissions behavior. Do you document what your app is doing in regards to certain command permissions you’re configuring on behalf of the admin? If so, map that documentation to the new behavior.If you are unsure, you can communicate with your admin users to ask if your new logic meets their expectations.
Current permissions behavior is documented in the application commands documentation and in the changelog for the previous permissions update
PUT /applications/<application_id>/guilds/<guild_id>/commands/<command_id>/permissions), you may need to make updates and should read these changes carefully.Types of command permission configurations
The following information isn’t changing, but it’s helpful context to understand the changes.
- Command-level permissions are set up by an admin for a specific command in their server. These permissions affect only a specific command.
- App-level permissions are set up by an admin for a specific app in their server. These permissions affect all commands for an app.
default_member_permissionsare set up by an app when creating or updating a command.default_member_permissionsapply to that command in all servers (unless an override exists). More information aboutdefault_member_permissionsis in the documentation.
What’s changing?
There are two changes around command permissions:- The logic used to apply permission configurations to a user in a given context within Discord clients
- New
APPLICATION_COMMAND_PERMISSIONS_V2guild feature flag to indicate whether that guild is using the old permissions logic or the new (upcoming) logic.
1. How permission configurations are applied in Discord
Current behavior:
Currently, these systems are mutually-exclusive, meaning that only one type of permission configuration is used to determine whether a user can invoke a command.With this current system, there is a clear hierarchy: command-level permission configurations take precedence (if present), then app-level permission configurations (if present), and finallydefault_member_permissions if neither are present.The implication of the current permissions system means that:- If any command-level permissions are configured, all app-level permissions and
default_member_permissionsare ignored for that command. - If any app-level permissions are configured,
default_member_permissionsis ignored for all of that app’s commands.
Upcoming behavior:
The new system removes the mutual exclusion aspect, meaning that the different types of permission configurations work together rather than independently—specifically, more than one may be used to determine whether a user can invoke a command.default_member_permissions continues to act as a “default” that a developer can set when creating or updating a command.App-level permission configurations now act as the “base” configuration.App-level configurations define who is allowed to use the app and where. These will work together with default_member_permissions, meaning if a user is granted access via an app-level permission configuration, they will still be restricted to the default_member_permissions for each command (by default). No more accidentally granting /ban which requires BAN_MEMBERS to @BotMemers just because you gave them access to the app!Command-level permission configurations now act as an “override” of the app-level.Command-level configurations override what is present at the app-level and any restrictions set by default_member_permissions. This means that an admin can explicitly grant a user access to a specific command even if they are denied access on the app-level or if they don’t have permissions that meet that command’s default_member_permissions.If a command-level configuration does not exist for the given context, the system will fall back to looking at the app-level configuration.Flowchart for command permissions logic
Below is a simplified flowchart that illustrates how permissions will be applied by the Discord client after the new changes take effect.2. APPLICATION_COMMAND_PERMISSIONS_V2 Guild Feature
We added a new APPLICATION_COMMAND_PERMISSIONS_V2 feature flag which indicates whether that server is using the current permissions logic.- If the flag is present, that server is using the old command permissions behavior.
- If the flag is not present, that server has migrated from the old command permissions behavior to the new behavior.
Am I affected?
Your app will only be affected if it uses thePUT /applications/<application_id>/guilds/<guild_id>/commands/<command_id>/permissions endpoint. This is a pretty restricted endpoint used to manage and update application command permissions on behalf of admins, meaning that it requires the applications.commands.permissions.update scope.If your app doesn’t use this endpoint, there’s nothing you need to prepare for these changes.If your app does use this endpoint, you should read the section on preparing for changes below.How do I prepare for the changes?
To prepare for these changes, you should take two steps:1. Use theAPPLICATION_COMMAND_PERMISSIONS_V2 flagUse this flag to determine which permissions logic that server is using. While the transition from the old behavior to the new behavior is happening, you may need two code paths depending on if the flag is present or not.If you don’t have access to guild features already through Gateway events, you can fetch that information using the
GET /guilds/<guild_id> endpoint.What happens if I don’t update my app?
If your app is affected and you don’t update it, permissions behavior that your app configures may not match what you or the users of your app expect.How long do I have to update my app?
The newAPPLICATION_COMMAND_PERMISSIONS_V2 flag is already live, and you should start seeing it in guilds’ feature flags.The new permissions behavior will roll out on December 16, 2022. On this date, admins will begin to see a banner that allows them to optionally move their server to the new behavior.In late January or early February, all servers will be migrated to the new behavior. We’ll post another changelog at this point, at which time you can remove any logic around the old permissions behavior.To help keep us focused on the features, improvements, and gaming-related experiences that Discord users love, we are deprecating the following pieces of the GameSDK starting today, and decommissioning them on Tuesday, May 2, 2023:This deprecation period will last until Tuesday May 2, 2023, after which these pieces will be decommissioned and no longer work. The other pieces of the GameSDK will continue to be supported.We know that Discord is an important place for people to find belonging, and that using your Discord identity in games is a crucial part of that sense of belonging. You’ll still be able to use the GameSDK to integrate Rich Presence, relationships, entitlements, basic user information, and the overlay.
Auto Moderation rules with trigger_type
KEYWORD now support
a regex_patterns field in its trigger_metadata.
Regex patterns are a powerful way to describe many keywords all at once using one expression. Only Rust flavored regex is supported, which can be tested in online editors such as Rustexp.Ephemeral interaction responses and follow-ups can now be deleted with a valid interaction token using the following endpoints:
DELETE /webhooks/<application_id>/<interaction_token>/messages/@originalDELETE /webhooks/<application_id>/<interaction_token>/messages/<message_id>
default_sort_order is an optional field in the channel object that indicates how the threads in a forum channel will be sorted for users by default. Setting default_sort_order requires the MANAGE_CHANNELS permission.If default_sort_order hasn’t been set, its value will be null.Two new trigger types were added to Auto Moderation:
MENTION_SPAMblocks messages that mention more than a set number of unique server members or roles. Apps can define the number (up to 50) using themention_total_limitfield in the trigger metadata object when creating or updating an Auto Moderation rule.SPAMblocks links and messages that are identified as spam.
Forum channels (
GUILD_FORUM or 15) have been released to all community servers. GUILD_FORUM channels are a new channel type that only supports threads, which display differently than in text (GUILD_TEXT) channels.Check out the forums topic for more information on the relevant APIs and technical details, and the Forums FAQ for more about the feature.As of today, message content is a privileged intent for all verified apps and apps eligible for verification. More details about why it’s becoming a privileged intent and how to apply for it is in the Help Center FAQ.Any app that does not have the message content intent configured in its app’s settings within the Developer Portal will receive empty values in fields that expose message content across Discord’s APIs (including the
content, embeds, attachments, and components fields). These restrictions do not apply for messages that a bot or app sends, in DMs that it receives, or in messages in which it is mentioned.If your app is verified
Verified apps and verification-eligible apps must be approved for the message content intent to receive message content. If your verified app isn’t approved, or doesn’t account for the new message content restrictions, it will break for users.Temporary Message Content Intent
Verified apps or apps that have submitted for verification can temporarily opt-in to a grace period which will allow your app to continue receiving message content until October 1. However, if you opt-in to the grace period, your app will be prevented from joining any additional servers until you opt-out. More details are in the Help Center article.If your app is unverified
Unverified apps must still must enable the intent in your app’s settings within the Developer Portal.Existing unverified apps will automatically have the message content intent toggled on in their settings. New unverified apps will have to manually toggle the intent in the Developer Portal.This week, Slash Command mentions are rolling out across all Discord clients (for Android, mentions are limited to the React Native client). Clicking a Slash Command mention will auto-populate the command in the user’s message input.Slash Command mentions use the following format:
</NAME:COMMAND_ID>. You can also use </NAME SUBCOMMAND:ID> and </NAME SUBCOMMAND_GROUP SUBCOMMAND:ID> for subcommands and subcommand groups.Starting on September 12, 2022, apps that aren’t using the new
resume_gateway_url field to resume gateway sessions will be disconnected significantly faster than normal.resume_gateway_url field has been added to the Ready gateway event to support session-specific gateway connections. The value of resume_gateway_url is a session-specific URL that should be used when resuming the gateway session after a disconnect. Previously, wss://gateway.discord.gg was used to connect and resume sessions, but should now only be used during the connection.At the moment, the value of resume_gateway_url will always be wss://gateway.discord.gg to give developers more time to adopt the new field. In the near future, the value will change to the session-specific URLs.On August 8th, 2022 we will begin requiring the
VIEW_CHANNEL (1 << 10) permission for webhook routes which require MANAGE_WEBHOOKS (1 << 29), to align with our documented behavior. We don’t expect that many applications will be affected by this, but in case you are, please ensure you have updated permissions needed for accessing the following routes:While this is a breaking change, most apps only rely on interaction responses (
INTERACTION_CREATE), not message interaction objects (MESSAGE_CREATE). Interaction responses are unaffected by this change.Upcoming Changes
Starting July 18, 2022, thename field for message interaction objects will now include subcommands and subcommand groups in the value (along with the existing top-level command). In the future, we recommend not relying on this message interaction field.The format of the value will be the different command levels (if they exist), separated by spaces:
<command name> <subcommand group name> <subcommand name>The name field is only seen on messages that are a response to an interaction without an existing message, so interaction objects for message components don’t include this field.Updating your app
Most apps only rely on interaction responses, not message interaction objects.We don’t recommend that your app relies on thename field for message interactions objects, but if it does you should update your app to handle subcommands and subcommand groups that your app may encounter.As an example of the change, pretend your app had a command /role with subcommands add and remove. Currently, the name field in the original interaction payload would contain role. If you responded to that interaction with a message then fetched its contents, the name field for that message interaction object would contain role as well.After this change, the name field for the original interaction payload will still contain role. However, now if you responded to that interaction with a message then fetched its contents, the name field for that message interaction object would contain role add or role remove.Application command options of type
STRING now includes optional min_length and max_length fields to control the length of text a user can input.The value of min_length must be greater or equal to 0, and the value of max_length must be greater or equal to 1.Interaction payloads now contain an
app_permissions field whose value is the computed permissions for a bot or app in the context of a specific interaction (including any channel overwrites). Similar to other permission fields, the value of app_permissions is a bitwise OR-ed set of permissions expressed as a string. Read details in the interactions documentation.For apps without a bot user (or without the bot scope), the value of app_permissions will be the same as the permissions for @everyone, but limited to the permissions that can be used in interaction responses (currently ATTACH_FILES, EMBED_LINKS, MENTION_EVERYONE, and USE_EXTERNAL_EMOJIS).Upcoming Changes
MENTION_EVERYONE, SEND_TTS_MESSAGES and USE_EXTERNAL_EMOJIS are the only permissions that will be affected by this change. In a previous version of this changelog, it was indicated that ATTACH_FILES and EMBED_LINKS would be affected but this is no longer the case.MENTION_EVERYONE, SEND_TTS_MESSAGES and USE_EXTERNAL_EMOJIS permissions are calculated is changing in two cases:- When responding to an interaction (like application commands or message components)
- When executing a webhook that the bot created
MENTION_EVERYONE, SEND_TTS_MESSAGES and USE_EXTERNAL_EMOJIS permissions will be calculated based on the permissions its granted, including any overwrites. Previously, a bot’s permissions in these cases relied only on those granted to @everyone.This change only applies to bots. The permissions for an app without a bot user (or without the bot scope) will still depend on @everyone.Updating Your App
If your bot wants to use theMENTION_EVERYONE, SEND_TTS_MESSAGES or USE_EXTERNAL_EMOJIS permissions when responding to interactions or executing a webhook, ensure that the bot was installed (or explicitly granted) with them.Note that even if your bot is installed with certain permissions, they can be changed using overwrites. For interactions, you can use the app_permissions field to determine your app or bot’s contextual permissions before replying.In API v10, the
MESSAGE_CONTENT (1 << 15) intent is now required to receive non-empty values for the content and matched_content fields in AUTO_MODERATION_ACTION_EXECUTION gateway events. This matches the intended behavior for message content across the API.The
$ prefix in identify connection properties are deprecated. The new field names are os, browser, and device. When passed, the $-prefixed names will resolve to the new ones.In API v11, support for the previous field names ($os, $browser, and $device) will be removed.Add new Auto Moderation feature which enables guilds to moderate message content based on keywords, harmful links, and unwanted spam. This change includes:
- New endpoints for creating, updating, and deleting Auto Moderation rules
- New gateway events emitted when Auto Moderation rules are created (
AUTO_MODERATION_RULE_CREATE), updated (AUTO_MODERATION_RULE_UPDATE), and deleted (AUTO_MODERATION_RULE_DELETE). Requires theAUTO_MODERATION_CONFIGURATION(1 << 20) intent - New gateway event emitted when an action is executed (
AUTO_MODERATION_ACTION_EXECUTION). Requires theAUTO_MODERATION_EXECUTION(1 << 21) intent - New audit log entries when rules are created (
AUTO_MODERATION_RULE_CREATE), updated (AUTO_MODERATION_RULE_UPDATE), or deleted (AUTO_MODERATION_RULE_DELETE), or when Auto Moderation performs an action (AUTO_MODERATION_BLOCK_MESSAGE)
Application command permissions have been updated to add more granular control and access to commands in Discord. You can read the major changes below, and the updated documentation for details.
Breaking changes
- Bearer tokens are now required to edit command permissions. Bearer tokens are tokens tied to an authenticating user’s permissions, and can be retrieved using OAuth. The user must have permission to manage the guild and roles.
applications.commands.permissions.updatescope was added as a requirement to edit command permissions.- Disabled the batch editing endpoint (
PUT /applications/{application.id}/guilds/{guild.id}/commands/permissions).
Other changes
- Created a
CHANNELcommand permission type - Increase permission limit from
10to100 - constant (
guild_id - 1) to represent all channels in command permissions - Added
default_member_permissionsfield, which is a bitwise OR-ed set of permissions, expressed as a string. This replaces thedefault_permissionfield, which will soon be deprecated. - Added
dm_permission, which is a boolean flag used to indicate whether a command is available in DMs (only for global application commands). If no value is passed, the global command will be visible in DMs. - Added
APPLICATION_COMMAND_PERMISSIONS_UPDATEgateway event andAPPLICATION_COMMAND_PERMISSION_UPDATEaudit log event.
Added new channel type,
GUILD_FORUM (15). A GUILD_FORUM channel is an unreleased feature that is very similar (from an API perspective) to a GUILD_TEXT channel, except only threads can be created in that channel; messages cannot be sent directly in that channel. Check out the forums topic for more information.The
GET /guilds/{guild.id}/bans endpoint has been migrated to require pagination to improve reliability and stability. Check out the endpoint docs for more information.- API v8 is now deprecated.
GET /channels/{channel.id}/threads/activeis decommissioned in favor ofGET /guilds/{guild.id}/threads/active.- Starting in v10, you must specify the message content intent (
1 << 15) to receive content-related fields in message dispatches. Read more in the Gateway Intents documentation. - To specify a reason for an administrative action in audit logs, apps must now pass the
X-Audit-Log-Reasonheader rather than thereasonparameter for all endpoints. Read more in the Audit Logs documentation. - Message routes (like
POST /channels/{channel.id}/messages) now use theembedsfield (an array of embed objects) instead ofembed. - The
summaryfield for applications now returns an empty string for all API versions. - The
nameanddescriptionfields for Achievements are now strings, and localization info is now passed in newname_localizationsanddescription_localizationsdictionaries. This change standardizes localization to match Application Commands. Read details in the Achievements documentation. - Existing attachments must be specified when
PATCHing messages with new attachments. Any attachments not specified will be removed and replaced with the specified list - Requests to v10 and higher will no longer be supported on
discordapp.com(this does not affectcdn.discordapp.com)
Upcoming changes
Interaction modals are now available, allowing applications to prompt users for further detailed input. Check out the modal docs for more information.Application Commands can now add an attachment option type. See the option type table for more information.
Add new documentation for the recently released guild member timeout feature.
- Add official support for
guild_scheduled_eventsfield onGuildresource sent withGUILD_CREATEevent
Nov 18, 2021
- Breaking change for return type for
GET /guilds/{guild.id}/scheduled-events/{guild_scheduled_event.id}/users - Add
with_user_countquery param forGET /guilds/{guild.id}/scheduled-events/{guild_scheduled_event.id} - Return additional
creatorfield by default in response forGET /guilds/{guild.id}/scheduled-events/{guild_scheduled_event.id} - More details and clarification for the guild scheduled events feature.
- Document support for
beforeandafterquery params forGET /guilds/{guild.id}/scheduled-events/{guild_scheduled_event.id}/users
Nov 15, 2021
Add new documentation for the recently released Guild Scheduled Events feature.Autocomplete interactions are now available, allowing application commands to provide server completed options. Check out the autocomplete interaction docs for more information.
Thread permissions have been updated and simplified:
- “Use Public Threads” is now “Create Public Threads”, which allows users to create public threads and announcement threads in a channel, even if they cannot send messages in that channel.
- “Use Private Threads” is now “Create Private Threads”, which allows users to create private threads in a channel, even if they cannot send messages in that channel.
- “Send Messages in Threads”, which allows users to send a message in a thread. The “Send Messages” permission has no effect in threads: users must have “Send Messages in Threads” to send a message in a thread. This allows for setups where a user can participate in a thread but cannot send a message in the parent channel (like a thread on an announcement post).
User commands and message commands are now live! These commands appear on context menus for users and messages, with more to come in the future.Context menu commands are a type of application command. The “Slash Commands” documentation page has been renamed to “Application Commands” and split out by type to show this.
Message routes now accept an embeds array in addition to the existing embed field. Bots can now send up to 10 embeds per message, to be consistent with webhook behavior. The existing embed field is considered deprecated and will be removed in the next API version.
Message components are now available with our first two components: a layout-based
ActionRow and…buttons!You can now include buttons on messages sent by your app, whether they’re bot messages or responses to interactions. Learn more about message components.The addition of message components means new fields and response types:- An optional
componentsfield has been added to the message object - New response types
6and7have been added for interaction responses, valid only for component-based interactions
API v9 is now available.API v9 includes support for threads, an upcoming feature. Older API versions will not receive any Gateway Events for threads, so it is important to update soon! We’ve prepared a migration guide to help make the upgrade process very straightforward.This documentation is being published early so bots can have at least two months to upgrade before threads launch.Additionally, API v9 also removes the
/channels/:id/messages/:id/suppress-embeds route.Need to keep some of your commands safe from prying eyes, or only available to the right people? Commands now support command permissions!You can enable or disable a command (guild or global) for a specific user or role in a guild. For now, users will still be able to see the commands, but won’t be able to use them.New routes have been added to support this functionality:
GET Guild Application Command PermissionsGET Application Command PermissionsPUT Application Command Permissions
default_permission field has also been added to the ApplicationCommand model. This field allows you to disable commands for everyone in a guild by default, if you prefer to make some of your commands an opt-in experience.There have been reports that sessions have higher frequency of errors when starting if a bot has joined too many guilds (the gateway connection times out). To account for this we have lowered the requirement for large bot sharding down to 150,000 guilds in order to improve reliability.
Changes to interaction response types have been made to support better designs for application commands:
- Type
2Acknowledgehas been deprecated - Type
3ChannelMessagehas been deprecated - Type
5AcknowledgeWithSourcehas been renamed toDeferredChannelMessageWithSource
flags has been documented on InteractionApplicationCommandCallbackData. Setting flags to 64 will make the interaction response ephemeral.Slash Commands are now supported in DMs with bots. Due to this change, some of the fields on the Interaction object have been made optional. Newly optional fields don’t reflect any behavior changes in Slash Commands within guilds; they are to support commands in the context of a DM only.
Permission overwrites in the guild channel creation endpoint are now validated against the permissions your bot has in the guild. Permission overwrites specified in the request body when creating guild channels will now require your bot to also have the permissions being applied. Setting
MANAGE_ROLES permission in channel overwrites is only possible for guild administrators or users with MANAGE_ROLES as a permission overwrite in the channel.Slash Commands are here! There’s a lot to cover, so go check out specific documentation under Slash Commands.Slash Commands include some new features for webhooks as well:
- Webhooks can now update previously-sent messages from the same webhook using Edit Webhook Message and Delete Webhook Message
application field on the READY gateway event, which is a partial application object containing id and flags.Inline Replies have been added to our documentation. They behave differently in v6 and v8, so be cautious in your implementation:
- Inline replies are type
19in v8, but remain type0in v6 - You can now add a
message_referenceon message create to create a reply - A new field
referenced_messagehas been added to the Message Object - A new field
replied_userhas been added to the Allowed Mentions Object - Message Create gateway event is guaranteed to have a
referenced_messageif the message created is a reply. Otherwise, that field is not guaranteed.
The v6 gateway now applies the restrictions for gateway intents. This means the new chunking limitations are now in effect, regardless of intents being used. See Request Guild Members for further details.
Additionally, if privileged intents are not enabled in the application dashboard the bot will not receive the events for those intents.All other intents are always enabled by default unless specified otherwise by the identify payload. We have made a support article to explain some of the changes and resulting issues with more details: Gateway Update FAQ
We’ve introduced API and Gateway v8! Changes are noted throughout the documentation, and you can also read this commit in our docs repo for a full diff.The changes are:
- API and Gateway v8 are now available. v6 is still the default for the time being.
- Gateway Intents are now required
- Removed
guild_subscriptionsin identify in favor of Gateway Intents. - All permissions have been converted to strings-serialized numbers. As such,
permissions_new,allow_new, anddeny_newhave been removed - The
gamefield has been removed. If you need a direct replacement, you can instead reference the first element ofactivities - Channel Permission Overwrite
types are now numbers (0 and 1) instead of strings (“role” and “member”). However due to a current technical constraint, they are string-serialized numbers in audit logoptions. embed_enabledandembed_channel_idhave been removed. Usewidget_enabledandwidget_channel_idinstead.- Form body errors have been improved to include more helpful messaging on validation. See more here
- The
Retry-Afterheader value andretry_afterbody value is now based in seconds instead of milliseconds (e.g.123means 123 seconds) - The
X-RateLimit-Precisionheader is no longer respected.X-RateLimit-ResetandX-RateLimit-Reset-Afterare always returned at millisecond precision (e.g.123.456instead of124) - Bots no longer receive Channel Create Gateway Event for DMs
delete-message-daysis no longer available. Usedelete_message_days.- Removed
roles,premium_since, andnickfrom Presence Update Gateway Event - Removed some integration object fields for Discord application integrations
- Removed
include_applicationsfrom Get Guild Integrations. Application integrations are always included. - The following deprecated routes have been removed for better naming conventions:
/guilds/<guild_id>/widget:/guilds/<guild_id>/embed
/guilds/<guild_id>/widget.json:/servers/<guild_id>/embed.json/servers/<guild_id>/widget.json/guilds/<guild_id>/embed.json
/guilds/<guild_id>/widget.png:/guilds/<guild_id>/embed.png
/channels/<channel_id>/messages/bulk-delete:/channels/<channel_id>/messages/bulk_delete/
/invites/<code>/:/invite/<code>/
Documented
permissions_new, allow_new, and deny_new as string-serialized permission bitfields.The legacy mention behavior for bots is now removed, and granular control of mentions should use the Allowed Mentions API moving forwards.
The Guild Members Chunk gateway event now contains two properties:
chunk_index and chunk_count. These values can be used to keep track of how many events you have left to receive in response to a Request Guild Members command.We’ve added a way to specify mentions in a more granular form. This change also begins the start of a 60 day deprecation cycle on legacy mention behavior. Read more:
We’ve added a new endpoint for deleting all reactions of a specific emoji from a message, as well as some new invite and reaction gateway events. Read more:
The Spectate functionality of Rich Presence no longer requires whitelisting or approval.
We’ve added documentation around a brand new feature: Gateway Intents! Gateway Intents are a great way to specify which events you want to receive from our gateway. Go on, save yourself some bandwidth and CPU usage.Using Intents will change the behavior of some existing events and commands, so please refer to:
Updated our IP discovery message. The old message is deprecated and will be removed in the future.
Fixed a bug from the 2.5.5 release that caused network handshakes to fail, resulting in no networking data being sent. The networking manager and integrated lobby networking should be full operational again after updating.
We’ve shipped some updates to the GameSDK, including support for Linux as well as the IL2CPP backend system for Unity. These changes also fixed a bug in the
SetUserAchievement() method.Get the latest at the top of the Getting Started documentation. If you’re looking for help interacting with the GameSDK or want to report a bug, join us on the official Discord.News Channels are now changed to Announcement Channels. Developer License owners will continue to get access to them (both existing and new). Underlying channel type (GUILD_NEWS = 5) remains the same.
You can now get more precise rate limit reset times, via a new request header. Check out the rate limits documentation for more information.
You can now use Bot tokens for authorization headers against the HTTP API for Achievements.
Additional information around Teams has been added to both the API and the documentation. The Teams page now includes information about the team and team member objects. Additionally, the Get Current Application Information endpoint now returns a
team object if that application belongs to a team. That documentation has also been updated to includes fields that were missing for applications that are games sold on Discord.Additional information has been documented to support Server Nitro Boosting. This includes the addition of a few message types, as well as some new fields on guilds. Please note that this feature is currently under experimentation, and these fields may be subject to change.
The Discord-RPC implementation of Rich Presence has been deprecated in favor of Discord’s new GameSDK. If you’re interested in using Rich Presence, please read our SDK Starter Guide and check out the relevant functions in the Activity Manager.
The Invite Object now includes two additional fields,
target_user and target_user_type.Ask to Join no longer requires approval or whitelisting to use. You are welcome to create in-game UI, but all Ask to Join requests are also now handled by the Discord overlay.There have also been some small additions to the Rich Presence SDK. The previously undocumented
UpdateHandlers() function is now documented.Dispatch documentation around store listings has been removed. Store pages for the Discord Store are now managed entirely within the Developer Portal.
The User object now includes two new additional fields,
premium_type and flags. These can be used to know the Nitro status of a user, or determine which HypeSquad house a user is in.The documentation has been updated to correctly note that the
private_channels field in the Ready should be an empty array, as well as the response from /users/@me/channels for a bot user. This change has been in effect for a long time, but the documentation was not updated.We released server changes that allow guilds to represent an incomplete state of the member list in our clients, which results in inaccurate member lists and online counts over RPC. These fields are now deprecated and will now return an empty members array and an online count of 0 moving forward.
Additional
activity and application fields—as well as corresponding object documentation—have been added to the Message object in support of our newly-released Spotify integration and previous Rich Presence enhancements.The Get Guild Emoji response now also includes a user object if the emoji was added by a user.
The Accept Invite endpoint is deprecated starting today, and will be discontinued on March 23, 2018. The Add Guild Member endpoint should be used in its place.
Additional sharding requirements and information for bots in over 100,000 guilds has been added. This requires a small change in numbers of shards for affected bots. See the documentation for more information.
Rich Presence is now live and available for all developers! Rich Presence allows developers to closely integrate with Discord in a number of new, cool ways like:
- Showing more information about a user’s current game in their profile
- Allowing users to post invitations to join their party or spectate their game in chat
- Displaying “Spectate” and “Ask to Join” buttons on users’ profiles
API and Gateway versions below v6 are now discontinued after being previously deprecated. Version 6 is now the default API and Gateway version. Attempting to use a version below 6 will result in an error.
Changes have been made throughout the documentation to reflect the addition of channel categories to Discord. These includes an additional field—
parent_id—to the base channel object and a new channel category example.Emoji endpoints have been added to the API. Bots can now manage guild emojis to their robo-hearts’ content!
The
type field in the activity object for Gateway Status Update and Presence Update payloads is no longer optional when the activity object is not null.After today, we are changing how default channels function. The “default” channel for a given user is now the channel with the highest position that their permissions allow them to see. New guilds will no longer have a default channel with the same id as the guild. Existing guilds will not have their #general channel id changed. It is possible, if permissions are set in such a way, that a user will not have a default channel in a guild.We saw a use case in many servers where the previously-default #general channel was being repurposed as an announcement-only, non-writable channel for new members by using bots to clear the entire message history. Now, that channel can simply be deleted and re-created with the desired permissions. This change also allows dynamic default channels for users based on permissions.We are also rolling out a change in conjunction that will allow Discord to remember your last-visited channel in a guild across sessions. Newly-joined users will be directed to the guild’s default channel on first join; existing members will return to whichever channel they last visited.
Audit logs are here! Well, they’ve been here all along, but now we’ve got documentation about them. Check it out, but remember: with great power comes great responsibility.