@tpcstld should we expect libraries to ignore/pass through the _error field? We do say that _ prefixed fields are internal only, so if that's the case, I can un-document this.
#github-notifications
1 messages · Page 22 of 1
335c332 Link to gateway version table - msciotti
9299e31 Non-dm --> guild - msciotti
6ebf011 Clarify channel create - msciotti
b2045cd Fix rate limit consistency example - msciotti
Thank you, great callout. Realistically all the images in the docs should have this too.
f4c57f4 Add alt text for DAPI widget - msciotti
28abc71 Cosistency of versioning and overwrite type - msciotti
It's been a while since I've dug into the Voice API tbh. Last I remember was something like it still being touched very heavily and not wanting to document in case we make a lot of breaking changes. But I can bring this back up next week as a separate note.
My autoformatter is really messing me up. I'm just gonna turn it off for now and do a separate pass in the future for spacing.
Sorry for the annoying table spacing commits, I'll turn my auto-formatter off for now and do a separate commit for aesthetic changes.
3 times in this file it says int but the rest of the docs say integer
this is actually an integer sent as a string ("0" or "1"); #2088
We are so inconsistent in this. Main docs use integer, sdk uses int :( I'll rectify this in some other commit so it's not literally every file touched.
This is a great question. @night might be better equipped as he created this error API, but I believe this is one of the cases where we have an _ prefix but the field is public.
The reason why the _ exists is to avoid a possible collision with a "legitimate" field named "error", due to the nested nature of the object.
anyway that underscore note is for gateway so it doesn't apply to this
@msciotti we might want to talk about this :'D
- For the time being, the API is definitely going to support both JSON int and strings, since we just cast it to a number internally.
- Nevertheless, our official clients will only ever send strings.
- It is entirely up to you whether or not we want to publicly deprecate ints here.
My 2 cents is maybe keep ints here and deprecate in the future if we have to? /shrug Or say that we prefer strings here?
IMO we might refactor this part of the doc in the future, but for now I think we should leave it as-is since its description is aligned with other parts of this table (e.g. owner)
I also got bamboozled by this btw XD
| retry_after | float | The number of seconds to wait before submitting another request. |
In most (all?) cases it's a number with decimals.
Haha true.
This is a side-effect of an implementation detail that makes everything here string-serialized.
| type | string | type of overwritten entity - `"0"` for "role" or `"1"` for "member" | CHANNEL_OVERWRITE_CREATE & CHANNEL_OVERWRITE_UPDATE & CHANNEL_OVERWRITE_DELETE |
After seeing a conversation in DDevs, it brought back an idea to me that night had to have per library support links. I added the ones that I was able to find. If yours is missing, please leave a comment below and ill add it in.
Preview:

| [catnip](https://github.com/mewna/catnip) | Java | [Invite](https://discord.gg/yeF2HpP) |
maybe link to dapi channels for applicable libs (like Eris)?
maybe link to dapi channels for applicable libs (like Eris)?
I've generally been against creating an independent support server for Discordia, and was going to recommend just adding a link to discord-api for me, but if we're going to endorse the servers here, then I will consider creating one. I'll have to think about it.
@tpcstld that is much more idiomatic and obvious. Saying integer or float could be seen as implying they are two different cases.
For consistency, it would probably be more sensible if the API just gave a specific number of decimal places of precision, as well, but I don't see that changing any time soon.
Trust me, I'm familar with the discord api and the (API) ToS.
Wasn't ever implying that you weren't, so apologies if I gave that impression, I realise I probably worded that awfully, sorry about that!
Probably worth making a new issue like Sinister said though. The best solution for now if logging is just the issue (and not the concern of the 403 hard limit) would be to just handle that exception as an edge case until a better solution can be agreed if possible :)
GitHub won't let me make a suggestion because it is outside the scope of what has been changed, but in Gateway.md on line 318:
While not deprecated, Guild Subscriptions have been superceded
While not deprecated, Guild Subscriptions have been superseded
Minor typo that should be fixed :)
Putting a vanity invite that could potentially expire due to boosting tiers might not be smart. The readme uses this link instead: https://discord.gg/r3sSKJJ
Fixed several bits of broken formatting, a bunch of NBSP characters
that are not used elsewhere, and fixed a few broken code examples
(missing semi-colons, et cetera).
Added a table describing the example of the Rich Presence activity
example, since it is not clear to users who have impaired sight as to
how this may look.
This is added in response to
https://github.com/discord/discord-api-docs/pull/2097#discussion_r495313517
on PR #2097 by Mason.
Put this up to go into the feat...
@msciotti, I have put a PR up targeting this branch that completes adding this alt text across this documentation, if you decide to pull that into this:
Ses kanallarına girerken, hoparlör sürekli açılıp kapandıktan bir süre sonra hoparlör kapanıyor gibi görünüyor. Ancak kullanıcının hoparlörü açık olduğu için odadaki sesleri duyabilir. Başka bir odaya geçen ve özel odaya bir böcekle giren kişiler özel konuşmaları duyabilir. Bu çözülmesi gereken bir sorundur.
Merhaba, bu depo API ile ilgili sorunlar içindir. İstemci ile hataları bildirmek için lütfen Discord Testers'a gidin ( https://discord.gg/discord-testers )
Hello, this repository is for issues with the API. For reporting bugs with the client, please go to Discord Testers ( https://discord.gg/discord-testers )
Shouldn't it specify guild channel here as well?
Does it not fire when DMs are closed?
not really renamed, the widget_ fields already existed
- `embed_enabled` and `embed_channel_id` have been removed. Use `widget_enabled` and `widget_channel_id` instead.
were already deprecated
- The following deprecated routes have been removed for better naming conventions:
^^ v7 too.
Technically v7 isn't released as they have said. The whole point of it was for it to be a development preview, so I don't know if there is any expectation that they will provide a deprecation period for undocumented behavior.
They'll probably do what they do with v6, but there isn't technically any reason to be using v7 other than for testing (so not in a production environment). I think there is just the unfortunate issue that a number of libraries made the choic...
Also, /invite/<invite_code> was removed in favor of /invites/<invite_code>
Many libraries use REST v7 but Gateway v6, I don't know any library that uses Gateway v7.
One thing I've noticed, however, is that MessageCreate events seem to be missing for DMs.
The library is probably dropping it because the channel is not cached because CHANNEL_CREATE didn't fire
Many libraries use REST v7 but Gateway v6, I don't know any library that uses Gateway v7.
One thing I've noticed, however, is that MessageCreate events seem to be missing for DMs.
The library is probably dropping it because the channel is not cached because
CHANNEL_CREATEdidn't fire, you would have to update it to not require the channel to be cached
I can confirm this, I don't have an issue with DMs being missed.
doesnt make much sense to have delete/close when we dont have channel create for dms either
I'm not a fan of this PR for a few reasons.
- This adds another link to maintain that can potentially die.
- Project READMEs will already maintain their support invites and won't have to wait for Discord to accept a PR (look at how many PRs have gotten accepted over the last 90 days here -- it'll take forever).
- There's already a link to DAPI which encompasses most of these libraries anyway.
I second @Rapptz's statement. Repositories are linked, and most of them display an invite link at the top of the repository. Failing that, users can go to or through Discord API server.
The docs already had instances of falling out of sync with reality for this particular subject (dead libraries being still listed) in the past, which means this change has potential to cause confusion in the future.
It's easier for people to find the link to any library's support server/channel if they're all listed here in the official library list, instead of going around to library GitHub readmes and websites trying to find a badge or link which may not even be there.
Also, IMO it's better for people to go to the library's official server than a DAPI channel for it, as they have multiple channels and probably have more people with knowledge about the library, and many libraries don't even have DAPI...
Changing wording like this is more than simple s/word1/word2/g job, as I'm not sure this particular word can even be used like this (though I am not a native speaker so do not quote me on that). The statement would, in my opinion, sound better if phrased as "roles allowed to use this emoji" or something to that effect in this particular instance.
@advaith1 @ZoroSC thanks for your input. I'll double-check the library, but I'm looking at raw received events alone, which aren't dependent upon ChannelCreate events as far as I'm aware. May report back when I have more.
many libraries don't even have DAPI channels.
Typically not without a reason though.
It's easier for people to find the link to any library's support server/channel if they're all listed here in the official library list
That would be true, provided the list was updated frequently enough, which it is not.
uh, looks like you commented on the Guild Members Chunk area, which is the response to Request Guild Members, which only needs the presence intent to return presences. If you were talking about Guild Create, that's already documented in the right place.
Is this repository dead? It has been three months since this pull request was opened and it still doesn't even have a label or a comment. It's not very fun to go through all open pull requests to get information on features for the API.
@advaith1 is there any reason to inconsistently use notation between the REST API and the gateway going forwards, or would it be more sensible to encourage things being made consistent across the platform if possible?
I am leaning towards the latter for this, which is partially why I brought it up :)
That would be brilliant, thanks!
oh, so i did. My mistake.
What about the Video permission on the OAuth2 page while creating a bot?
You can add that permission but when authorising the bot I don't see the checkbox.
That permission is only there for completeness so it isn't missing permission, bots cannot use video even if they have the permission.
while it's a useless permission, it probably shouldn't just disappear on the OAuth page

(this happens if you select a permissions integer of 512 which is just the video permission)
Description
CHANNEL_LIST_UPDATE would contain either an array or object mapping channel IDs to their corresponding position when channels are moved in the list, depending on how the Discord client currently holds channel information.
Why This is Needed
Currently, if you move a channel in a big guild, the gateway spams CHANNEL_UPDATE events for all channels in-between channel with position 0 and the channel position of the channel being moved. This doesn't sound like an issu...
I am getting this issue where my client freezes up as-well, I'm also in Tidal.
lol let's hope discord does something about this
Slightly off-topic: Updating guild role positions seems to send multiple guild role update events well.
Slightly off-topic: Updating guild role positions seems to send multiple guild role update events well.
Even thought the max amount of roles is half that of channels, I've seen many large guilds with roles right up to the limit. It also has the same effect on the client, so it is potentially worth doing something about as well.
Slightly off-topic: Updating guild role positions seems to send multiple guild role update events well.
I can confirm that. It sometimes even breaks role order when moving a newly created role to the top of the list.
I've especially noticed this on a 200k member server that almost always goes into an outage everytime we move a role or create a new one.
I've got this in a few places so I'll resolve them all
62e23e6 Retry-After fix - msciotti
fcd2a45 Reset-After fix - msciotti
1b801b3 renamed --> removed - msciotti
its an int everywhere else, just a string here in audit log
de5b1aa Deprecated old invite route, overwrites are str... - msciotti
b16b08e retry_after as a float for consistency - msciotti
27d9ddb Clarify user-relative fields in guild object - msciotti
@nekokatt @tpcstld Is this a bit more clear for these two fields?
1d2ecdf Fix overwrite types in changelog - msciotti
5272bca Channel permission overwrite. - tpcstld
I'm curious, what's the reasoning behind this change? Was it just getting that expensive to send these to bots constantly?
iirc gateway v6 sent a channel_create every time a dm was sent, even if in an existing dm
Should this change have happened as a part of this merge?
It feels like the docs are now out of date.
Apologies if I have been misled or am otherwise incorrect about this.
oooo right, I completely forgot about that >w<
hello discord, I am a user and I noticed two bugs in the call by cell phone, starting with a bug that when you are in a call and changes the other call is going in and out, but it can happen without you being connected, to another bug tbm it is after a while on the call you don't hear anything and you need to get in and out, the same thing with the old bug that was having the robotic voice ... anyway these bugs don't happen so often, but it still irritates me a lot and to my friends who play ...
For customer service please contact https://dis.gd/contact
hello discord, I know I already wrote a text reporting a bug, but the other one is the personalized description, if you put a personalized phrase / text there it doesn't appear, and you need to uninstall and install discord
This repo is for issues regarding the Discord API. It is not a place to report client bugs. To report client bugs, please join the Discord Testers server.
Closing this as we've launched the "view server as role" feature, which you can use to debug permissions.
it doesn't hurt anything for it to be marked as undefined, and offers us flexibility if we need to remove the field in the future.
I don't think we'll change this behavior. As it stands it makes sense to return a 204 consistently since the member exists and the request here is a set manipulation on the member's roles in an idempotent way (both for PUT and DELETE). the RFCs do not make requirements for status codes on these kinds of requests, so it's really up to the implementor on what they want to return.
There is actually no user because it is a webhook. Public server updates just add a webhook to your guild (same as channel following) and then write into the channel it's configured to post into. The user id (webhook id) is unique per guild.
I get that webhook message authors aren't real users, but they walk and quack like one, so I found it surprising that system would not be set here. I don't think we document any behavior for when the author is a webhook or fake user (discrim = 0000). Maybe worth mentioning somewhere down the line.
Description
- Endpoint to fetch a user by Name#Tag (no presence data included)
- Endpoint to search a user by name, nickname, name#tag when sharing a guild.
Why This is Needed
Currently searching a user which share a server with an user is unnecessary hard. You need to fetch all users in order to convert User#Name -> ID. Especially with the new restrictions and intents it become harder.
Alternatives Considered
I couldn't find an alternative way to solve this problem.
**Addi...
-
#1574
-
you can find a member by name in a guild by sending
queryin Request Guild Members without having any privileged intents
#1577 might be helpful too, the REST counterpart of Request Guild Members
- #1574
It's very similar to this issue. I extended this idea with those search methods.- you can find a member by name in a guild by sending
queryin Request Guild Members without having any privileged intents
That's already very useful, but you are still bound on the guild. It would be better to search in a pool of all users which shares a guild with the bot
I'm kinda curious -- what would be your use case? What sort of use case do you have that the current options couldn't solve?
OK I think this is in a good spot. "Final" review requested :)
its an int here, only string in audit log options
| type | integer | 0 for a role or 1 for a member |
Remove CHANNEL_CREATE from the intents list?
DIRECT_MESSAGES (1 << 12)
- CHANNEL_CREATE
- MESSAGE_CREATE
- MESSAGE_UPDATE
- MESSAGE_DELETE
- CHANNEL_PINS_UPDATE
0b86991 String only in audit logs - msciotti
7a84de8 channel create no longer in dms - msciotti
- API and Gateway v8 is now available. v6 is still the default for the time being.
- Channel Permission Overwrite `type`s 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 log `options`.
Hi guys, i try to make autorization by discrord, buy i have trouble with toket.
I not recieved token.
[code]
$chB = curl_init();
$post_opts = array(
'client_id' => '760412233565077514',
'client_secret' => 'FdZK5nVnvL0AOD1RZ58LOZSK0DwcCpjF',
'code' => $_GET['code'],
'redirect_uri' => 'http://127.0.0.1/',
'grant_type' => 'authorization_code',
);
$c_opts = array(
CURLOPT_URL => $token_url,
CURLOPT_POST => true,
CURLOPT_RETURNTRA...
we already now send 443 in the endpoints as of a couple weeks ago
we started retuning 443 for the port on voice websockets, so this should be resolved
9a6495e t e c h n i c a l c o n s t r a i n t s - msciotti
Thanks everyone for your help! Much appreciate. In the changelog, I will also put a link to this commit for reference so that people can see the list of changes for themselves if they'd like.
- remove duplicate overwrite table
- remove duplicate
widget_enabledin oauth example
@msciotti
Missed a tiny detail, the gateway doesn't think the intents are optional anymore and will respond with a 4013 close code when omitted.
@msciotti was there a reason this got closed, out of curiosity?
I think it might have been a side effect of the branch being deleted :blobsweat:
It's late now I'll poke tomorrow.
It seems that suppressing embeds on a message that contains a mention does ping in certain circumstances.
We have managed to reproduce the ping with these steps:
- Person A using Android has their app open and is not looking at channel X in server Y (they are instead looking at another channel in another server)
- Person B using desktop posts a message that contains "@everyone" and a link to image such as "@everyone (sorry for the ping) https://i.imgur.com/ECaZgF2.png" to channel X o...
Hi, since this is not an issue with the docs nor the API, and it is not a feature request either, this is the wrong place to ask such question, instead try asking in DAPI, or reading the docs. This place is to make suggestions/issues about the Discord docs, not asking random questions.
Also make sure to not leak your secrets the next time you ask!
Good luck.
Err yeah. So I can't seem to reopen this PR cuz the base branch is deleted. Is there a chance you could change it to point at master? Then I'll merge this in.
93d34f9 Add json error codes 50024 and 50033 (#1638) - FasterSpeeding
fe8e475 Update Discord URLs in Legal and Policy (#1840) - MeguminSama
b6710f4 Add intents requirement to changelog and update... - MinnDevelopment
Relates to #2106, @tpcstld fyi :)
Let me rebase this when I get to a PC, only just realised there are conflicts
8bc7231 last_pin_timestamp nullability (#1588) - tpcstld
@tpcstld cherry-picked the commit, not sure why the history was completely different to the history when I branched off of the feature branch, but it should be good to go now if you still want to merge it :+1:
This is regarding the bug where the wrong port is sent on voice endpoints, leading to users who do not realise the documentation and API give the wrong details to receive confusing errors.
Original issue this was mentioned in was closed, and I can't seem to find anything else referring to this with updates available, so was wondering if this is likely to be fixed, and if so, when.
Also would like to know what impact this will have on any consumers currently having to use string manipul...
I think this got brought back from the dead. It should be removed. https://github.com/discord/discord-api-docs/commit/74660779261e44142120bae0786213ee87232372
But I'll just merge this and remove it for you. XD
89b149b Added alt text to images, moved GitHub CDN-host... - nekokatt
If we are updating parts of the intro, spectating is no longer an available feature as described here.
Hmm, I've not used the spectating functions myself so I'd need a source on that. Considering all of the spectating docs are still on the site.
would probably be better to make a separate PR removing all spectating docs/references
I agree with you on that, so resolving this for now.
I guess my brain just turned off when I wrote this god knows how long ago lol
78542ee The GameSDK is not open source. (#2117) - trilleplay
API support for inline replies! Be mindful of the different types between v6 and v8. We did this so as to not make breaking changes in v6.
While a new type is generally not a breaking change, in this case, not handling the new type would mean missing out on a lot of messages in chat for things like moderation bots, and we didn't want to break that.
v8 is still new and not default yet, so we felt comfortable using a new type there.
e99cf59 gateway behavior - msciotti
🤔 seems weird to document the reply behavior in the gateway events instead of just the message object instead, unless they don't show in rest?
also I added more message_reference details in #2053 so I'll update that to include reply details
Is it possible for normal users to make inline replies?
@GunnerBasil yes of course! Replies are a feature intentionally for users. We're documenting them for bots ahead of time due to the type changes that need to be handled.
What does a reply look like on v6? Are the fields just missing or does it used the old Replying to x from y / Replying to y format?
It is not guaranteed. Only up to 5 messages who are replying to old messages are loaded. So most of the time will always be there, but if 50 people reply to the first 50 messages in the channel, only the first 5 will be there
Probably worth mentioning that this is also returned on all replies as well, regardless of whether referenced_message is returned, since this is just id's
Oh, also if the referenced message was deleted we obviously won't return it here either
Is it necessary to say that referenced_message is not guaranteed on MESSAGE_UPDATE and MESSAGE_DELETE? They both already make no guarantees except for id and channel_id.
Is there any sort of demo on how these'll look and function in the apps and clients?
My useless contribution to this PR. :nervous_smile:
What does a reply look like on v6? Are the fields just missing or does it use the old
Replying to x from y/Replying to yformat?
The v6 equivalent of inline-reply is afaik the quote. From what I gathered is the inline-reply just a new and fancy version of the "Quote message" feature Discord offers.
So the v6 equivalent would be
> User Message
@UserMention
Is channel_id really needed here? We're already specifying which channel messages are sent to, having a duplicate reference doesn't seem to make sense here.
Would we be able to create a message with only a message_reference param here or would we also need to include at least one of content, embed and/or file?
Extra line here you've added
When I was looking at the Docs earlier I noticed that all of the images in this file were broken because they had invalid directory links. I will be looking through other filed and fixing this.
Current Version:

Updated Version:

This reflects the change in the documentation of the public user flags in the api docs.
Not every issue is a feature request or bug report. Some issues like #2121 is neither and should have a question label if anything. Maybe allowing blank issues instead is better? I'm not really sure what you can really put here for a template.
@ThatTonybo There's partially implemented client-side support in today's PTB (not rolled out yet so you have to be a Discord employee or client modder to enable):

wouldn't those not apply to the message create gateway event?
What about when there is not referenced message? Will that fall under If not present, the backend couldn't fetch the message.?
I assume the intent is to only pay attention to this field if the flag is set, otherwise the flag would be redundant if determinable from the state of this object in the documented behaviour.
It would be nice to get a clear definition of this, though. Even if it duplicates some pattern elsewhere.
Wait, so they send guild_id on REST responses for the inline replies, but not on the messages themselves?
Or am I misunderstanding this
Wouldn't just quoting a message and providing no other content be pointless behaviour outside producing spam, or is there a valid use case for wanting to be able to do this?
Is it necessary to say that
referenced_messageis not guaranteed onMESSAGE_UPDATEandMESSAGE_DELETE? They both already make no guarantees except foridandchannel_id.
Clearly defining what is provided on those events would be nice, purely because it is pointless if you don't have any behavioural guarantee of when they will or will not appear, especially if that differs to what you would expect. It probably matters more to library devs than to people just using the API for ...
Is this expected to be used as part of a work around for the fact that the results of the get guild integrations endpoint are potentially completely arbitrary, incomplete and unpredictable if more than 50 integrations are present?
This was brought up in https://github.com/discord/discord-api-docs/issues/1990 but the issue was marked as too heated and closed without any helpful solution.
Reason I ask is I want to make sure there isn't any "surprising" behaviour that should be expected o...
name: Question about Discord's API or SDK's
We have just discovered that the role create endpoint now has a bucketed rate limit of two days.

It would be sensible to document that these rate limits can be of the magnitude of several days in some case so that it is clear to the developer that they may need to account for these cases. This will prevent developers spending ages wondering why their bots using library X someti...
Hello, I've recently discovered the undocumented encryption option aead_aes256_gcm besides xsalsa20_poly1305_lite, xsalsa20_poly1305_suffix, xsalsa20_poly1305. Since my library language has managed support of it I would like to use aead_aes256_gcm for voice encryption as it removes a dependency (libsodium) from my library.
Is the encryption aead_aes256_gcm considered for usage of bots, since it is not documented by the API docs?
And if so, how long would it be supported? And ho...
Well I sent this before [https://github.com/discord/discord-api-docs/pull/2118#issuecomment-703005795](this comment below), I was going off above comment which seems to be incorrect? Either way clarification would be nice now that i've asked.
when you try to reply to a message via the client, it sends the message with all 3 message_reference fields
which fields are present in the message_reference object in received reply messages?
| description | ?string | the description for the template |
If you provide no description, the description field can be null:

Description
For non-pinging mentions such as mentions in embeds and mentions suppressed with allowed_mentions, they are rendered properly when the user is cached, but otherwise the client just shows the `` format or @invalid-user. This is because non-pinging mentions do not include the user data in the mentions array for the message. On the Android app, it seems to always show @invalid-user for mentions suppressed with allowed_mentions, not even attempting to resolve from cache...
It is not ready for general use yet. There is no ETA as this project has been de-prioritized for the time being.
it may be more sensible to pass a "is_notified" flag in each object that is mentioned. If false, treat it as if it didnt mention anyone.
Since v8 isnt default yet, it would be an ideal time to do this as it is semi breaking.
This isn't needed. Just look at all members with the boost role?
That only says that they have boosted once. What if a user has boosted multiple times? That information just isn't revealed. Also, at time of this issue creation, there was no guarantee which role was a booster role (before role tags were released).
This isn't needed. Just look at all members with the boost role. It's harder but it's doable.
Even though the role tag exists to determine "boosting or not", it's already possible as part of the user json (premium_since) as @msciotti said - determining the exact number of boosts from a given user still isn't possible, but it should be - that's the point of this issue.
Because this PR does not seem warranted/necessary, was opened without discussion of its worthiness nor even a proper pull request description, and may be spam related to Hacktoberfest. We intentionally added this as a small joke to the documentation, and everyone already had the ability to comment on that prior PR before its merge. Copy like this also fits in as a "playful and fun brand that doesn't take ourselves too seriously."
@night I figured "Doesn't look like anything to me" would possibly confuse people when they see it in the docs, and that giving an actual reason as the status would make them realise "oh they skipped from 6 to 8" rather than "hmmm whats this secret v7 api... time to use it to be 1337 hacker".
Pretty sure v7 existed, but was not officially released by Discord.
Pretty sure v7 existed, but was not officially released by Discord.
This PR isn't about the existence of an API version, it's about bad documentation.
If you want to keep the playful and fun brand that doesn't take ourselves too seriously. angle I'd use something like Here be dragons instead, since it's clear but also not as boring as a simple skipped.
I agree that this documentation isn't overly clear. It would be better to be informative and provide something of benefit rather than being jokey and ambiguous as a result.
As a side note, since I've noticed this a lot recently in various places: it would be nice for PRs to be given reasons before being closed without warning. Just out of courtesy for the fact the person who made the PR gave up their free time to try and improve your documentation. Even if it is the worst idea out...
I don't think someone who has previously contributed to this repository should be seen as a spammer. This PR is completely reasonable and just closing it without any comment is, quite honestly, pretty unprofessional behavior. The current way v7 is documented is completely incomprehensible in my opinion and doesn't seem like a joke to anyone reading this as a novice.
everyone already had the ability to comment on that prior PR before its merge.
I didn't even look at the PR since I was ...
Copy like this also fits in as a "playful and fun brand that doesn't take ourselves too seriously."
There's our problem, we need a balance between "haha funny brand for the kiddies" and "we need documentation for our users". You can look playful without sacrificing professionalism.
everyone already had the ability to comment on that prior PR before its merge.
Hadn't heard of the PR until after the merge. (yes, i've lived under a rock)
Also it is Sunday, and not everyone is in the same time zone, so for the majority of this PR, it would have been early hours of the morning for some people.
and may be spam related to Hacktoberfest
BTW just a pointer but a couple of days ago hacktober was made to only cover repos that explicitly opt in to it and since this repo isn't flying the hacktober tag people won't be using it to try to get tee-shirt points. You can read up on that more at https://hacktoberfest.digitalocean.com/hacktoberfest-update
I figured "Doesn't look like anything to me" would possibly confuse people when they see it in the docs, and that giving an actual reason as the status would make them realise "oh they skipped from 6 to 8" rather than "hmmm whats this secret v7 api... time to use it to be 1337 hacker".
We obviously care if there exists confusion, but from what I can gather there is no such confusion being reported with the current copy thus far outside of "what happened to v7." It is also clear from the ...
Labeling it "skipped" would not fix the user confusion in my eyes. Since we skipped v7 there will always exist a subset of people who will ask "what happened to v7?" This confusion will live on until v6 is decommissioned along with v7 sometime next year.
I will stick by my viewpoint that it is quite unprofessional & unhelpful leaving an inside joke in the place of core documentation. Other than saying that, I will argue no more, as it wouldn't lead to anything productive anyways.
Wouldn't these problems be solved by simply labeling it 'deprecated?' Yes it's boring but it also doesn't attract any attention and doesn't prompt any questions about what happened to v7.
We obviously care if there exists confusion, but from what I can gather there is no such confusion being reported with the current copy thus far outside of "what happened to v7."
I mean, the fact that this PR exists means that someone must of been confused... Or that someone thought the chance of confusion was high. Either way, plenty of other playful and fun text still exists within the documentation -- so I really don't see why the removal of one instance is a problem.
Labeling ...
Description
Steps to Reproduce
Expected Behavior
Current Behavior
Screenshots/Videos
Client and System Information
This is probably a problem with your usage of a library. No way to know though, since you left literally all of the issue template blank. It's there for a reason.
sorry i didnt know this is the whole message in console.
04.10 21:28:43 [Server] ERROR ==============================================================
04.10 21:28:43 [Server] ERROR Your DiscordSRV bot does not have the Server Members Intent!
04.10 21:28:43 [Server] ERROR DiscordSRV and its API hooks require these intents to function. Instructions:
04.10 21:28:43 [Server] ERROR 1. Go to https://discord.com/developers/applications
04.10 21:28:43 [Server] ERROR 2. Click on the DiscordSRV...
that is not a bug, just read it and do what it says
yes i go to that link and see nothing? i dont see a bot?
well if you set it up then you must have created a bot there; if you didn't set it up then ask the person who did
this doesn't appear to be an issue with the discord API. good luck figuring it out, however this repo is not the place.
This changes name of the role if type is "role" to name of the role if type is "0" in role_name in the optional audit log info.
Hello, I'm here to report a bug with nitro boosts on the phone.
When you boost a discord server and you are banned within 7 days. In the server boost rebric there is written January 1, 2015 for the date of the boost.

Hey Zehir,
This repo is for talking about the Discord API. For general bugs with the Discord app, you can talk to our support team at https://dis.gd/contact or report them directly in our bug report server at discord.gg/discord-testers
@night it is probably worth noting that since you know the codebase and internal design, it is understandable that you have a greater understanding of the state of things.
For people like us on the outside, we do not have access to the same information you will, so I feel that having a developer of a service being the one to dictate whether they think the documentation they wrote is confusing to other users or not is somewhat biased.
Not meaning to tread on anyones feet or anything, but it ...
The fact that every other comment here seems to be in support of this should make that clear :)
IMO there is nothing wrong with the current wording as it is clear and unambiguous. It clearly documents that the end-user should be using v8, which is all this section will ever show. What the current version is.
IMO there is nothing wrong with the current wording as it is clear and unambiguous. It clearly documents that the end-user should be using v8, which is all this section will ever show. What the current version is.
Here, you dropped this: /s
The fact that every other comment here seems to be in support of this should make that clear :)
IMO there is nothing wrong with the current wording as it is clear and unambiguous. It clearly documents that the end-user should be using v8, which is all this section will ever show. What the current version is.
The current wording suggests to me that it doesn't exist.
Which then is counteracted by the fact several of the largest libraries use it.
If the intent is only to document tha...
and what if it isn't "0"? Should this be marked as being null or missing, or is there a different value here?
Maybe "array of IDs corresponding to roles allowed to use this emoji. If not provided, then all roles can use this.", just to be clearer on the behaviour, perhaps?
I clarified that this field isn't present if the type is "1" in
First of all, do you know how to use discord srv? It is a Minecraft plugin that integrates with the discord api to send messages across both MC Server and a discord guild
With that being said, you should have created a bot already in https://discord.com/developers/applications and linked it for the plugin to be working
What you need to do is go to the bot you're using, and check off "SERVER MEMBERS INTENT" under the "bots" section
This fixed it for me
In addition, you should have opened an issue on the discord srv github instead of here where no one can help you as it isn't directly connected.
Description
Make guild.features a bit integer instead of an array of strings for version 8.
Why This is Needed
An array of strings is wasteful and since server boosting was added, guild.features is more likely to be filled with that data. It's also more flexible to use integers instead of string constants from my experience at least.
Alternatives Considered
I do have something implemented into my library which turns it into an integer. This is what I have ...
Description
Right now do I face random errors with my bot which may look something like this (ID was replaced with 0s):
[ 06.10.2020 22:20:59 WARN ] [JDA [25 / 27] RateLimit-Worker 4] [RateLimiter] - Encountered 429 on route PATCH/channels/{channel_id}/messages/{message_id} with bucket 80c17d2f203122d936070c88c8d10f33:guild_id:000000000000000000:webhook_id Retry-After: 920 ms
The above error basically tells that the library/bot received a 429 from Discord for the Channel...
There is a channel rate limit which affects the message CRUD routes, but other than that shared limit there is not another rate limit you should be hitting on this route.
There is a channel rate limit which affects the message CRUD routes, but other than that shared limit there is not another rate limit you should be hitting on this route.
So what could be a possible issue here then? Like this confuses me for quite some time now as to why my bot gets those warning seemingly random while I use the recommended methods of the Library to avoid such warnings in the first place.
does your bot use multiple processes? they might not communicate ratelimit info
does your bot use multiple processes? they might not communicate ratelimit info
What exactly do you define as multiple processes? Like using several cores, or asynchronous handling?
Because the library I use does handle stuff async when using their queue method, but this shouldn't be an issue here.
Advaith is asking if you're clustering (using several separate programs, and in your case it would be multiple JDA instances).
In that case.... No? Like I do use sharding using JDA's ShardManager, which handles several JDA instances. But I just point out again that JDA was build to respect Discord's rate limit in any way possible.
On the topic of this and the linked issue, I noticed that the delete message bucket now alternates between itself (3 / 1 sec), and 80c17d2f203122d936070c88c8d10f33 (5 / 5 sec), which is shared with the post message and edit message endpoints. Since I read somewhere that the delete message bucket is separate and faster to accommodate moderation bots, I was wondering whether this is intentional.
which is shared with the post message and edit message endpoints
That definitely sounds like a problem and could be the cause of this. The bucket for delete message should be fixed and have a constant bucket hash.
I also noticed that crossposted messages have a different rate limit. A crossposted message can only be edited 3 times per hour and that rate limit is not shared channel-wide but per message. It seems like there are a lot of inconsistencies that need to be addressed here.
The published message edit ratelimit has the 20022 json error code
The published message edit ratelimit has the 20022 json error code, so that can be checked for separate handling
Except you only get that when you actually hit the rate limit, which a library is supposed to prevent by doing preemptive handling through headers.
Regarding this pr and crossposting, will replies be unable to be crossposted? Or (what would be pretty neat) is if the reply's would get auto attached to crossposts through the same methods editing a crossposted message.
Also couldn't help but think since maybe there should be different property naming, there would now be message_reference and referenced_message, which could be pretty confusing.
documented that this is returned on replies; pending on #2118
I think the concept is that you can inline-reply to any message maybe? Like looking at the comment below showing how it looks client side, it doesn't seem to be replying directly to the message, rather creating a separate message mentioning that message. Maybe not in the client (just cuz it seems kinda impractical), but in the API, might be able to send reply's to a message in a different channel than that of which that message is from.
Also is https://github.com/discord/discord-api-docs/pull/2118#discussion_r500679312 true? Because that seems to be what it looks like.
it would be useful (and was technically possible in replies v1 by typing out the syntax), but in the line it says
the channel id of the referenced message must match the channel that you're sending the message in
hopefully it gets changed tho
Also I saw some chatter about the fact that deleted messages will just return null.
What about on the client? If the referenced message gets deleted, will the reply be removed? Or will it do something similar to crosspost like replace it with "[Original message deleted]"
This will suffer from the same problem that permissions suffered from as Discord adds and removes features, which is quite often.
v8 ship has sailed, and these are strings because we have many guild features, we'd run out of bits.
v8 ship has sailed, and these are strings because we have many guild features, we'd run out of bits.
Are you implying that it isn't possible to use the same workaround as you did with permission bits? Discord definitely has the capability to use string-serialized numbers to overcome the bit integer limitation.
This will suffer from the same problem that permissions suffered from as Discord adds and removes features, which is quite often.
I'm only aware of 13 guild features—the ...
There is quite a few internal ones too.
There seems to be no benefit to moving from an array to a string at the cost of duplicating the information being sent. I can see why this would be nice to have but adding a features_new field seems wasteful and redundant. Would be nice for v9 though I suppose.
To be fair in logic if someone (for example) DMs you on Discord, you wouldn't reply to them by text (SMS), that would just be weird. I'd probably expect the same here but with channels. In which case if that is true then channel_id definitely won't be needed
The Discord client with the inline replies experiment enabled can reply to any message from any channel without the restriction of the channel being the same.
Are users/bots able to edit messages to add message references?
FYI, the rate limit for role create is not new, and it has in fact existed for more than a year.
Anyway, I just wanted to comment on the "general assumption" on long rate limits. It is funny how we sometimes forget the most obvious things - such as modifying current user endpoint in this case, which has a pretty long timeout too (and you probably know about it).
This field will only appear for replies at the moment.
"Normal" (type 0) messages won't have it, because if they have a message_reference, they're crossposts.
Regarding the comments, the one below is a screenshot of the feature in action, and the one above is incorrect. Quoting will be replaced (not markdown removed however), but it's not nearly the same thing. When replying to a message it auto fills into a "@user ", it's pretty much the same content field as sending a normal message. So if I had to make an educated guess some sort of message content will likely be required, while yes quoting doesn't require it, that's because the quote itself cou...
It'd be nice to see the props replaced with something like reply_to & replying_to or something along those lines. They could obv still be documented as message reference objects and not have cross-references to completely different features.
A message is still required to have a content, embed, or file regardless of message_reference.
Well this is both true and not. In DMs yes, however being able to reply to something in a different channel in the server the message is in, doesn't come off as unworldly. It'd be neat to see, maybe even for like logging purposes? Being able to reply to the message in a log channel per say to keep track of it. Or replying to like an announcement in a general chat for users. It doesn't seem like something that shouldn't happen, but still might not.
And I'm struggling to comprehend the fact that
message_referenceis now both in POST and message object and meaning completely different things and I'm looking at the PR explaining it all.
Could you elaborate? They should mean and represent the same thing. A message_reference is comprised of guild, channel, and message ID fields.
If the referenced message gets deleted, will the reply be removed? Or will it do something similar to crosspost like replace it with "[Original message...
Could you elaborate? They should mean and represent the same thing. A
message_referenceis comprised of guild, channel, and message ID fields.
A referenced message is not mutually exclusive to the message_reference field. They're separately documented, and properties could be renamed without changing how the documentation/functionality of the object works.
The issue that is coming up for me is that crossposted messages & replying messages use the same properties, and this could be v...
hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii https://discord.com/api/oauth2/authorize?client_id=735595156069417051&permissions=8&scope=bot

GitHub - Social Media for Developers
Btw, please don't make an issue just to advertise your bot lol. People are probably subscribed to this repo, including me.
There is quite a few internal ones too.
Bit-shifting aren't going to be affected by internal ones. They can skip some shifts as they did with INLINE_REPLY (15, ..., 19, etc).
There seems to be no benefit to moving from an array to a string at the cost of duplicating the information being sent. I can see why this would be nice to have but adding a
features_newfield seems wasteful and redundant. Would be nice for v9 though I suppose.
I'm not sure where you got the idea that th...
Description
Bots that are on fewer than 100 guilds, but have ever been on more than 100 guilds, are unable to enable privileged intents.
Steps to Reproduce
- Run a bot for 5 years
- Experience slow natural growth
- Manually have bot leave all but 99 servers
- Attempt to enable privileged intents
Expected Behavior
It was expected to be able to enable privileged intents once the bot was on fewer than 100 guilds
Current Behavior
The boxed for privileged intent...
Although I like the idea of it being an integer and I may very well change my library to do it like that, I still believe changing it now after v8 has been released/documented would be a breaking change and therefore must bump to v9.
I would not say that this is very important, but the table on the page in GitHub is not displayed correctly (more precisely, it is not displayed at all)
https://github.com/discord/discord-api-docs/blob/master/docs/dispatch/Error_Codes.md

Everything is well displayed on the site
Seems everything is one long line, instead of being broken up with newlines. Should be easy enough to make a PR for
Description
As of late, discord has started forcing the notion of stateless bots. This however doesn't really work well when the API is literally designed to update state (the client). Currently, events only provide the new state of the updated entities. It would make it a lot easier for bots to be stateless and not require loading members if discord would provide the old state, or at least provide some way of identifying what changed.
Why This is Needed
Many mode...
this issue tracker is for discord API and docs bugs and feature requests, not for random chat or advertising
To prevent potential abuse, once a bot is required to submit verification it is no longer possible to toggle these flags on the client side. If you have other issues precluding you from verifying I would recommend reaching out to our support team at https://dis.gd/contact
Do you really think a bot that has been non-malicious for 5 years would suddenly start abusing things? Besides, what potential abuse could come from disabling access to these intents?
Frankly, this information would have been nice to know as soon as the verification system was announced, so that people could have pre-pruned their bots to below the threshold so as to not render the bots useless now. Lots of "hobby-project" bots (that are likely not qualified to be verified) were previously public for ease of adding for friends, but if they happened to hit 100 guilds, they will be permanently broken as of today.
As an addendum, there are several reasons why someone might intend to keep a bot unverified:
- They want to be able to change the bot's username
- The bot is not kept online consistently enough to merit verification
- They intentionally want a hard limit on the number of guilds a bot is in (ie keep hosting costs minimal)
- Their bot's feature-set changes or is inconsistent (hobby-project bot)
**If a bot that is intentionally unverified, or not eligible for verification, happened to hit...
Description
This feature would allow bot owners/developers to set a hard limit on the number of guilds to which the bot can be added during the regular bot oauth flow. If the limit is reached, users cannot add the bot to any more guilds.
Why This is Needed
Some bot developers choose to not verify their bots and may wish to keep their bots in less than 100 guilds to continue operating fully (see #2134). Without a hard limit, your bot's privileges may be in the hands of the use...
The issue that is coming up for me is that crossposted messages & replying messages use the same properties, and this could be very confusing for people, example if someone ctrl+f's to find what
message_referencemeans they could get two completely different meanings, it's just asking for trouble.
Most of my confusion stems from how message_reference here is being used exactly by its name: we're referencing another message. #2053 documents that this is how it's used — including for t...
Considering that bots with privileged intents cannot be added to 100+ guilds, perhaps enabling them even when not in use could be a workaround until Discord implements a proper guild limit.
Are users/bots able to edit messages to add message references?
Not supported at the moment. Do you have any compelling use cases?
With the original (client-side) replies, sometimes I edited replies into my messages after sending to clarify what it was responding to
It is my understanding that the bot can be freely added to up to and including 100 guilds, which triggers the verification requires flag.
Really? That's it? If the scope of your bot changes to need these intents in the future after verification, you're screwed, thanks for playing? The thought that people might want to reapply for these intents never crossed anyone's mind? This feels like an incredibly hostile decision, and I'd urge you to reconsider.
@Ratismal hmm, what? you can always apply for more intents after you're already verified.
night's comment is only for enabling limited intents (for small bots); for requesting whitelisting the process is currently making a support ticket and it'll be added to the dev portal in the future
There are also two other events
INTEGRATION_CREATE
{
"t":"INTEGRATION_CREATE",
"s":25,
"op":0,
"d":{
"user":{
"username":"Erk",
"public_flags":131584,
"id":"77469400222932992",
"discriminator":"2048",
"avatar":"ca38426aca0884f0b636a6d588131b96"},
"type":"discord",
"name":"Dumblebot",
"id":"763674548452851712",
"enabled":true,
"application...
I can think of a use-case for example if an user uses a banned word it could be quoted and explained to user as active feedback.
@Stonedestroyer Why does that have to be an edit? Wouldn't it just be a normal reply?
@oliver-ni User would see what word it was and who it was aimed for. So it makes ux better. But it was an example. Not sure what you mean by edit.
Description
The Modify Guild Member API endpoint, documented here: https://discord.com/developers/docs/resources/guild#modify-guild-member, fails with the following error when trying to modify the nickname of the owner of the target server/guild:
{ ["message"]=> string(19) "Missing Permissions" ["code"]=> int(50013) }
Steps to Reproduce
Send the following payload: {"nick":"New Nickname"} as a PATCH request to the endpoint: ``https://discord.com/api/v8/guilds/SER...
intended. due to role hierarchy, you cannot modify the nickname of anyone above you, and the server owner is above everyone else. you can also not manage any roles above your highest role.
Then there should be more links to this section because I never came across to it (and I expect most people implementing something don't read the doc from A to Z before doing anything you find the relevant information first). And it is frustrating to figure out what went wrong until someone told me about this potential restriction.
I was aware of the role management constraint but a bot can still grant a role to the owner of the server.
Or Discord could introduce a new JSON API erro...
The bigger question here is why is this considered reasonable in the first place when other endpoints raise 400 for this kind of case?
It would be better for this to raise the 400 that the patch user endpoint returns, or did return last time I checked, if there is to be any consistency with how to handle these...
This could be extended to also provide the full message payload when a message is being deleted, so that we actually can know what got deleted in the first place.
This would fall in line with moderation of message edits. The current message delete format is pretty useless in terms of the information it gives you (no content, no idea who sent the message, no idea if it had embeds, no idea if it mentioned everyone (e.g. ghostpinging), no idea if it was pinned, etc)
Wouldn't it be easier to just say "give me every object, with all fields, all the time"? Message delete is not the only "empty" event, but it's probably the one least-likely to receive any more information because of privacy.
@SinisterRectus if only, that would make implementing a consistent interface for the entire API significantly easier and simpler...
@oliver-ni User would see what word it was and who it was aimed for. So it makes ux better. But it was an example. Not sure what you mean by edit.
They were asking for use cases of bots being able to edit messages to turn them into replies, not just normal use of replies from bots which is already going to be supported.
Description
Hello, then doing a request to GET /users/{user.id}, we can't tell if a user is deleted or the username is
'Deleted User XXXXX", so i would like a way to know if an account is deleted (kinda like bots) with a value of deleted:true then an account is deleted.
Why This is Needed
As you may know, there's a law called GDRP, and i support this law, so i would like a way (as projects owner) to delete data from deleted users.
Alternatives Considered
The...
IRCC Discord will email bot developers when a user is deleted.
However, since user deletes are more common place nowadays, it would be nice to distinguish deleted users with a flag.
Additionally, a gateway event for when a user the bot can see is deleted (probably under the MEMBERS intent) would allow for automated data deletion.
802633c Storage: added GetPath return type, WriteAsync ... - NathaanTFM
Weird we have this as 4 in one place internally. Lemme follow up to see what's up.
| flags? | integer | [message flags](#DOCS_RESOURCES_CHANNEL/message-object-message-flags) combined as a [bitfield](https://en.wikipedia.org/wiki/Bit_field) |
5a74b97 Document default avatar image sizes being const... - FasterSpeeding
Btw bots should now be fully allowed to manipulate guild templates.
thanks upside down cyan A, I'll make a pr for that
71cdf5b Audit Log: use new overwrite string in role_nam... - cherryblossom000
1337c50 Fixed Status.DoNotDisturb enum (#1898) - NathaanTFM
@Lachee where did you get that info about discord emailing bot devs? that makes no sense
@Suspense4615 This was mentioned during the API ToS Q&A in the Discord API server back in mid-2017. See this summary gist that mentions the email thing at the very beginning.
As far as I'm aware, that exclusively applies to user-requested account deletes, and not account deletes by other means or reasons- guessing based off the number of deleted users I've seen on guilds my bots are in and the complete lack of any such emails.
This is both a migration issue and an abuse issue. On our end, applications are in one of four states when it comes to verification
- Ineligible (have not met the 76 guild requirement)
- Unsubmitted (you, at some point, crossed that threshold)
- Submitted (you have an active application submission)
- Approved
Right now, the code is checking if you are in an ineligible state to be able to flip those toggles. Otherwise, you cannot.
If we were to make it check for unsubmitt...
Can't it just be purely tied to guild count, checking if it's below 100 or not? That's what it was implied to be before
Can't it just be purely tied to guild count, checking if it's below 100 or not? That's what it was implied to be before
This is an expensive query for us to do. On OAuth pages, we keep an estimated count. An exact count of above/below 100 is expensive to compute, and we have flags specifically for this reason.
I agree that this is likely does not affect a large percentage of bot developers, and with the new knowledge of how this works, hopefully it can be avoided in the future. Therefore, handling it manually for existing cases sounds reasonable. For people this affects, should we open a support ticket?
If we were to make it check for unsubmitted as well, [...]
For that case, I'd highly suggest being able as a dev to limit your bot's server count, as to never hit the 76 guild requirement (and cross into the unsubmitted category, thus never being able to enable privileged intents)
- Unsubmitted (you, at some point, crossed that threshold)
This doesn't necessarily mean they can apply though; if you drop below 76 before submitting, then it will not let you submit the application, but it seems that it also prevents you from enabling limited intents. Someone actually encountered this issue in DDevs (link).
This is all a long way of saying that before we go spend a bunch of time changing the system and dealing with the abuse cases that will occur, for how many people is this a problem? I know that your bots are in a unique case. Perhaps we can see if we can just handle this manually, as it won't be an issue for new bots going forward?
There are a more people waiting on the outcome of this situation. They don't want to verify their "large" bots, but they don't want to lose member/presence fu...
Considering that bots with privileged intents cannot be added to 100+ guilds if it isn't verified
This is actually not the full picture. Any bot--regardless of intent requirement--cannot be added to over 100 guilds. That's why I'm not sure I understand the use case of this feature suggestion? You do effectively have this limit already, it is 100 servers. A bot that is currently in under 100 servers cannot join a 101st without getting verified.
The only other thing that currently trigg...
They don't want to verify their "large" bots, but they don't want to lose member/presence functionality, so they are considering pruning down to below 75/100 guilds...maybe you could handle the amount manually, but remember that one of the premises for the introduction of intents/verification was that the bot count was small enough to handle, yet you guys were overwhelmed by the response
Yeah, this is what I mean by a "migration" issue. Whenever you have a restriction occur on a date, th...
Well, first and foremost, it is impossible for new bots to pass that threshold in the first place.
@msciotti if I understand correctly, intent restrictions are imposed after 76 guilds not 100 - which bots can freely surpass
Yes, what kittens said. This is the issue I'm highlighting here and with #2138; that it is likely that developers will unintentionally and irreversibly enter the unsubmitted state.
I see. So if I can parrot this back to make sure that I understand it:
For new bots, they can enter the unsubmitted state. This causes them to no longer be able to join more guilds (that's fine), but also disallows them from toggling privileged intents.
So, if for example you decided in the future that you need Presence data for some new feature of the bot, you can't turn it on.
The problem is not entering the state, but that toggle ability.
Understood. This is a complex ...
Seems like we're on the same page. Thank you for your consideration. Hopefully you find a solution.
Yes, I opened this as a reaction to the intents issue. I'd say that lack of resources to maintain a large bot, for example, did not inspire me to post this request because there is a reversible fix for that. If you join too many guilds, you fix it by leaving some. #2134 is not fixed by leaving guilds, except now by your offer to work with developers via DMs.
Description
When trying to create a server template when it already has one, it returns error 30016 with a message about invites.
Steps to Reproduce
- make sure a server has a server template
- POST
/guilds/:id/templateswith a body includingname
Expected Behavior
an error that mentions templates; either just edit the message of 30016 or make a new error code
Current Behavior
{
"message": "Maximum number of invites to this server reached.",
...
Since this is the direction the industry wants to go, then I'll raise the alarm on "black magic". Ref: https://discord.com/developers/docs/topics/community-resources#embed-visualizer
Since the narrative is that "black" and "white" are now always going to be associated with race because we can't see that referring to two groups of people with words that are polar opposites in almost every other context is fighting an impossible battle (and that there are many, many other contexts that preda...
Is this issue fixed, because it says closed, which I think means fixed or not going to fix, and I'm personally wondering if Discord really considers this an problem worth fixing and reading the comments gives me mixed messages.
@Lachee no, that's not what i meant, a way of knowing if other users have a deleted account, not ourself... simple as that ¯\_(ツ)_/¯
Document server template routes that bots could not access before (https://github.com/discord/discord-api-docs/pull/1712#issuecomment-705921398)
@Lachee no, that's not what i meant, a way of knowing if other users have a deleted account, not ourself... simple as that ¯\_(ツ)_/¯
Yes, that is what I am talking about.
@Lachee well, no? why would Discord sends you an e-mail every times a users get deleted? Having this info in the api's responce is more efficient...
@Lachee well, no? why would Discord sends you an e-mail every times a users get deleted? Having this info in the api's responce is more efficient...
thats why I am suggesting it???????
Additionally, a gateway event for when a user the bot can see is deleted (probably under the MEMBERS intent) would allow for automated data deletion.
@Lachee ah, i see... that's wierd from Discord tho
Previously the docs didn't specify if, or how, some array entries are sorted, so you'd have to figure it out yourself by requesting an endpoint and inspecting the response.
For example, it might not be immediately clear that the Get Reactions endpoint sorts users by ID instead of in the order they reacted in. Additionally, while most endpoints use ascending ID ordering, some other endpoints such as Get Channel Messages sort items in reverse.
This PR aims to document that behavior and the ...
Returns the messages for a channel. If operating on a guild channel, this endpoint requires the `VIEW_CHANNEL` permission to be present on the current user. If the current user is missing the 'READ_MESSAGE_HISTORY' permission in the channel then this will return no messages (since they cannot read the message history). Returns an array of [message](#DOCS_RESOURCES_CHANNEL/message-object) objects on success, sorted by their id in descending order.
Returns a list of [guild member](#DOCS_RESOURCES_GUILD/guild-member-object) objects that are members of the guild, sorted by their ids in ascending order.
Returns a list of partial [guild](#DOCS_RESOURCES_GUILD/guild-object) objects the current user is a member of, sorted by their ids in ascending order. Requires the `guilds` OAuth2 scope.
Get a list of users that reacted with this emoji. Returns an array of [user](#DOCS_RESOURCES_USER/user-object) objects on success, sorted by the user ids in ascending order.
Since this is a patch request, the name is also optional, right?
That makes no sense for a patch request... What if I want to modify just the description?
Description
Webhooks for my action runs started receiving 400s starting around 6:55PM PST. The 400 responses have a response body of {"check_run": ["check_suite"]}. I'm currently getting about 3/16 webhook messages successfully delivered.
Steps to Reproduce
- Create an action on a repo
- Set up a Discord webhook
- Run the action somehow
- Observe the lack of a message
Expected Behavior
A webhook message is sent
Current Behavior
No message is sent
I forgot that API v8 isn't the default yet :pensive: Here's the v8 error:
{
"code": 50035,
"errors": {
"check_suite": {
"pull_requests": {
"0": {
"title": {
"_errors": [
{
"code": "BASE_TYPE_REQUIRED",
"message": "This field is required"
}
]
}
}
}
}
},
"message": "Invalid Form Body"
}
Upon further investigation, it seems that the PR title just isn't being sent anywhere at all in the actions payload, which explains why this borks.
This is a good point. I'll look into changing this, along with the other templates-related issue.
8ec82a3 Document features being returned in Get Current... - advaith1
a926694 Document application integrations (#1886) - advaith1
Regarding the serialized_source_guild property, it's relatively unclear without looking at the returned JSON which properties may or may not be present (and that continues down into roles and channels of that object as well). Perhaps it's worth documenting those three separately from the main guild object? Another motivation for that would be that the main guild object contains a number of fields that would be completely irrelevant for a template, such as the owner ID and the permissions of...
This is an attempt at continuing #2127's discussion.
To summarize the discussion of that PR: The current wording of the status of v7 API and Gateway, "Doesn't look like anything to me", is potentially confusing. The PR was made to change the wording, so that it was more clear for beginners of the API that v7 is discontinued, skipped, whatever -- that you shouldn't use v7 because v8 (a better version) is already released.
The PR was closed by night for a variety of reasons, including bei...
This did actually came up (somewhat tangentially) in #elixir_nostrum in DAPI: #381889573426429952 message

you could say wild missingno. or something
Discord is kind of known for their gaming brand, so I'm suggesting that the joke should be more gaming related. The example I gave above is from Pokemon's missingno bug

They moved away from the whole "I'm big gamer, hello" branding when they moved to discord.com, sooo...
Jake talked about it in DAPI [start link](#381887113391505410 message), tldr its a westworld reference and it's clear enough that you should be using v8 so it won't be changed
I know. :) But not everyone reads that channel. There's a discussion open on GitHub for a reason.
I know. :) But not everyone reads that channel. There's a discussion open on GitHub for a reason.
Not everyone follows every discussion that happens on this repo either :)
I'll get around to these changes this week, thanks folks
Closes #1472
Maybe there is a better place to put this but it seems like the most fitting to me.
I wrote a lot of this as I was doing research, but I need to start with:
I. Am. Mad. I read that 2018 journal that everyone is in a tizzy about (second link in @Fyko's post). I actually read it. I am angry that this garbage is what people consider remotely good enough to upheave an industry on. I am furious that people read this and think that it's okay to shove that bloke's utter garbage down the throats of hard-working engineers ...
I just want to make a quick note for all those struggling on iOS (like myself)
Discord seems to have problems with custom schemes (read: anything not http/s). When working with redirect URIs using libraries like OAuthSwift, it's better to have a custom domain redirect that sends the client back to your app. Even though Discord's online OAuth settings accept a custom scheme likemyapp://authorize, you will get this same 'invalid redirect_uri' error.Instead, the solution I ende...
Logic and Reason has finally entered the thread.
@mr-tech Please publish that as an article somewhere so more places can see it, I feel like this is something the entire industry needs to educate themselves on before it's consumed by some woke agenda. We've already seen other industries be consumed by a woke agenda, and it's most visible in the entertainments industry... just look at TV Boxsets made within the last 3 years and compare it to boxsets from 10, 15 years ago (if they haven't been removed because users on Twitter pressured compan...
I don't see how this is more more inclusive. Am I missing something? I don't see how whitelist includes less items then allowlist. If you mean inclusive as in more people, that makes less sense to me. Like does words like white space deny anyone of anything? I don't see how anyone is considering the words whitelist or blacklist limiting someone's ability to read the API docs or use the API. If anything, I feel that it'll cause more confusion as they aren't the usual terms used and say...
This seems to be connected with #1886 As the application field is the one present here.
Before Discord starts deleting these comments, I'd like to chip in myself.
Unfortunately these types of issues have been spreading recently, some of you might of seen the changes in other places.
I've found that the people who suggest these changes usually only come armed with the four same "articles" who's scientific base, is well, dubious. As made by @mr-tech's superb points. Surely if this was such a big issue there would be thousands of articles and actual scientific research done on i...
There are more than 4 places where the API returns an array. Are those not sorted?
...honestly I kinda forgot that there was more I needed to document lol.
I've had a quick look and found all these additional endpoints to return an array:
- Get Guild Audit Log
- Get Pinned Messages
- List Guild Emojis
- Get Guild Channels
- Get Guild Bans
- Get Guild Roles
- Get Guild Voice Regions
- Get Guild Invites
- Get Guild Integrations
- Get User Connections
- List Voice Regions
- Get Channel Webhooks
- Get Guild Webhooks
I know not all of them are/can be sorted, b...
- Get Channel Invites
- Modify Guild Role Positions
Modify Guild Role Positions and Channel Positions are depending on YOU to provide the positions, the API doesn't return it explicitly afaik (certainly not on the mentioned endpoints; however a note on how the client does sorting would be appreciated at some point), documenting those seem out of place, right?
Guild features are returned in a randomly sorted array and the client stores them as a Set
Modify Guild Role Positions and Channel Positions are depending on YOU to provide the positions, the API doesn't return it explicitly afaik
Modify Guild Channel Positions only returns 204, not the set of channels. Not sure why. Modify Guild Role Positions returns all roles, not just the ones you sorted. They appear to be in snowflake order.
a note on how the client does sorting would be appreciated at some point
I agree. I've asked about it in #881 and #1277 and did not receive a...
Alright, I've added some more endpoints. Some takeaways:
- Voice Regions don't seem to have any sorting, and even if it wouldn't make much sense.
- I couldn't find any ordering for Get Guild Integrations; it's neither by id nor application ID apparently.
- TIL invites are sorted by their code in alphabetical order. The client UI sorts them by author name.
- User connections are sorted alphabetically by connection type ("github" - "spotify" - "youtube" etc); I can't test how they're sort...
Jake talked about it in DAPI
I just want to say that I was there -- and Jake refused to even have the discussion in the first place. I could understand if Jake believed that the change was unwanted, but Jake outright refused to have discussion on the matter.
Since it's clear to me that even attempting to have a discussion is unwanted (even though that was one of night's reasons for closing the PR), I cannot see myself continuing my part of the discussion. Unless someone on the team wa...
Can confirm, this is a pretty large issue that significantly affects user experience
Please get involved and support actual meaningful change in the world rather than useless slacktivism. Look into your local political organizations to see if you can volunteer (current pandemic permitting) or donate to the NAACP or similar.
Changes like this don't accomplish anything. At worst they alienate apolitical people by associating real political activists with what some would deem "snowflakes".
Instead of trying to make yourself feel...
"whitespace" within the Contributing guidelines (is there an alternate word for whitespace?)
What? Why change this? I am pretty sure this word originates from printed paper... which is well, white.
I agree. I looked at "Doesn't look like anything to me" and I was like what is this and literally gave up reading that documentation for a day.
Playing devil's advocate for Discord here, if you see "Doesn't look like anything to me" and instead of, I'm not sure, asking a question and instead you just literally give up reading documentation. That seems like more of a problem with how you feel about a joke than anything about the actual text. It would take 30 seconds to make an issue or ask in the DAPI/ddevs server.
fwiw I think the wording isn't great either. Just pointing out that last comment is absurd.
Jake talked about it in DAPI
I just want to say that I was there -- and Jake refused to even have the discussion in the first place. I could understand if Jake believed that the change was unwanted, but Jake outright refused to have discussion on the matter.
I don't believe it is a topic worth discussing. It's not confusing that you are expected to use v8. Often times open source repos have issues and pull requests like this which aren't important and just end up locked for bein...
Is there any endpoint that invalidates discord token ?
No, but at this point, pushing discord tokens to a Gist is rather common.
Well, there are a number of ways to respond to what this PR has turned into. I will keep it simple.
Someone went through the effort to suggest these changes and open a PR with said changes knowing that it would be poorly received. We have people internally at Discord who are happy to see these changes. So, I would state that factually, people do indeed care about this.
While replies to this topic have been opinionated, I do not think they are intended to be disrespectful (though strong ...
In other words, today we learn that it's okay to ignore an overwhelming majority shown here:

if it makes a few slacktivists at Discord happy.
Seriously?..
@msciotti Agreed, people do care about this. My essay proves that I care a lot (more than I'm comfortable caring about it. I wish I couldn't care tbh).
Discord's decision is Discord's decision. I said my piece on the topic and will let it go.
Moving forward, I think it is important to define under what understanding of "inclusion" these changes are being made so that people can properly evaluate the rest of the documentation for similar changes that must be made under Discord decision. ...
Any entities with an ID included in the list of IDs will be mentioned. Note that IDs of entities not included in the content will have no effect.
Perhaps rephrase it to this?
Same as above. Roles don't use emojis; members/users do.
This changes the semantics of the statement. Poor grammar aside, "roles this emoji is whitelisted to" makes sense while "roles allowed to use this emoji" does not because roles don't use emojis; members/users do.
Same as above. This is now redundant. "A disallowed intent is one which you have not enabled for your bot or one that your bot is not allowed to use." -> "You are disallowed to use a disallowed intent." It should explain why you are disallowed.
Same as above. Roles don't use emojis; members/users do.
This is now redundant. "A disallowed intent is one which you have not enabled for your bot or one that your bot is not allowed to use." -> "You are disallowed to use a disallowed intent." It should explain why you are disallowed.
I'd honestly prefer to keep the original phrasing of the last part of the sentence. i.e.:
Any entities with an ID included in the list of IDs will be mentioned. Note that IDs of entities not included in the content will simply be ignored.
A bit more clear to me
"whitespace" within the Contributing guidelines (is there an alternate word for whitespace?)
I'd say bluespace. Some editors have a dark blue-ish background, and it reminds me of empty space on a blueprint.
Repository maintainers should really give a second consideration to locking discussion on this PR from non-involved parties, this PR has been posted on several 4chan related community centers and it's going to get flooded with armchair sociologists who will completely miss the point of this PR in order to concern troll.
I support this PR, it's a good change with the exception of one nitpick;
Would authorized/deauthorized be a better replacement than allowlist/delimited?
It'd ...
What if we just swapped the meanings of blacklist and whitelist? Blacklist would be things that are allowed and whitelist would be things that aren't allowed.
"whitespace" within the Contributing guidelines (is there an alternate word for whitespace?)
I'd say bluespace. Some editors have a dark blue-ish background, and it reminds me of empty space on a blueprint.
I thought whitespace wasn't going to be changed?
"whitespace" within the Contributing guidelines (is there an alternate word for whitespace?)
I'd say bluespace. Some editors have a dark blue-ish background, and it reminds me of empty space on a blueprint.
I thought whitespace wasn't going to be changed?
Ah, my apologies then.
how about if not empty, only members with at least one of these roles can use this emoji ?
maybe rewrite the entire paragraph to
If you specify an `intent` value in your `IDENTIFY` payload that is *disallowed*, the socket will close with a [`4014` close code](#DOCS_TOPICS_OPCODES_AND_STATUS_CODES/gateway-gateway-close-event-codes). A disallowed intent is a privileged intent that has not been activated for this bot. Bots in under 100 guilds can enable these intents in the bot tab of the developer dashboard, verified bots have to request discord to activate these for the bot ...
and the testers feature is no longer needed. might can be lift out i think, or maybe and RPC features of your app will be available to all users
@Iamgoofball if you really want better terminology, allowed/denied would fit in most places.
allowlist/denylist just sounds stupid.
The hook property in GET /oauth2/applications/@me is not properly documented in the documentation site.
Also what does the hook property mean anyway since it's not documentated on any libraries nor on the documentation site for it?

What I gotten:
{
id: '531613242473054229',
name: 'Nino',
icon: 'a822e90063fd0359d15fdf6ad3af64de',
description: 'Discord moderation bot',
summary: 'Discord moderati...
This is mainly for the client. And related to games.
Hook controls whether or not the overlay and other things are allowed to default hook a game. Let's us turn it off quickly if it's causing crashes.
Is this still relevant?
Far as I know
Are you suggesting that I redirect to any http(s) domain, which in turn redirects to my custom scheme?
Seems like the best way to solve the problem at the moment, and it's what I had to do
If you want to use a custom scheme you must employ PKCE on your authorization flow. Learn more at https://oauth.net/2/pkce/
allowlist/denylistjust sounds unnatural, like someone just ransedon the repo and called it a day
grantlist/blocklistkeeps the same number of syllables and characters aswhitelist/blacklist.allowlistanddenylistjust do not sound "smooth" or "good."
I see nowhere in the documentation that mentions support for PKCE
Ridiculous PR that was done for nothing more than virtue signaling, you would literally accomplish more by donating 5$ to some charity than changing most instances of a word
In all fairness, at least it's not as bad as Github's own "replacing slave/master with something more inclusive" change prompted by some american movement protesting a black man's death, which ironically turned out to be racist because it implied only black people would be slaves and not, you know, literally anyone for m...
allowlist/denylistjust sounds unnatural, like someone just ransedon the repo and called it a day
grantlist/blocklistkeeps the same number of syllables and characters aswhitelist/blacklist.allowlistanddenylistjust do not sound "smooth" or "good."
I propose avoiding Xlist and Ylist since that will only invite more confusion being terms that don't actually exist and aren't any more descriptive than whitelist and blacklist. I'm in preference of "list o...
I'm in preference of "list of X" as that will universally be the most descriptive
a role that is on the list of allowed roles is much more verbose than a grantlisted role (>3x words, >2x syllables). While the latter might initially be more confusing for someone who is looking at it for the first time, the context makes it clear what the phrase means. Grantlist/blocklist are more descriptive than whitelist/blacklist (grant-list = a list of things that are granted access, block-list = ...
I'm in preference of "list of X" as that will universally be the most descriptive
a role that is on the list of allowed rolesis much more verbose thana grantlisted role(>3x words, >2x syllables). While the latter might initially be more confusing for someone who is looking at it for the first time, the context makes it clear what the phrase means. Grantlist/blocklist are more descriptive than whitelist/blacklist (grant-list = a list of things that are granted access, block-l...
You should receive the following error now:
{
"message": "A server can only have a single template.",
"code": 30031
}
We should now accept both fields optionally (it is worth noting that description is still both nullable and optional.)
| name? | string | name of the template (1-100 characters) |
Nihlus details a good concern, and unfortunately I have no good solution here.
In general for this set of APIs, the serialized_source_guild property is very messy. Internally, it is inherited from the base Guild object, and Discord clients parse it like a Guild (with the exception of icon/icon_hash) so I don't think that documenting it completely separately is a good idea. If the base Guild ever had a new non-optional field, serialized_source_guild would likely come with it as we...
When you close the connection to the gateway with the close code 1000 or 1001, your session will be invalidated and your bot will appear offline. If you simply close the TCP connection, or use a different close code, the bot session will remain active and timeout after a few minutes. This can be useful for a reconnect, which will resume the previous session.
efc420e Document close code 1000/1001 behavior (#2148) - MinnDevelopment
words as grantlisted are just bad, while you typically can figure them out by looking at context, the parts that make the word and some thinking. it doesn't just require a lot more effort to do, it raises the bar enormously for non native english speakers, and especially for developers with limited knowledge of english.
When trying to use a translator to translate it to my native language, it translates to "listed at the stock market" in my native language. even when used in a sentenc...
If you want to use a custom scheme you must employ PKCE on your authorization flow. Learn more at https://oauth.net/2/pkce/
Thanks for your reply. I will implement PKCE and get back here to verify that custom schemes function with that. It might be worth mentioning somewhere on the Discord application OAUTH2 dashboard.
There is also no single-word adjective form for describing a member of a list of X.
Authorized/Unauthorized. It's easy.
Authorized/Unauthorized. It's easy.
Those words already have meaning, however, in a slightly different context. You could successfully Authorize, but be on a list of Y, and thus be Unauthorized. I get your meaning, but X-Listed / Y-Listed conveys additional meaning, to me anyways,
Description
My discord bot is showing INVALID TOKEN when the token is indeed valid.
[discord/discord-api-docs] New comment on pull request #2150: Add elixir libs to community libraries
Usually the library authors decide when they want it to be listed in the docs.
[discord/discord-api-docs] New comment on pull request #2150: Add elixir libs to community libraries
This PR was made due to a recent discussion in #elixir_nostrum.
I can probably ask the authors of each lib to approve/comment on this PR if they don't have any objections or close this PR and allow them to create it themselves whenever and if they want to.
[discord/discord-api-docs] New comment on pull request #2150: Add elixir libs to community libraries
I have no objections with adding Nostrum.
I'm assuming X and Y here are placeholders, X-Listed / Y-Listed conveys literally nothing. I haven't had a chance to read the 3000+ words in this PR conversation to figure out what's going on. Allowlists and Denylists are probably the best bet you're going to get here, they're already used in some places and convey enough meaning (ie you're either allowed or not allowed). People yelling it doesn't sound "natural" are just yelling it because it's different, given enough time you'll get used to...
Allowlists and Denylists are probably the best bet you're going to get here, they're already used in some places and convey enough meaning (ie you're either allowed or not allowed).
I don't think adopting neologisms makes for a very accessible documentation, I prefer the current approach of rephrasing instead of just s/whitelist/allowlist/g. As was mentioned previously, translators will have a hard time translating it properly. Words such as these can be adopted when they are widely in u...
I don't think adopting neologisms makes for a very accessible documentation, I prefer the current approach of rephrasing instead of just s/whitelist/allowlist/g. As was mentioned previously, translators will have a hard time translating it properly. Words such as these can be adopted when they are widely in use, but not right now, especially in documentation where clarity is important.
If we're going the route of having things that are widely adopted/in use why are we rushing into maki...
Then why are we rushing into doing this?
Because it has been stated that this will get merged, so might aswell make the best out of it now. To be frank with you I am opposed to the original changes, tho the documentation could use some rephrasing here and there.
And for allowlist/denylist, I agree there are places where it can act as a drop-in replacement, but for a lot of those cases a simple rephrasing, which simultaneously can also aid clarity, will also do the job, so I really don't...
Seems okay. It is explicit.
Description
When doing breaking changes like requiring whitelisting for people that have the server member intent already enabled, consider warning bot owners that have that option enabled but are not whitelisted
Why This is Needed
When the intent system became available, I enabled the server member intent as soon as possible because I need the server members for my bot.
The intent toggle had been explained as follows:
This toggle will temporarily not have...
The system DM and email sent to bot devs when their bot becomes eligle for verification links to a support article and a blog post which explains it, and the system DM and email they sent to all bot devs in July about the tos update and domain change also linked to the blog post.

Also, if you applied for verification but did not request an intent you had the switch on for, they t...
It was not mentioned in the emails before or after verification for me. I get that it was mentioned in a later blog post and help article, but I really do think the communication could have been better.
Also I understand that I'm partly at fault here, but I'm far from the only developer not understanding this properly.
My feedback is really this:
- Show a big red warning in your verification screen that says 'Your bot is currently in a broken state' when it is
and/or
- Send an ...
The format of serialized_source_guild is exactly the same as what the create guild endpoint accepts: https://discord.com/developers/docs/resources/guild#create-guild
It's a template, it's purpose is ... creating guilds, so the data format is just exactly what we need in order to re-create that guild. So the same rules/restrictions/conventions that the create-guild endpoint has apply here too (for example the first role is always for @-everyone, etc)
icon/icon_hash are the one exception...
fyi, there's also: UNKNOWN_GUILD_TEMPLATE = ('Unknown guild template', 10057)
already added that in #1712
nit: I'd vote for "with a object" -> "of objects", because the interface was intentionally designed to support multiple template per guild if we wanted to in the future. Currently it reasonably strongly enforces a limit of one per guild, but if the right use case came up, I could see that restriction being lifted.
ah, I thought that it was just to avoid breaking backward compatibility with the client from before it was changed from multiple to one, should I also change the route title to Get Guild Templates?
Nihlus details a good concern, and unfortunately I have no good solution here.
In general for this set of APIs, the
serialized_source_guildproperty is very messy. Internally, it is inherited from the baseGuildobject, and Discord clients parse it like a Guild (with the exception oficon/icon_hash) so I don't think that documenting it completely separately is a good idea. If the base Guild ever had a new non-optional field,serialized_source_guildwould likely come with it...
The method should be renamed to "Get Guild Templates", too, in that case.
Agreed with the suggestion to show a warning in the UI that the bot is currently in a broken state. Here's what I mean:
I can read "You must apply for whitelisting if you turn on any of the Privileged Intents" and still not realize I need to do anything if I believe that I have already applied. When looking at the enable/disable toggle in the bot settings, and I don't see any red or warnings or anything, that bolsters my belief that I am in a good state when I am not.
Taking out the "if...
And it is true that whitelist/blacklist relies on cultural presumptions
There is no such presumptions. The problem with the 2018 journal and with what people are doing with allowlist, grantlist, etc. is that they're abusing their grasp of the language by breaking the words down into their parts, saying "I understand these parts in isolation", and then gluing them together again. Saying that "white list" is hard to understand is applicable to "fire wall", "gate way", "guide line", "under ...
How's this not a feature?
I want to give boosters special privileges in the server. For example if they boosted 3 times, they will get access to a custom bot.
Still needing this, can't believe it is not a feature. I want to give my members special privileges based on how many times they boosted!
mentioning somewhere on the Discord application OAUTH2 dashboard.
Or literally anywhere in the documentation. There's so many OAuth2 systems out there that don't use PKCE, so without documentation it's literally impossible to tell.
@night
editing (and deleting) messages is now possible

How about we stick to the topic of the PR for now, because it does not require a PhD in linguistics to understand the intent of the author's changes.
And--as someone who studied English language and literature--as much as I love a good debate about philology, I think we're all well aware that that is not the intent of these changes, or the discussion that has sprouted from them.
Yeah let's do Get Guild Templates.
@Nihlus
Would you like me to open an issue and elaborate a bit more?
I think this is a good idea. I expect this concern to come up again and it definitely looks like a much bigger scope than this PR.
But to set some expectations I'm going to avoid personally making any decisions around this area. I'm honestly not too familiar with the API, and so I'm definitely going to defer to the longstanding API doc maintainers (i.e. night and mason). But they are very busy right now so nothin...
8ca8012 Removed outdated verification level display nam... - Jrelvas1
Description
Upon restarting a bot, users who have previously triggered the event on_reaction_remove can no longer trigger the event. This can be fixed by restarting the users discord client.
Steps to Reproduce
To reproduce the issue, create the event, on_reaction_remove and have a user remove a reaction triggering the event. Then restart the bot, and have the user try to trigger the event by removing a reaction again. The event will not trigger.
*Expected Behavior...
This sounds like the behavior of the API library you use rather than an API bug.
You can probably use on_raw_reaction_remove instead. This is likely due to the fact discord doesn't provide user/member data for reaction removals.
Description
This issue continues on from a discussion that started in #2144, in regards to a lack of clarity in the definition or implementation of the Guild object.
In the new Template API, there exists a property called serialized_source_guild which, ostensibly, contains a Guild object. However, the data in the property never contains an id property, nor a significant number of other properties. Furtherm...
Kind of beating a dead horse with this one, but good to see interest in itemizing what needs to be fixed. See at least #1484 and #1605. Might be mentions of this concept elsewhere that I can't remember.
80c7538 finish up stickers documentation - puddi
adding a new field to the messages object for stickers, with new tables to explain the actual new type of stickers object (joint work w/ @jfurrow)
Any documentation for CDN?
We were discussing about the CDN URLs earlier in the Discord API server and discovered that https://discord.com/stickers and https://cdn.discordapp.com/stickers were both valid.
Error code 50081 might be worth documenting as well. Not sure since bots can't use stickers.
looks like bots can also access /sticker-packs/directory/:layoutid:
- client uses the layout id 758482250722574376
- error 10033 Unknown Store Directory Layout
- query params
with_store_listingsboolean andcountry_code
and when bots try to send stickers in a message by including sticker_ids, it returns error 50081 Cannot use this sticker; will bot be able to send stickers in the future?
[discord/discord-api-docs] New comment on pull request #2150: Add elixir libs to community libraries
I have no objections with adding coxir either. 👍
This needs to be #DOCS_RESOURCE_CHANNEL/message-object-message-sticker-structure
Also might be worth saying in the description that bots can only receive stickers, and not send them
looks like bots can also access
/sticker-packs/directory/:layoutid:
- client uses the layout id 758482250722574376
- error 10033 Unknown Store Directory Layout
- query params
with_store_listingsboolean andcountry_codeand when bots try to send stickers in a message by including
sticker_ids, it returns error 50081 Cannot use this sticker; will bot be able to send stickers in the future?
Bots don't need to access the directory layout so we can leave it undocum...
Description
It would be useful if bots could create webhooks where only the account that created the webhook could access its token / use the webhook.
Why This is Needed
A few large bots on the platform (namely, PluralKit, Tupperbox, NQN, and possibly more) use webhooks to send, or "proxy", messages sent by users.
Editing webhook messages was recently added. This creates the issue where a server admin, or other user with Manage Webhooks permissions, could edit a different u...
Removing webhook message editing feature will be sucks though.
@night Is there a final list of which endpoints I need to remove/change from my lib? Are these coming back or are they gone for good? Are we good to proceed with removing these in our libs?
| stickers? | array of [sticker](#DOCS_RESOURCE_CHANNEL/message-object-message-sticker-structure) objects | the stickers sent with the message (bots currently can only receive messages with stickers, not send) |
this doesn't seem true though? at least for png/apng stickers; https://cdn.discordapp.com/stickers/748293547572330607/067a41f0df36a1d0925078ded077824c.png?size=512 is the image from the id and asset
@puddi Let's instead just say that the URL for fetching them is private
@advaith1 It's possible, but we don't want to yet document it. There's lots of undocumented but technically available things within our API. In this case, where we host stuff could be subject to change (since we have two URLs that resolve there right now, lol) and we don't want everyone scraping stickers yet outside of our experiment
With the original (client-side) replies, sometimes I edited replies into my messages after sending to clarify what it was responding to
I know a couple of people who do that too. I think that one use case is already quite important and frequent
So my sister is having a problem about the Group chat she wan in the group chat but she cant find the Group Chat please fix this Thank you
For issues unrelated to the API, please contact support.
Hello, i recently boosted my server and unlocked the emoji upload possibility. At first, I upload some emoji and deleted them afterward because I wanted to change some of them and now its does not upload any at all
This is not an api docs issue. Please go to the discord testers server
Hi @msciotti I'm running into this issue as well, although my SetLogHook doesn't seem to display any debug messages. I'm trying to catch the NotRunning error when discord quits while the game is running, but I'm notsure 100% how to implement it.

I'm running into an issue with SetLogHook where it doesn't seem to display any debug messages. I'm trying to catch the NotRunning error when discord quits while the game is running, but I'm not sure 100% that my implementation is correct. NotRunning does in fact show up if I quit discord while the game is running, but I expected the callback function to fire, but nadda. Any ideas?

...
This would cause an error (I think?) and proposes confusion to new users.
That example is a minimally required identify payload. Intents are required in v8+.
Nevermind, the diff confused me.
Don't use webhooks to proxy users' messages, instead use embeds or something. (This would make for a really bad user experience.)
Apologies if I'm missing something, but how would this make for a bad user experience?
Using embeds instead of webhooks makes you miss out on some core features that make you want to use webhooks in the first place, such as customisable avatars and usernames
Yeah embeds have the author oarameter. But not as cool as an actual webhook.
Understood, but then I have to ask. The use case for this seems to be related to server moderation (that server admins can edit a webhook's message), so why would it matter if the ability to customize the avatar and username was lost? If there's a need to prevent server admins from editing messages like these, I fail to see why a loss of customization would be a big issue.
The feature request here is asking to make it such that webhooks can be generated in a way that only the creator is able to know their token rather than anyone with manage webhooks.
I understand that, but the use case doesn't quite make sense to me. Perhaps I'm misunderstanding it, but it sounds like they're talking about the use of webhooks for recording a user's deleted messages -- or something of the sort that would relate to moderation. In those sorts of cases, I can't see why the loss of customization would be a big issue.
No, the use case for webhooks as presented here is for proxying a message as a user, but modified in some small way. The intent here is that server administrators shouldn't be able to edit a message that was legitimately proxied as a user as server admins don't have that permission for regular user messages.
NQN is the only bot of the three given above that I can give a complete explanation for so apologies for the lack of generality, but it allows people for example to include message URL...
Ahhh, okay. Thank you for clarifying -- I had not thought about those sorts of situations.
This PR adds a note that setting guild_subscriptions in v8 does not have any effect on whether typing and presence events are sent, or not.
Tested combinations:
| Gateway version | Intents | guild_subscriptions |
Result |
|---|---|---|---|
| v6 | None | true |
Receives TYPING_START and PRESENCE_UPDATE event |
| v6 | None | false |
No TYPING_START and PRESENCE_UPDATE event |
| v6 | GUILD_MESSAGE_TYPING/GUILD_PRESENCES |
false |
Receives TYPING_START and... |
TBH I don't feel message editing is anywhere near as an important concern for this feature. This seems like 100% necessary for security.
What happens if i want to damage the credibility of a bot? I could fetch all webhooks created by any bot for whatever purpose and then start sending nsfw or anything abusive. and send pretending to be X bot with it's name & avatar
Hello! I can't speak for NQN, but both PluralKit and Tupperbox have a feature where you can react to a proxied message with a question mark and the bot will reply with the original user who sent the message.
If someone manually grabs the webhook and sends messages with it (whether they're replacing someone else's message or just something abusive), the bot's database will have no knowledge of the message and will reply that the message was not proxied through that bot.
What happens if i want to damage the credibility of a bot? I could fetch all webhooks created by any bot for whatever purpose and then start sending nsfw or anything abusive with it's name & avatar
Even if the bot's webhooks were restricted to only the bot being able to use it, you could just as easily create your own webhook and do the same malicious things. I have seen this happen numerous times already with bots webhooks created both by the bot and by those who have permission.
maybe just remove the section entirely? since the docs are for v8, and it isn't vital info for v6
I think it should be mentioned in the change log.
isn't it implied by the requirement of intents though?
Documentation should remove the need for people to make implications or assumptions on behaviour. So even if it was implied it should be explicitly noted.
In the gateway documentation, there is an example URI where the version and encoding are set explicitly in the URI. The version is set to 6, but I think it should say 8 as the majority of the documentation applies to gateway version 8, and for newcomers, this would lead to confusion.
With the resulting payload, you can now open a websocket connection to the "url" (or endpoint) specified. Generally, it is a good idea to explicitly pass the gateway version and encoding. For example, we may...
Description
Now we're able to edit and delete webhook messages, could we make it so we can do it for any webhook message in a channel we have manage webhooks in?
This could be implemented by allowing the PATCH and DELETE methods for the /channels/{channel.id}/messages/{message.id} endpoint to work for any message with a webhook id set to be modified/deleted if the current user has manage webhooks in that channel.
Why This is Needed
To edit/delete a message by id, assumin...
b3e2c3e Clarify some large bot programs - msciotti
Global Rate Limit errors and increases, CloudFlare bans, and Large Bot Sharding are not documented super well, leaving many developers to assume they have to contact us when their bot gets large. While we certainly love chatting with new devs at scale, I felt it might be good to more clearly document just exactly what these systems do, how the errors can manifest, and what these programs solve.
That is to say, they are not a magic solve for all problems, but may help you in a specific ...
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
Huh, I thought the implication was that very large bots got an increased number of IDENTIFY calls. Is that not the case?
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
That is the case. Large sharding bumps from 1k --> 2k. It also (unless I am misinformed) allows you to start more shards concurrently (which is why as part of the process we sync you to a multiple of 16 or 32 when you get real big).
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
So, just to make sure I'm reading your response right... it becomes 2000 IDENTIFY calls when you become a Very Large Bot? If so, this should be edited to mention that -- because it seems to say that you still only have 1000 IDENTIFY calls.
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
You should also probably change the wording on the paragraph just below to mention the increased limit on starting shards concurrently.
Could #1636 be rolled into this PR as well? So we can rely on that being there for large sharding.
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
"impossible for to" -> "impossible to"
That is generally a sign that your Authorization header is incorrect in your REST request. Make sure your header follows this format:
Authorization: Bot {bot_token}. Also make sure your bot has access to the channel.
Thanks
Is there any update on this? I am still getting frequent 429s because of the new hash switching,
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
I think this might be relevant to the convo (2 paragraphs lower):
This is not true for all bots above 250,000 guilds, but if you have a large bot and find yourself having these issues, please file a support-ticket to get moved to Large Bot Sharding. You can contact the discord support using https://dis.gd/contact.
So it seems 250k != Large Bot Sharding, and therefore you don't automatically get 2k IDENTIFYs when you have a big bot.
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
I thought you should contact them when you are getting random 4000s from the gateway?
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
@A5rocks I understood that, and I wasn't trying to say that 250k means it's a Very Large Bot.
However, when a bot gets Large Bot Sharding enabled, you then get an increase in IDENTIFY calls, as well as the ability to start more shard concurrently. As it stands, the documentation does not mention either of these points (and, in fact, seems to imply the opposite on both) -- so I was suggesting that msciotti document both points.
I suggested this in one of my issues here, to implement a separate way of receiving the members on startup (if the bot has the members intent) so that it has it easier to handle member updates later on.
The API as it is right now is extremely counter-productive towards a majority of existing bots, as they either have to chunk members or retrieve them when a command or similar is executed, which both takes (a lot) of time and consumes additional requests.
Having Discord send the updated info...
I think this could be more explicit. The returned channel/guild is only a name/id respectively so partial is a bit of an understatement.
This is handled for "partial emojis" by linking to an example. I don't think it's the best solution, but it is an idea. See https://discord.com/developers/docs/topics/gateway#message-reaction-add-message-reaction-add-event-fields
What about a channel follower webhook example? Or would it be better to explicitly state that source_guild only has id, name, and icon and that source_channel only has id and name?
Description
Steps to Reproduce
Expected Behavior
Current Behavior
Screenshots/Videos
Client and System Information
You have to actually fill out the issue template. There's no information here.
When you mute and unmute your microphone fast, it appears that you are silenced but you can speak normally
(sorry for my english, because i'am using goole translator ;-; )
sorry i don't speak english and it's my first time at this site :(
Client bugs should go to [Discord Testers](https://discord.gg/discord-testers]. This repo is only for issues regarding the API.
I found the following field in the app configuration:
INTERACTIONS ENDPOINT URL
You can optionally configure an interactions endpoint to receive interactions via HTTP POSTs rather than over Gateway with a bot user.
However, I haven't found a single place where this is documented, so I don't know where to start. I could set up an endpoint to check what I receive, but I don't really understand how to do it without a bot user. I'm not even sure if the text means that I don't ne...
That is for slash commands which are not released yet, therefore they are not documented yet. They will be released later this year.
Description
A new property that bots can send in messages that can be checked by TnS team whether a message from a bot contains user-generated content.
Why This is Needed
A malicious user decided to make bots say "bad"(doxing) things using certain features on the bots and then mass reporting it.
5 bots were reported and 4 of them were banned. The 5th wasn't banned because most likely it was one of the largest bots on Discord and would cause a nightmare having tha...
If this were to be implemented, it would be best to have it reference a message id that the content was generated from so TNS can use that to determine the likeness of the processed message and the user input
Why can't you just report the message like normal?
Why can't you just report the message like normal?
"A malicious user decided to make bots say "bad"(doxing) things using certain features on the bots and then mass reporting it."
Literally any user-generated content that is possibly breaking ToS can be reported, reporting a mesage like normal is not possible because it is the malicious users reporting, not you.
a "containsUserContent" property would be useful to prevent a bot from being insta banned for having malicious users report ...
I can't help but see this suggestion as more of a band-aid.
There's far too many bots for T&S to reasonably have a list of where UGC could be and where it couldn't be. Even if you have a property that tells T&S that a message has UGC in it, they would still have to figure out what part of the message is UGC, and what part is your bot's doing -- something that isn't always that easy.
It's easy for T&S to know that a role name shown through <@&ROLE_ID>, or something like a nickname on y...
Discord is scared of the ramifications of such a decision.It could cause unnecessary strain on theresystem.
your suggestion of approving UGC is actually a very good one, but i will tack on the idea of providing a notice that the UGC in question is subject to approval by the bot's developers and that the bot cannot be held responsible for said UGC until it has been approved. in the event the UGC is disapproved then simply clear said UGC and inform the guild owner in question that the UGC was not satisfactory.
I am also of the opinion that the containsUserProperty solution is a band-aid on a large...
This is not something we're going to pursue for a variety of reasons, one main one being that people would just simply set this flag to true by default, or not understand the nuance.
The problem is not with the API, but with the enforcement of ToS - and this is something our T&S team is continuously improving. No, your bot should not get banned if someone uses it to do something bad and mass reports it. That problem is on us, not you.
It will be documented when ready.
I'm guessing the bottom one, it was probably created and then deleted
Not having this in the API makes it impossible to know if a user has actually deleted their account or is just faking account deletion. Just listening on GUILD_MEMBER_UPDATE/PRESENCE_UPDATE for username/avatar changes with a regex has led to false positives before where a user fakes deletion to try to evade certain security measures used by bots or server managers.
Thank you for the feedback. We understand this was a breaking change, and therefore had a 6-month migration period and did our best to communicate this impending change via blog posts, DMs and emails, in the Dev Portal UI, etc.
But, we are certainly not perfect! It would probably be good to add some validation when submitting your verification request if you have those intents turned on but did not apply.
Can we keep this open until it is documented?
You all seem very interested in an "official" discussion, so here is the official stance:
It's not a necessary change, and we do not feel the need to change it. Thank you for your thoughts.
It may be beneficial to start documenting these rate limits on an endpoint-by-endpoint basis, since it appears this is how they are now being implemented.
This is not a great solution because it will encourage people to hard-code backoffs instead of programmatically handling them via headers.
As for your original question, I'm not sure what you believe the proper solution would be. Adding a note that says "These resets can sometimes be a number of days?" when that is really only true ...
I started thinking about this a week ago. I think another good solution is for libraries to avoid blocking and return a rate limit error, if the time-to-wait would be above a certain amount (say, 10 seconds) -- or if it's below that amount, it would block and automatically try again once the timer is up.
However, we should at least have a note on the Rate Limits page -- so that anyone making their own library won't run under the same assumption that all rate limits are short.
It's an interesting idea, but ultimately not something we'd want to display like this. For scheduled downtimes, I think a number of people here have commented on ways to either avoid it or proactively message it.
For unscheduled downtime...well, such is the way of the internet I suppose. Support servers with reactive messaging, or even some sort of backup message send script you can run locally, are probably simpler ideas.
Others are also right in that tying something to status wouldn't...
Description
This new intent would allow bots to specify to report a message to T&S when deleted.
Why This is Needed
On most big servers, bots handle antiraid, instantly mass deleting messages from those involved in raids. Sadly, when messages are deleted by bots, they are completely removed from Discord's database, making it hard or impossible to report the users. This could also apply for message filtering for bad words or copypastas, so bots could log what was deleted, an...
Hi,
Thanks for the suggestion. We aren't going to let automated reports take place at this time - and I suspect it will end up being incredibly noisy / low signal to noise ratio anyways.
Just ban the bots from your sever - this is actually good signal (along with a few other secret things we look at.) to detect these kinds of activities.
🤔 is banning bots supported? the option doesn't show on iOS and is an accepted bug for Desktop
We are talking about the user bots sorry
On the topic of this and the linked issue, I noticed that the delete message bucket now alternates between itself (3 / 1 sec), and 80c17d2f203122d936070c88c8d10f33 (5 / 5 sec), which is shared with the post message and edit message endpoints. Since I read somewhere that the delete message bucket is separate and faster to accommodate moderation bots, I was wondering whether this is intentional.
That definitely sounds like a problem and could be the cause of this. The bucket for delete m...
<!--
Before opening a new issue, please search existing issues: https://github.com/discord/discord-api-docs/issues
-->
Description
This new intent would allow bots to specify to report a message to T&S when deleted, or just have the option to store the message in Discord's DB even after deletion.
<!--
Provide a clear and concise description of what the feature request is.
-->
Why This is Needed
On most big servers, bots h...
If the client can filter them out, then the spammers can. If the client can't filter them out, then there are obviously going to be false positives.
On the topic of this and the linked issue, I noticed that the delete message bucket now alternates between itself (3 / 1 sec), and 80c17d2f203122d936070c88c8d10f33 (5 / 5 sec), which is shared with the post message and edit message endpoints. Since I read somewhere that the delete message bucket is separate and faster to accommodate moderation bots, I was wondering whether this is intentional.
That definitely sounds like a problem and could be the cause of this. The bucket for de...
I was told from the Discord Testers guild to report my issue related to RPC here but I do not think this issue fits here very well:
Related approval message in DTesters server
Steps to Reproduce
- Connect to the local running RPC server from your discord client.
- Authorize with the
rpcscope. - Send the following payload: `{"cmd":"CAPTURE_SHORTCUT","nonce":"....","args":{"action":"...
Description
We all want to make our bots look beautiful, detailed and well made. Custom emotes help with this. This exclusivity of emotes for bots would actually be a tab for us to be able to add custom emotes for bots to use.
An easier way to use emotes without having to use any server for that.
(it is very annoying to have to take this in every emote).
Why This is Needed
This is a little necessary for those who are new to creating bots, and to facilitate the work of ...
As an alternative, I would consider having the bot create a guild (or creating one yourself and inviting the bot) and uploading emojis here
[discord/discord-api-docs] New review comment on pull request #2165: Clarify some large bot programs
How about "you can contact Discord support"? (without the)
[discord-api-docs] Branch clarity/large\-bot\-errors was force-pushed to `f147e71`
011754d shard concurrency starting - msciotti
@jhgg one thing I'd like some clarity on before I merge based on your comment here: https://github.com/discord/discord-api-docs/pull/1621#discussion_r425365853
In the case of 32 shards, do I need to start the full "bucket" of shards in order? Or could I, for example, start shards 0-14 + shard 31 concurrently?
The way max_concurrency works is that the identify limit is per bucket. The order at which these buckets execute is not relevant as they are concurrent and have their own limits. Small bots have a max_concurrency of 1 which means they only have one bucket, while bigger bots have 16 buckets each with a 5s identify rate limit. You could start shard 0-14 and shard 63 (because 63 % 16 = 15) at the same time.
For example, a bot with max_concurrency 1 can start the shards in random order. The ...
Any updates on this?
It was supposedly raised to the team over 6 months ago, surely there's been some decision we could hear about by now, right? :p
Steps to Reproduce
Setup a new bot that uses the Guilds intent, listen for GUILD_CREATE, nothing happens when a bot joins a guild / or starts up when a member of one or more guilds.
Expected Behavior
Discord should send GUILD_CREATE events regardless of privileged intent activation.
Current Behavior
Without the privileged intent activated, no GUILD_CREATE events are sent from Discord.
Client and System Information
Testing on https://github.com/an...
Unable to reproduce using...
- a new bot without any privileged intents activated with
GUILDSintent specified and joining a new guild:
[Client] Received payload from gateway 'Hello'.
[Client] Sending payload 'Identify' to gateway.
[Client] Initialized heartbeat: 41.25 sec.
[Client] Received event 'READY' from gateway.
Waiting for guilds to arrive...
--- Adding the bot to a guild
[Client] Received event 'GUILD_CREATE' from gateway.
[Client] Received event 'GUILD_MEMBE...
I can't reproduce. Do you have more information? I was able to receive GUILD_CREATE events on API version v8 by specifying only the GUILDS intent (intents == 1).
What does your application site look like, the bot section. Did you enable presence intents?
I used just a new fresh new bot, just with a bot account:

I can't reproduce this. (This bot is in multiple guilds and I am identifying with only the guilds intent)

@andersfylling
Edit: the intent value sent on identify is 2047
If you use an intent value of 2047, your bot has the following intents:
Guilds | GuildMembers | GuildBans | GuildEmojis | GuildIntegrations | GuildWebhooks | GuildInvites | GuildVoiceStates | GuildPresences | GuildMessages | GuildMessageReactions
Your bot should not be able to connect to the gateway without having the privileged intent enabled.
Interesting. My bot does not get kicked or anything, it just stays connected. Though I haven't tested it for hours..
Can't reproduce with discord.js using {ws: {version: 8, intents: ['GUILDS']}}; it does receive the GUILD_CREATE events on connect.
The presence intent switch was on in the dev portal, I turned it off and there was no change. However, when I turned it off, there was a red "500 Internal Server Error" box in the dev portal. After reloading, the switch is still off.

Open Id needs an endpoint for Jwks , AWS Cognito and other auth services need it for easy integration
Right now people need to create wrappers around discord in order to be able to use it with services like cognito
https://github.com/qwerqy/discord-cognito-openid-wrapper
Right now the only alternative is to use a wrapper function.
Adds info about List Guild Members being restricted according to intents.
To specify these intents in your `IDENTIFY` payload, you must visit your application page in the Developer Portal and enable the toggle for each Privileged Intent that you wish to use. If your bot qualifies for [verification](https://dis.gd/bot-verification, you must verify your bot and turn on the checkboxes for the intents you want in the form. If your bot is already verified and you need to request additional privileged intents, [contact support](https://dis.gd/support).
probably should hold off on merging this until the gateway update is deployed, and update this to say that it's already off done
I think I made a sufficient change. I'll leave it up to Discord to decide when they want to pull this. I think it makes more sense to make the change as if it is deployed rather than keep it as "On October 7..."
Wouldn't it be better to not explicitly mention this route, but rather say that certain routes may require intents (and will have an info block with the required intent/link to this part of the page where intents are explained)?
With yesterday's change to intents, providing previous states is a necessity.
With the tools currently available, having every member in cache is necessary for many bots. Many moderation, logging, and utility bots need to know a user's previous username, nickname, avatar, etc when they get updated, and the only way to get that information is to have the old values cached.
A bot that previously took a few minutes to load this cache now takes several hours, which is an unreasonable amoun...
All bots should be able to get a full member cache within 10 minutes of startup assuming ~1000 members/shard. There's no reason on Discord's end it should take any longer than this.
I'm not saying 10 minutes isn't a long time, but it is vastly shorter than several hours.
All bots with the members intent should be able to get a full member cache within 10 minutes of startup assuming ~1000 guilds/shard. There's no reason on Discord's end it should take any longer than this.
I'm not saying 10 minutes isn't a long time, but it is vastly shorter than several hours.
Sounds nice in theory, but the practice is often the exact oposite.
10 minutes is a pretty low number. Especially for bots with large numbers of shards is this quite unrealistic as not every guild ...
For some real life data, it took my bot 15 minutes successfully chunk in every guild's members from the time the final shard received a ready event. My bot's on ~120 shards right now so it's reasonably representative of the sort of timescale you might expect at the medium end of size if you do chunk every guild on startup.
- A lot of the integration fields seem to now be optional on V8 and treating them as otherwise will break implementations
- Get Guild Integrations is now returning bot integrations regardless of what include_applications is set to or if it's included so this doesn't seem relevant for V8 docs.
To clarify a few things. The hours of time for startup are caused by the usage of old chunking features which no longer work on v6 and v8. The reason it takes so long to load is that the requests for 50 guilds will only return the members of 1 guild. The other 49 guilds then timeout and retry the request after 10 seconds (in JDA).
So the time for startup can be calculated:
2500 * 10 seconds = 25000 seconds = 7 hours
I have updated JDA to no longer use this old chunking even when inte...
Assume a bot on 25 thousand servers that can see roughly 20 million unique users (approximate numbers from one of my own bots). Each chunk can contain up to 1000 users, and chunks can be requested 120 times per minute. Therefore, in the ideal case where there are no users with more than one mutual server with the bot, it would take approximately 20000000 / 1000 / 120 = 166.67 minutes to fill the cache, which is nearly 3 hours. If my math is correct, this seems unreasonably long for a bot to r...
This would be useful for, say, moving a conversation to another channel.
@jagrosh your math is not correct tough, you can request them for up to 115 guilds per minute (to leave headroom for heartbeats), and you will get multiple chunks back per guild as needed. your need to calculate it based on servers and not member counts.
also multiple shards are independant so you can requests guilds on multiple shards at the same time
so to calculate the time it would be <number of guilds> / (115 * <num shards>)
When you request a guild's chunks, you receive all of them, not just the first 1000
[discord/discord-api-docs] New comment on issue #2173: OpenID: When would you guys support opend ID?
https://support.discord.com/hc/en-us/community/posts/360040492792-Create-OpenID-Connect-endpoints-to-more-easily-enable-SSO- seems to have a feedback post which is probably a more relevant location.
Description
Occasionally voice channels cannot be deleted without the "Connect" permission - but not always. In 2 guilds with identical permissions, one may require the "Connect" permission, and one may not.
Steps to Reproduce
God knows - all I know is that it is reproducible since someone else ran into the same issue ~2 years ago.
Expected Behavior
Voice channels should be deletable with just the "manage channels" permission, since only the manage channels per...
A few days ago all our Discord bots broke because message.member.presence.status is always offline. Not sure if this is a problem with Discord, which recently had an upgrade or Discord.js. Feel free to delete this if it's in the wrong place.
you need to enable the Presence intent in the dev portal, see https://s.advaith.io/intents and https://dis.gd/gwupdate
should add the allowed_mentions update
Ah, I was incorrect, and conflating multiple problems.
Duplicate of #1522? The reasoning here is that you can't delete a channel you don't have access to. Since CONNECT acts just like VIEW_CHANNEL this applies here as well.
The chunking requirements always apply now that intents are enabled by default in v6. I've also updated the changelog because this is a breaking change to v6.
Should I also link to https://dis.gd/gwupdate ? I'm not sure how temporary this blog article is.
Description
Gateway v6 has a bug with Opcode 8 requests, where it only accepts the first guild in the guild_id array of that payload. The bot has been whitelisted for both guild members and guild presences intent.
Steps to Reproduce
- Connect to the gateway on v6
- Wait for all the guild_creates to finish.
- Send a opcode 8 requesting members for all the guilds that are bigger than the large_threshold.
Expected Behavior
I would get member chunks for every sin...
This is intended behavior see #2178
Oh so discord is just planning to break v6 without warnings.....
Adding to this, could we allow querying by role ID(s)? With the recent gateway changes and upcoming changes to similar HTTP endpoints, most bots won't have a local cache to query and finding members with a specific role will be fairly difficult without either storing all member -> role mappings locally or fetching the entire member list, both of which aren't desirable, and scales poorly as servers grow larger and larger. Expected use cases might include finding moderators on a server or manag...
Description
When sending non-numeric IDs/Snowflakes for gateway opcode 8 (Request Guild Members), the gateway hangs for a few seconds after which opcode 9 (Invalid Session) is returned. I believe the gateway should be able to recover gracefully.
Steps to Reproduce
- Send opcode 8 with non-numeric
user_ids. For example:
{
op: 8,
d: {
guild_id: '[REDACTED]',
presences: false,
user_ids: [ 'a' ],
query: null,
nonce: '1756ebb1e21',
li...
This also occurs when (query='', limit=0)
The issue is more that it's inconsistent. In 2 guilds with identical permissions, one will require "connect" and one won't
In case of query='' the gateway doesn't not respond with any GUILD_MEMBERS_CHUNK but the session does not crash (i.e. the gateway still sends events). In case of query=null during the "hang" time no new packets are received or can be sent to the gateway, then it sends Session Invalid. Re-identifying after that resumes normal behavior.
I think it would be OK to link it in the changelog? Since it's useful for people at this time, but not forever.
this is the error log :
config: {
url: 'https://discord.com/api/oauth2/token',
method: 'post',
data: 'client_id=00000000000&client_secret=secret-0-0-0-&grant_type=authorization_code&code=mycode&redirect_uri=https%3A%2F%myredirect-uri.com%2Foauth2%2Fendpoint',
headers: {
Accept: 'application/json, text/plain, */*',
'Content-Type': 'application/x-www-form-urlencoded',
'User-Agent': 'axios/0.21.0',
'Content-Length': 236
}
...
As an alternative, I would consider having the bot create a guild (or creating one yourself and inviting the bot) and uploading emojis there
Just to mention there are drawbacks to doing that, such as the 100 server limit for users, bots can't create servers if they are in more than 10 servers and if you are planning to get verified for intents it can be seen as suspicious or inorganic growth since the bot will need to be in several servers owned by the same user to allow using th...
it can be seen as suspicious or inorganic growth since the bot will need to be in several servers owned by the same user
I would say this isn't something to be concerned about -- it's expected that the bot will be in a one or two (maybe even three) servers owned by the bot's creator, as there can be legitimate purposes to doing so. It's only when the bot starts being in dozens of servers owned by the bot owner that it might become suspicious -- and even then, there may be legitimate reas...
@BannerBomb Yes, if you want to play a card game with your bot, and want to use emotes, you will have to create more than one server to use all emotes.
What I want with this emote scheme, is that you can make an API request, and return all available emotes to the bot. This would make using emotes much easier.
Having this form of <emote: id> to use emotes, makes messages very polluted, and you also can't remember that,
every time you have to get a reference to use the emotes.
It is very annoying to be creating several servers to use emotes.
However, if you find yourself needing that many emoji, I would recommend finding another solution. For example, with Blackjack, you might consider using the
♠️ ♣️ ♥️ ♦️emoji that Discord includes by default, plus a number next to it. So for a One of Hearts, you might put♥️1. Alternatively, make the symbols and the card number separate emoji -- that would still be a decent amount of emoji (18 including Joker, by my count), but it would be far less than you needed before (and would be e...
@Cristian-Sknz Well I would suggest either limiting the amount of emoji you're using (I gave a couple examples of how you could do so), or boosting your bot's emote server to Level 1, as I don't think Discord will enjoy you using multiple servers to attempt to bypass the normal 50 emoji limit.
@LikeLakers2 I think they could make an exception for bots as they made it possible for bots to use custom emotes. And these bot emotes, only bots can use, a common member could only use them to react to some message.
@Cristian-Sknz I mean... you're using Discord's bandwidth. You're asking them to let you store your assets on their servers, and they're letting you, up to a point. Discord is paying for the bandwidth and storage your bot's emoji use, so the least you could do is be considerate and limit how much you're using -- or help cover some of the costs by purchasing boosts, which get you extra emoji slots as a bonus. I really don't think "It's only for bots to use" is a good reason to say otherwise.
Gonna just remove this then.
1609f22 rename some userflags to match their new name (... - caneleex
671a8a2 Fix markdown table (#2136) - ent3r
802633c Storage: added GetPath return type, WriteAsync ... - NathaanTFM
9a8f894 Reworded Flags (#1860) - Lachee
5a74b97 Document default avatar image sizes being const... - FasterSpeeding
@LikeLakers2 I don't see that that would be a big problem, I could create many other servers and exceed the limits of how many emotes I can use.
I agree that there must be a limit, but not as low as 50 emotes.
Some updates (that I will edit into the original comment as well):
channel_idis now optional on a message reference, meaning the only mandatory field ismessage_id- You can still only reply to a message within the same guild and channel
- If you send
channel_id, we will validate it (@meishuu why would anyone do this 🤔 )
Additionally, replies by default mention the user being replied to. There are some additions to the allowed_mentions object to change this behavior:
- `...
I would say this isn't something to be concerned about. It's expected that the bot will be in a one or two (maybe even three) servers owned by the bot's creator, as there can be legitimate purposes to doing so. It's only when the bot starts being in dozens of servers owned by the bot owner that it might become suspicious -- and even then, there may be legitimate reasons for that being the case. That's why there's the ability for Discord to do a manual review -- because a human can understan...
5cff75a channel id not necessary - msciotti
This has been changed in the latest update--only message_id is required.
Now only a message_id is required when sent
Are there any plans on making it able to reply to out of channel stuff? It seems very yes and very no at the same time, it'd be nice to know what's going on?
@advaith1 It'd be nice if you could point me to where it's said that staff can't bypass the growth flags.
What about when its a normal message, not a reply? What will happen with this field? Will that fall under If not present, the backend couldn't fetch the message.?
Fair point. In this case the nullable ? on the field may not be enough, I can clear this up a bit.
@LikeLakers2 staff can't bypass the growth flags, and someone actually ran into the growth flag because of emoji servers for their bot (they kicked the bot from the servers and made it send messages through webhooks as a workaround)
Something similar happened with the bot Loritta, had to increase the rate limit for this bot, because it was taking the global rate limit almost every day, and it wasn't the bot's fault, the reason was because the bot ...
e890d58 clear up referenced_message - msciotti
Probably worth adding "but only require a message_id" or something like that
Are there any plans on making it able to reply to out of channel stuff? It seems very yes and very no at the same time, it'd be nice to know what's going on (like are you still discussing it etc.)?
No, a reply can only be sent as a reply to a message in that same channel.
I can see how that was confused when channel_id was required, but it no longer is, which should help clear it up as well.
1264349 woops that is optional still - msciotti
| channel_id? | snowflake | id of the originating message's channel |
As a side question, why are all three fields of this optional?
This, wouldn't at least message_id be required
I feel like that happened to my bot also tbh but we are only using like 3 servers for emotes, most of the rest are all from unique owners 🤷 . But you can't use webhooks for everything like again for games. You can't edit a webhook message to update the results to keep the chat clean instead of sending separate message for each result of the game afaik and each webhook is locked to a single channel unless you update the webhook to use another channel. I would hate to use webhooks to send mess...
@advaith1 I was hoping to get a link to the message so I could also get some context, but that'll do.
Anyways, if that's the case, that's an incredible oversight by Discord. Why would you rely on statistics handled by computers to do that sort of thing for you and not implement a way to override it?
would be useful to say the default
message_id is not always present, see #2053 for details
I believe it is still actively desired.
Well, right now, it doesn't matter, but in the future, if there's any other endpoint that is gated behind any intent (be it current or new), we'd have to update this wording and list too (not a BIG deal, but I thought it'd be cleaner by mentioning just that certain endpoints may also require intents 😅)
Is it planned to allow webhooks to reply?
Hi. For several days now, my bot has been growing with many problems that are definitely not on my side.
- the bot cannot see that the user has joined any server. As if Discod's API didn't pass all the data to my bot (guildMemberAdd). Meanwhile, 0 errors in the console. Script:
client.on("guildMemberAdd", async (member) => { // ... }); - sometimes the bot has a problem finding users / channels
- Occasionally I see the following errors on my console
a) Response: Internal Server ...
programisci: maja problemy z api discorda
discord: tyryryryyrtytyy chuj ci w dupe tyytryrytytyyy
This is a duplicate of https://github.com/discordjs/discord.js/issues/4952 and may other issues.
programisci: maja problemy z api discorda
discord: tyryryryyrtytyy chuj ci w dupe tyytryrytytyyy
Translation for those who do not speak Polish:
programmers: have problems with Discord's API
Discord: lalalalalala screw you lalalalalala
The wording used is stronger in the original version.
Hi, from October 27, after 4 months my bot stopped working as it should, because it started to display error in the console:
„ TypeError: Cannot read property 'hasPermission' of null”.
The bot code has not been changed for weeks, and the bot itself does not respond to commands that require permissions. I did not find any help on the internet that would work, what should I do?
On October 7, Discord started enforcing bot verification and some intents restrictions. It seems that the remaining restrictions are now enforced. Despite our best efforts to streamline this transition for you, some of these changes are not negotiable and require individual action. Please read the discord gateway update FAQ
On October 7, Discord started enforcing bot verification and some intents restrictions. It seems that the remaining restrictions are now enforced. Despite our best efforts to streamline this transition for you, some of these changes are not negotiable and require individual action. Please read the discord gateway update FAQ
what should I do in this situation, if I don't want to change the bot code, wait?
what should I do in this situation, if I don't want to change the bot code, wait?
You build a time machine and travel back in time to when it worked. Seriously though, you have to update your library and code.
giving up would probably be the best solution for you
Description
A few days ago, discord has enforced the intents limitations on v6. This means that the old request guild members functionality, of passing more than 1 guild per request is no longer supported.
Instead of ignoring the other guilds I see 2 better alternatives:
- Send chunks for all of the guilds, but slower (this would result in the same but without breaking existing libs)
- Close the socket with an invalid payload OP code
4001(this would not be a silent ...
I think it's important to maintain a list of everything that is affected by intents in one location. Docs shouldn't be vague just because the API might change in the future.
without warning? they announced it months ago and even sent every developer a system message

@Mitchell-T the only mentioned thing was intents, not the fact that they would change how opcode 8s work
my bad, actually a valid issue, got burried in the ocean of people complaining their unmaintained bot broke, comment deleted
channel_idis now optional on a message reference, meaning the only mandatory field ismessage_id
This... is tricky. As far as the backend model is concerned, all message references have channel_id required, as was previously documented.
However, when provided for message creation, we enforce a different structure in which message_id is required instead of optional, and channel_id is optional instead of required. It technically has the same fields, just different optiona...
Description
guild.members contains only 1 member
Steps to Reproduce
async def on_message(message):
members = message.guild.members
member_count = message.guild.member_count
Expected Behavior
len(members) equals member_count
Current Behavior
members.count is always 1
Screenshots/Videos

**Client and Syste...
not a bug, read https://s.advaith.io/intents and https://dis.gd/gwupdate
you will have to update to discord.py 1.5.1 and specify the members intent (https://discordpy.readthedocs.io/en/latest/intents.html)
Hello, I have been using my discord bot for over 6 months with not changed code, but 3 or 4 days ago it just stopped to work and now always message.member returning NULL and I have no idea why. Bot have full rights to the server.
Can you please help me?
what library and version?
probably an intents issue, recheck those
I am not sure what do you mean under library, but I am using nodejs and here is my package.json:
`{
"name": "dcbot",
"version": "1.0.0",
"description": "",
"main": "Discord.js",
"scripts": {
"test": "echo "Error: no test specified" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"body-parser": "^1.19.0",
"discord.js": "^11.5.1",
"express": "^4.17.1",
"form-data": "^2.5.0",
"mysql": "^2.17.1",
"node-fetch": "^2.6....
according to that, your library is discord.js and the version is 11.5.1; but discord.js v11 is unsupported, you need to update to v12
https://discordjs.guide/additional-info/changes-in-v12.html
if you need further help with discord.js (after reading that page), go to its support server https://discord.gg/bRCvFy9
according to that, your library is discord.js and the version is 11.5.1; but discord.js v11 is unsupported, you need to update to v12
https://discordjs.guide/additional-info/changes-in-v12.htmlif you need further help with discord.js (after reading that page), go to its support server https://discord.gg/bRCvFy9
OH thank you very much! it helped me.
Hello, I just updated to version 12 but when I am trying to add or remove role with new command message.member.roles.remove('1231654414654446'); I am getting this warning and role is unable to be added or removed:
(node:23184) UnhandledPromiseRejectionWarning: TypeError [INVALID_TYPE]: Supplied roles is not a Role, Snowflake or Array or Collection of Roles or Snowflakes.
Can you please help me? Thanks
for help with discord.js go to the discord.js server: https://discord.gg/bRCvFy9
The original contract that was communicated to us was that one guild per request would only be enforced if we passed in the intent key. Everyone who develops a library also states that this was what was communicated to us.
Breaking our libraries that don't pass the intents key was not communicated to us in any capacity. I think this change should be reverted if you don't pass the intents key so it can work just like it used to without breaking every old client out there.
Description
When browsing to a URL that doesn't exist under https://discord.com/developers/docs/, such as , the page will appear to load to the normal dark background, and show the loading circle that normally appears on the right half, but will stay at this point indefinitely. No page will load, not even a 404 page -- but importantly, nothing will appear on the left panel usually used for navigation either.
A wrong URL is usually the result of user error when typing in the URL ...
also, minor but the colors of the 404 text effect in the normal dev portal 404 page (https://discord.com/developers/meme) are wrong
i get this error when i run node ./src/bot.js and i dont found my answer on the all issues
UnhandledPromiseRejectionWarning: FetchError: request to https://discord.com/api/v7/gateway/bot failed, reason: connect ETIMEDOUT 10.10.34.35:443
at RequestHandler.execute (D:\MyDiscordBot\node_modules\discord.js\src\rest\RequestHandler.js:93:15)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async RequestHandler.push (D:\MyDiscordBot\node_modules\discord.js\src\r...
By the looks of it you are running through a proxy of some sort. Either way, this is not the appropriate place for errors with Discord.js, this is for the API directly. Please join the Discord.js server and ask there.
Discord.js server: https://discord.gg/bRCvFy9
Description
As it currently stands, Channel Updates have 4 (or 3?) distinct criteria for hitting a rate limit. For those who are unaware, the main one to note is that channel name / topic changes now fall under a 2 requests every 10 minutes. Attached is the announcement made by Mason, and link is: #api-announcements message
. However supplying X-Audit-Log-Reason seems to override this
It would be nice to be able to specify reactions in the message create payload for bots that incorporate a lot of reaction based controls. Currently, it takes many API requests and a few seconds to add a few reactions to a message: Allowing them to be provided in the message create payload would reduce this to a single request and also enable users to start controlling the bot faster after issuing s command.
Hi, these are two different small changes that I figured should both be made under the same PR.
The first change is that RFC 7009, "OAuth 2.0 Token Revocation", is mentioned next to the Revocation URL. I did this because RFC 6749 is linked just above, for those implementing OAuth2 from scratch -- so knowing how to implement token revocation would be good for them to know too.
The second change is more of a nitpick. It mentions how you should use Basic authentication when using the Clien...
Something to this effect was already rejected here: https://github.com/discord/discord-api-docs/issues/182#issuecomment-262388833 and here: https://github.com/discord/discord-api-docs/issues/1301 and is also a bit pointless to add at this point as there will be a future API update for proper buttons, inputs, etc. See this blog post: https://blog.discord.com/the-future-of-bots-on-discord-4e6e050ab52e
Description
Just 2 weeks ago, the code below worked. That is, I write "!my_command 0000000000000000" to the chat, and then the bot returns its nickname and tag to the console in the format "user_name#0000".
Now, when I run the same code, i can specify any id but, the bot always returns None to the console. At the same time, nothing has changed at all, users did not change their nickname (although the id does not depend on this), and even more so did not delete their acco...
Hello! The gateway was updated few days ago, you need to manage your intents in your bot's config
Sorry, but I didn't quite understand what exactly is required of me? I mean, what exactly am I supposed to do to get the code working again?
I'm having this same issue right now, what can I do?
You need to enable intents for your bot. https://dis.gd/gwupdate
But as far as I understand, intentions only concern guilds here, and with the help bot.get_user(id) I could get user information regardless of the guild
Okay, while I solved the problem by giving out all intents, I'll figure out later how it works. Thanks for the support! :)
I used discord regularly and from 1 day to another it would not start and came up with the message i have attached as a file...
Is there anyone who have experienced this issue? and how do i overcome it, so i can have the discord available for my pc again.
(i tried uninstalling it, and install it again to see if it helped but did not).
This repository is related to the Discord API documentation and issues with the API, for problems with the actual Discord client, please contact support at the following link: https://dis.gd/support
you should use fetch_user instead of get_user
I would consider usage of this deprecated, and it may ultimately be removed in the future.
Assuming I'm understanding this correctly (that the Create Group DM endpoint is deprecated), would that deprecate the Group DM Add Recipient and Group DM Remove Recipient endpoints by extension? And if so, would that deprecate the gdm.join OAuth scope too?
Added aegis.cpp's server invite, and invites to DAPI channels for libs without support servers.
Maybe we should put different text for dapi links? idk
| [aegis.cpp](https://github.com/zeroxs/aegis.cpp) | C++ | [Invite](https://discord.gg/w7Y3Bb8) |
| [discordcr](https://github.com/discordcr/discordcr) | Crystal | [Invite](https://discord.gg/puaxPkK) |
| [Discord.Net](https://github.com/RogueException/Discord.Net) | C# ...
Indeed, I tried to specify a user previously unknown to the bot, and returned None again. Works better with fetch_user(), thanks :)
This would also be very useful for bots that repost content from normal users such as starboard bots; there isn't a workaround for those like there is for admin-set or dev-set emojis.
For a starboard bot now, you could actually use webhooks, which are able to use all emojis, as they are now capable of editing and deleting messages
@night Maybe it was accidentally restricted? I get a 50001 Missing Access when the bot doesn't have the Members intent.
couldn't this just be represented by a ? on the limit field in the table?
Webhooks technically can't use all emojis, they need to be non deleted and they can't be unavailable (from a guild which lost a boost causing the emoji to grey out). Possibly also emojis that are role locked but I can't remember that.
When you send an embed like this through the webhook API
it will return the following error now: Only dictionaries may be used in a ModelType
So I think the bug is: New API does not understand that embeds are delivered in lists for webhooks (that's what the docs say.)
Unable to reproduce this issue
POST: https://discord.com/api/v8/webhooks/ID/TOKEN
BODY:
{
"embeds": [{
"title": "Hello!",
"description": "Hi! 😀"
}]
}
Works fine.

I've also experienced this, but only for actions on pull requests (none of them arrived). I think that is the specific problem, maybe consider specifying the issue title
@advaith1 Just double checking, these invites are perma invites right?
The limit is 100, not 1000.
Because of the recent update of Discord in v8, my Discord Bot no longer works properly.
I'm trying to retrieve the number of users having a specific role
const memberCount = guild.memberCount; // Still works
const membersFromGryffindor = guild.roles.cache.get(metadata.gryffindor.role_id).members.size; // No longer works (got 0 but no error)
Does someone knows how to fix it ? I couldn't find anything on official documentation...
Thanks in advance
I'm currently writing a bot and I've run into an issue when trying to run it. It is telling me that it cannot connect to the host (discord.com:443). It says that it is a certificate error, which it is, but I have no idea how to fix it. I've gone on multiple forums that have said to go to https://crt.sh/?id=1 and download the certificate, but I'm not going to trust something straight of the internet like that, plus, I'm not well versed in cybersecurity. Any help is greatly appreciated
T...
Did you change your system clock? Your error says that discord's SSL certificate has expired; so your issue may occur if you set your system time behind certificate expiration dates (in discord's case: 7th May 2021).

I just copied them from their GitHub repos, so probably
They are using cloudflare's ssl, they are always up to date, it's probably a problem on your end. As @angelobreuer said, check if your system clock is good
check if your intents are configured correctly (what's that?)
this wouldn't have always given a correct number before anyway. you need the members intent and you need to fetch all members in the guild to have all members cached.
you can enable the members intent in the dev portal https://discord.com/developers
to get help with discord.js go to https://discord.gg/bRCvFy9
note that this has nothing to do with API v8.
Description
Using a link or text which is quite lengthy and does not contain spaces in the MessageEmbeds .setAuthor property causes the content in the embed spill out of the embed itself.
Screenshots/Videos
Client and System Information
discord.js: 12.4.1
Latest Stable and Canary
Windows 10
Description
Steps to Reproduce
Expected Behavior
Current Behavior
Screenshots/Videos
Client and System Information
This partial deployment limbo is quite a headache.
Unless I'm missing something here this is still not documented (which already halts the implementation for us as we choose to not merge any features that are not documented to keep our sanity and semantic versioning promises).
The guild deploy is another aspect that's quite hard to plan around: If it happened/happens this can all be convenience getters, which don't require API requests. If we can not rely on this we don't really have a ...
Bot Activity disappears
I don't think it is acceptable to have to refresh the activity on a regular basis, it should be that the bot will retain its activity setting it once (just like a custom status for users it will remain until changed)
This is an issue with the library or how discord operates with bots and should be changed
I agree
Just wanted to change some stuff to help people have more fun coding
I would revert this as "redirect.com" is a real service that would essentially get free advertisement by using their domain. If you wanted it to be more professional, then you should use an IANA-managed reserved domain such as example.com.
Same thing, I would revert this change.
Same thing as above, I would revert this change.
This site you changed it to is a real site (also, not to mention one of those "get this browser extension to verify your identity"). Same as above.
Same thing as above with the domains.
i was just changing the perms
I think this was misspelled by intent but correct me if I am wrong.
Also, a similar change was declined some time ago: https://github.com/discord/discord-api-docs/pull/1875.
I do not see the point of changing the version here?
I agree with @BrightSkyz. Is there a reason why you want to change the domains? I think everyone knows those are fake URIs, and if not, they will know if they look them up.
There is no discord directory at the repository root
Well it was for me, but it just went with the whole thing
Yes i found that out, that's why i took it out
I was looking at a wrong diff/commit in the PR; I did not see you removed it in a later commit.
Description
I'd like to request an API endpoint for bulk-editing the voice permissions of users in a particular voice channel.
Essentially, a bulk version of PATCH/guilds/{guild.id}/members/{user.id}, but purely for server-mute and server-deafen.
Why This is Needed
I maintain one of several bots designed to automate voice channels for users playing Among Us. The biggest hurdle faced by my bot, as well as [my mai...
There is no point whatsoever to linking this when you're already on the Discord dev docs.
I imagine this was !wumpus for a reason; why change it?
Should revert this too
Hi. I'm just going to be upfront and say that I'm not sure this would get through, regardless of whether these changes were made for clarity's sake.
I say this because Discord has previously closed #2127, an issue making a single change like the one in this (because of concerns of being hard to understand), because they want their docs to give off the tone of a (quote) "playful and fun brand that doesn't take o...
This is unnecessary, and I don't get why you would make a bot, with only a help command.
Perms: 1 doesn't even exist lol.
These docs are not only for bots, they also are for store pages, rpc/ipc/ and dispatch. There is no reason to just say bot.
This is for CI and building, you shouldn't be changing this.
It's like this for a reason, just to make it look cool. Check out #1875.
I didn’t read that it said ‘commands’ I thought it said command so that’s why
Ok let me just say this, I only made this pull request, it was only meant for some things not everything that I changed
I'm going to go ahead and say that this was intentional, as v8 isn't the default yet. They won't make examples for stuff that isn't officially the defualt. This should be changed once v8 becomes the defualt though.
this was probably an oversight, v6 is deprecated and is not recommended for use anymore, and the documentation only reflects v8.
imo the hyperlink should be like this: Revocation URL
that way it provides details on it, but doesn't clutter up the space with a name (which isn't that useful if you have a link).
Other than that, lgtm!
Hey! A bunch of commenters already kinda got the idea, but yeah overall Discord kind of enjoys the "playful" tone of our dev docs.
Almost all, if not all, of the changes in this PR are mainly around flavour text, and while we understand that it's not for everyone, we're gonna keep it as-is, at least for now. :)
Oh ok, I just wanted to make a pull request that people liked but I guess everyone doesn’t like my stuff 😭
It's alright, I appreciate the effort regardless.
I changed it to [Token Revocation](https://tools.ietf.org/html/rfc7009) URL as I wanted the link to refer to the act of Token Revocation, rather than imply that it would link to info about how to use the URL.
I realize that might sound a bit nitpicky, but eh.
a3b813b Mention RFC 7009 next to the token revocation U... - LikeLakers2
203b916 Update changelog and chunking requirements (#2178) - MinnDevelopment
de09ff2 Update integration docs to v8 behaviour (#2175) - FasterSpeeding
@tpcstld Thanks for the merge. I was actually about to make one final change, though (before my internet decided to die) -- the warning below the table was going to be changed to reference the token revocation URL, rather than just the token URL, as both of them seem to require the x-www-form-urlencoded content type.
> warn
> In accordance with the relevant RFCs, the token and token revocation endpoints will **only** accept a content type of `x-www-form-urlencoded`. JSON co...
If you could put it up in a separate PR that would be nice. (I don't have access to a laptop right now.)
Nah, it'll take me like two minutes. I'll just get it done for you.
Hi! This is a small change that I was going to make over at #2194, however the PR was merged before I could make it. So it's going in its own PR.
I opted to remove the URL to the URLs table, as this warning is right below it. I also removed the references to the RFCs, as we are now referencing URLs that are from two different RFCs (and it'd be awkward to change that warning every time a new OAuth2 endpoint is added).
aee6333 Update the warning below the URL tables, to ref... - LikeLakers2
Hi! I was notified in the Discord API server, some time after my last PR was merged, that the OAuth2 Token endpoint supports submitting parameters as Content: multipart/form-data. After testing this for myself and verifying that this was the case, I found myself confused -- this seems to be flying in the face of the relevant RFC (RFC 6749), which always says to use application/x-www-form-urlencoded.
I thought it might of been a quirk of how Discor...
This is likely due to a quirk of our API framework. For POST requests with values, the framework automatically accepts and parses both kinds of content type.
I haven't consulted with others yet (it's late here), but I would consider this to be an un-intentional error in the API. I would encourage people to use x-www-form-urlencoded, and we will probably only "officially" support that version. However I believe this is probably not a high-priority fix (?), unless I'm missing something i...
Thank you -- even if it might not be fixed (though I kind of hope it is at some point -- I like things staying to spec, personally), it's nice to have an answer.
The only thing I can think of regarding allowing form-data for this (even if unintentionally) is that it may require the API to receive somewhat more data from the client. You can see an example of how form-data sends stuff here, just in case anyone ...
nicememe.website made firefox give me a Warning: Potential Security Risk Ahead message. About that...
I am pretty sure that permission 1 / CREATE_INSTANT_INVITE exists; see https://discord.com/developers/docs/topics/permissions.
It also gets listed when adding the bot:

As it currently stands, Channel Updates have 4 (or 3?) distinct criteria for hitting a rate limit. For those who are unaware, the main one to note is that channel name / topic changes now fall under a 2 requests every 10 minutes. Attached is the announcement made by Mason, and link is: #api-announcements message
image
Thus, Channel Updates have several possibilities to reach a 429
Just a name change => 2 every 10 minut...
I can't figure out what these params mean. At first, I assumed it meant I could tie an invite to a specific user, which is exactly what I was trying to do (so sharing the link would require logging in as that user). But it seems like this is for something else because passing target_user or target_user_id doesn't work (the former doesn't throw an error but doesn't change anything, the latter throws GUILD_INVITE_INVALID_TARGET_USER_ID.
{
"max_uses": 1,
"unique": tru...
When a user is watching a stream and clicks the invite button in the stream, the invite's target user id will be which user's stream to view.
This PR changes the nick field from being nullable to being nullable and optional.
The documentation currently indicates that nick in guild members is nullable but not optional, yet this field does not appear when receiving members without nicknames through the Gateway (e.g. GUILD_CREATE).
Is this still a wont fix? I notice there's a Allowed Mentions object available now. Would it not be possible to resolve mention without pinging via this?
allowed_mentions has the same issue, it won't render unless the user is cached.
related feature request: #2126
Description
Why This is Needed
Alternatives Considered
Additional Details
what a nice issue amirite
Description
When a bot has no 'Embed Link' permissions he should still be able to send embed messages.
When a user turned off 'Show website preview info from links posted into chat' setting, it should still show embeds of webhooks and bots
Why This is Needed
I guess that this permission/setting was added to prevent abuse of link embeds by server members eg. NSFW Content. For bots, it doesn't make sense, because most of them depend on embeds to provide full functionality.
Th...
This doesn't make sense, as embeds act like a link to a client. I personally discourage them for this reason, and recommend people to use code blocks with a language like adoc:
===== LEADERBOARD =====
1 :: someName
2 :: anotherName
3 :: (none)
4 :: (none)
5 :: (none)
6 :: (none)
7 :: (none)
8 :: (none)
9 :: (none)
10 :: (none)
``` (the `::` has special highlighting in Discord)
Bots should not get special treatment when it comes to embedding for users. If a user does not want to receive embeds and previews, the client will always respect that. As far as permissions, the solution to this is for a server admin to give the bot the permissions it needs - so make sure to request those permissions in the bot's invite. If the admins don't want embeds, again, it's their choice, bots should not bypass user permissions and choices.
For bots, it doesn't make sense, because most of them depend on embeds to provide full functionality.
Bots should never rely on having any permission (except maybe send messages -- bots will almost always have that one), as their permissions can be edited at any time. If a bot is asked to do something that it doesn't have permission for, it should be ask to be given that permission.
With that said, I'm not sure I understand this "needed for full functionality" argument either. While l...
I personally discourage them for this reason, and recommend people to use code blocks with a language like adoc:
Code blocks have way fewer features and look worse. Especially working with images is a key feature of embeds. Messages don't allow editing images, but embeds do.
Without embeds, developer have way fewer options to display information
Bots should not get special treatment when it comes to embedding for users. If a user does not want to receive embeds and previews, the ...
For my bot, wrong permission setup is the top 1 issue in support even through my bot already providing help for permissions.
I think you misunderstood my response.
If someone hasn't given your bot something like Manage Roles when it needs Manage Roles, that's a different story. If you're having issues with your users being unable to set up permissions even when given instructions to, that's a different story.
What I am saying is that you should never rely on Embed Links just t...
What I am saying is that you should never rely on Embed Links just to be able to serve a response, as Embed Links can be removed from your bot's permissions at any time.
the point of this feature request is to change that
Bots should never rely on having any permission (except maybe send messages -- bots will almost always have that one), as their permissions can be edited at any time. If a bot is asked to do something that it doesn't have permission for, and you absolutely need that permission for that action, it should be ask to be given that permission.
The current way to solve this issue is by telling the user, that he should grant those specific permissions. As mentioned in my comment above, many us...
The comment you quote was just a response to eslachance and thetayloredman
My bad, I somehow misread the quote. >_<
The comment you quote was just a response to eslachance and thetayloredman
My bad, I somehow misread the quote. >_< Sorry.
The current way to solve this issue is by telling the user, that he should grant those specific permissions.
That's one way to solve it, but personally I wouldn't rely on having Embed Links just to be able to generate a response. Needing a permission that sounds like it's related to links, when you're not sending links in response, can really confuse users. ...
I suggested this years ago:
- Rename the permission to make it clear this applies to more than just links
- Add a fallback parameter which bots can populate, similar to the noscript html element
Example:
{
"description": "Your command worked!",
"color": 123812,
"author": { ... },
"fallback": "Your command worked!"
}
- Add a fallback parameter which bots can populate, similar to the noscript html element
Now this does seem like a good idea, so bots can use embeds, without the worry of having it disabled where it can have a fallback message (or code block for my use case). And, perhaps splitting EMBED_LINKS into something like USE_LINK_PREVIEWS and SEND_EMBEDS? (with a different name of course)
@advaith1 Thanks, that makes sense now.
Yeah, those do make embeds look nice, but I still wouldn't rely on them. Everything you mentioned (and everything I can think of on top of that) sounds like it's ultimately "a nice thing to have" rather than "absolutely needed". If you are able to send embeds, go ahead and use those features -- but don't make the functionality of your bot hinge on the permission.
I and other people don't depend on them but switching to normal text would drastically decrease the usability. Usability is a ...
Discord should just have a separate permission for bot embeds that has nothing to do with links IMO. https://github.com/discord/discord-api-docs/issues/1657
How can I fix this error sent by the console?
data: index.js:4128 - Niespodziewana Odmowa. { DiscordAPIError: Unknown Message
data: index.js:4128 - at item.request.gen.end (/home/exbot/node_modules/discord.js/src/client/rest/RequestHandlers/Sequential.js:85:15)
data: index.js:4128 - at then (/home/exbot/node_modules/snekfetch/src/index.js:215:21)
data: index.js:4128 - at process._tickCallback (internal/process/next_tick.js:68:7)
data: index.js:4128 - name: ...
you are trying to delete a message that doesn't exist.
for discord.js help go to https://discord.gg/bRCvFy9
you are trying to delete a message that doesn't exist.
for discord.js help go to https://discord.gg/bRCvFy9
the problem is that my bot is public, so there is no other solution? some line or something?
Greetings,
After a few recent updates, I'm unable to click on any link placed in Discord (be it through "open original" or clicking on the link itself depending on the type of linked content).
I can't really reproduce the issue and am not well versed in programming to give you proper details, but I was hoping you could look into the problem and tell me what I need to provide to help you gain more insight into the issue.
Client bugs go to https://discord.gg/testers
This repo is for api bugs
This PR marks height and width in a message's attachment as being optional in addition to only nullable.
Creating a message with a file that is not interpreted as an image (e.g. a txt file) results in a message response with an attachment that does not contain the height and width fields.
This PR marks last_pin_timestamp in the Channel Pins Update Event as nullable in addition to optional.
Unpinning a message in a channel fires a CHANNEL_PINS_UPDATE event that has the last_pin_timestamp field set tonull.
Description
When a bot is already part of a guild and a bot scoped oauth request is received, it should not require a captcha.
Why This is Needed
If the bot is missing permissions at the guild level, a bot invite link can be quickly used to grant the missing permissions in bulk without needing to go to the role menu.
Alternatives Considered
- Telling the user to give the bot more permissions. This is the current solution, but some people don't understand Disco...
Description
Complementing #2216, it would be great if the channel_id parameter already possible for webhook.incoming was available for the bot scope. If given in combination with the guild_id parameter, it would create a user level override granting the permissions you have selected. This of course would only be available when the bot is already in the guild (I guess this is optional, but would be a little weird otherwise.)
Why This is Needed
This would provide a simp...
Allow bots to bring up an interface with a pre-filled modification in the client to change permissions in some way.
https://github.com/discord/discord-api-docs/issues/1657#issuecomment-634357645
Description
The client uses this endpoint to get the album and artist IDs of a user's Spotify song to load the URLs in the browser.
Currently, bots cannot use this endpoint, but it doesn't seem to be an issue to let bots with the Presence intent use it.
Why This is Needed
Currently, Discord can make the Spotify album and artist names links, but bots can't. This isn't really needed but would be nice to have.
Alternatives Considered
Sending the additional IDs in the norm...
This isn't really needed but would be nice to have.
Unless there's a need for this - I don't see us opening this up.
Description
Whenever I upload a Rich Presence asset on the developer site, it takes roughly 10 minutes for the asset to become accessible (e.g. listed in the asset list, accessible from the Discord RPC API)
Here's a post on the Discord support forum that is probably related.
Steps to Reproduce
- Go to https://discord.com/developers/applications
- Select your app...
Can reproduce and DAPI has had several complaints of it not working for other people either.
Description
In Gateway#Sharding for Very Large Bots the documents says "If you own a bot that is in over 250,000 guilds" and in the Policy#API Limits describes that "If you are in over 200,000 guilds" you should reach out to support for further informations and developments. But here is the mismatch is it 200,000 guilds or 250,000 ? Yeah it i...
I have another use case for this:
<img width="429" alt="Screenshot 2020-11-07 at 19 53 58" src="https://user-images.githubusercontent.com/13135287/98449333-fce6d600-2132-11eb-99c6-5e407254c201.png">
what you see is results from a search tool for deno modules; i was hoping to be able to add links for the modules to the name of the fields, but then sadly found out that such isnt possible.
It should probably be made clear that this threshold is different from bot to bot. These numbers are an average indication but some bots needed it from 180k servers while others are happily going along at 300k on "small" bot sharding
Hi!
While chatting within the Discord API server, it was noted that the Token Exchange step requires a scope parameter, though the RFC does not specify a scope parameter as needed during the token exchange. After doing some testing, I found that the Token Exchange step outright ignores the scope parameter. I have thus removed the scope parameter from the Token Exchange documentation.
I've also taken this opportunity to update th...
@Elektron-blip Most likely an expired SSL cert.
Ah I see.
Description
Steps to Reproduce
Expected Behavior
Current Behavior
Screenshots/Videos
Client and System Information
const { Client } = require("discord.js");
const client = new Client({ ws: { properties: { $browser: "Discord iOS" } }});
client.on("ready", ()=>{
client.user.setPresence({ activity: { name: "Hello There!", type: "WATCHING" } });
});
for discord.js users :)
Why are you responding on an issue that's over 10 months old with an answer someone has already posted?
Description
Attachments that have been uploaded to channel that got deleted are not being removed from Discord CDN.
Steps to Reproduce
• Create a text channel or choose an existing one
• Post a message with attachment
• Copy link to that attachment
• Delete that channel
• Visit that link you copied. Attachment is still on Discord CDN.
Expected Behavior
Attachment should be deleted from Discord CDN.
Current Behavior
Attachment isn't deleted from Discord CDN.
...
In some cases, your device may pull from cache instead of loading from the CDN, as the file is already gone there.
In some cases, your device may pull from cache instead of loading from the CDN, as the file is already gone there.
Outside Discord app? No. It's not possible.
*Unless you visited that link before channel deletion.
!!English Below!!
Türkçe
Emir lütfen gerekli yerleri düzgün ve detaylı bir şekilde doldur aksi takdirde ne demek istediğin anlaşılamayacaktır ayrıca lütfen sadece İngilizce yazman gerekiyor buraya bakan çoğu kişi Türkçe bilmemekte.
English
Emir, please fill in the required fields properly and in detail otherwise what you mean will not be understood. Also please write only in English. Most people who look here do not speak Turkish.
What I mean is this: My bot's profile picture doesn't change. I'll put
another photo, it doesn't work. One, there is an error. Do you have to
Thank you :))
8 Kas 2020 Paz 19:38 tarihinde Zamion101 notifications@github.com şunu
yazdı:
!!English Below!!
Türkçe
Emir lütfen gerekli yerleri düzgün ve detaylı bir şekilde doldur aksi
takdirde ne demek istediğin anlaşılamayacaktır ayrıca lütfen sadece
İngilizce yazman gerekiyor buraya bakan çoğu kişi Türkçe bilmemekte.*Englis...
What I mean is this: My bot's profile picture doesn't change. I'll put another photo, it doesn't work. One, there is an error. Do you have to Thank you :))
Don't comment your problem. You need to fill in the required fields (like Description, Steps to Reproduce, Expected Behavior and so on) properly and in detail! Please edit your Issue or delete and open new one with properly and in detail.
Ok. Thanks :)
8 Kas 2020 Paz 19:51 tarihinde Zamion101 notifications@github.com şunu
yazdı:
What I mean is this: My bot's profile picture doesn't change. I'll put
another photo, it doesn't work. One, there is an error. Do you have to
Thank you :))Don't comment your problem. You need to fill in the required fields (like
Description, Steps to Reproduce, Expected Behavior and so on)
properly and in detail! Please edit your Issue or delete and open new one
with properly...
You need to use the Modify Current User endpoint. Changing the application's avatar may not change the bot's avatar.
Very İmportant!!
Huh .. Bot, I was changing your avatar. I want to change the profile photo
of my bot. Not happening. There is a problem. How can I do it? Do you
understand? Thank you :)) :((
8 Kas 2020 Paz 19:55 tarihinde SinisterRectus notifications@github.com
şunu yazdı:
You need to use the Modify Current User endpoint. Changing the
application's avatar may not change the bot's avatar.—
You are receiving this because you authored the thread.
Reply to this email directly, ...
I want to change this, it doesn't change. There is a bug. I need help.
Thank you :)) :((
8 Kas 2020 Paz 19:55 tarihinde SinisterRectus notifications@github.com
şunu yazdı:
You need to use the Modify Current User endpoint. Changing the
application's avatar may not change the bot's avatar.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/discord/discord-api-docs/issues/2223#issuecomment-723634093,
...



