API plans

[typpo]

This roadmap is deprecated. Use the Discussions feature to add and upvote API suggestions.

Here are our current plans. If an item is on this list, we're actively working toward it!

Last updated: 2023-11-17

Developers

• New option types
  • Floating-point number
  • Attachment
  • Autocomplete - choices populated dynamically by the application
  • Datepicker
• Text input interaction
  • Desktop
  • Android
  • iOS
• Age-gated commands - a way to mark commands NSFW so they will be hidden in non-NSFW channels and to age-gated users
• Context menu commands
• Limit CHANNEL option type to certain channels (text, voice, category, etc)
• API v10 preview
• More ways to describe/customize your app in the dev portal

User experience

• Nested/collapsible autocomplete - (top level > subcommand groups > subcommands). This will clean up the commands menu significantly
• Add autocomplete for option names
• Improved behavior/UX when filling out slash commands (in beta)
• Frequently used commands
  • Desktop
  • Android
  • iOS
• HTTP interaction bots will not show as offline
• Improved entry point for mobile users
  • Android
  • iOS
• More informative rate limiting errors when clicking Buttons
• Ability to localize slash commands
  • User/guild locale on interactions
  • Ability to set translations for slash commands
• Mentionable/channel types for the Select message component

Moderation

• Revisit the permissions system to make it more flexible
• Ability for server admins/mods to manage slash commands
• Ability to manage command permissions with channel-level granularity

Developer support

• 5 business day SLA for intents requests
• 5 business day SLA for verification requests
• Improved bot verification form
• Verification path for HTTP-only applications

[Lulalaby]

Great to hear, as always ❤️🔥

[dvd-22]

Age-gated commands seems pretty useful for... specific use cases lol. Glad to see these improvements being made

[Andre601]

It's generally speaking always a problem to verify someone's age.
I mean... The fact that you should be 13 or older to even make a Discord account is not stopping minors from creating one. After all is the only thing stopping them an "I agree to the Terms of Service and Privacy Policy" checkbox and maybe a captcha, but that's pretty much it.

The same applies to 18+ stuff. People can just fake their age on the internet. It's a sad problem existing since the birth of the internet itself and sure won't go away any time soon.
The most Discord here could do is make regular checks to verify an Accounts information (And the bot verification is IMO a good part of this as people need to verify with official documents (ID, driver's license, ...) but that only applies to the Bot dev itself).

Tl;dr: Making sure people won't use the stuff they aren't supposed to is harder than it looks. Especially on the internet.

[greysdawn]

Well the concern here was that underage devs shouldn't have access to creating/marking NSFW commands, which can be mitigated with a verification system using official docs like the bot verification system. There's still ways around it, but it'd be one way to fix that concern, which was the point I was trying to make- it's pretty hard to fake your age when you need to show official docs to verify it. Not marking NSFW commands properly would also be an issue come verification time, if not an issue before then due to it getting reported or bot growth sites (ie. top.gg) requiring things to be marked accordingly

That said, I know it's hard to keep minors away from NSFW content. As a mod in several large communities, I've had to bonk a lot of them for admitting to getting into NSFW spaces or sharing content they shouldn't 😅
It's a complicated problem that still can't completely be solved with age verification, regardless of the method used, and I understand that. I just think it'd be a lot harder for devs to get around it due to how strict Discord's verification system is

[ThePotatoGuy]

Can this be prioritized, or at least completed well before the august deadline? My bot has around 30 NSFW commands that I can't safely migrate over without affecting the thousands of servers its in.

[hollowstrawberry]

Yeah this seems pretty urgent in my opinion. As a workaround you can set default_member_permissions to 0 for nsfw commands to hide them, and an admin needs to enable them (ideally for specific channels). You would still need to check manually that the channel is marked nsfw.

[BotDevPanda]

Don't forget to make sure that <18 developers can't use this feature!

Or... Make it so ONLY Verified Bot Devs can use the feature, since they have to submit an ID for verification anyways

[WilsontheWolf]

How about an option to allow a user to submit multiple inputs (such as choices for a poll command). This would be better than having a whole bunch of options to add them or parsing a string.

Also a text input interaction would be handy. This would allow you to have users respond to something on the request of the bot without re-running a command or using the intent.

Edit: the text input would be really handy to use with context menus.

[UltimateSppy765]

like channels that user can't manage or generally any input that cannot be filtered by slash command arguments right now

All channel inputs in slash commands are validated by the API itself, you don't need to worry about the user sending in an invalid channel.

[danbulant]

All channel inputs in slash commands are validated by the API itself, you don't need to worry about the user sending in an invalid channel.

They can't be filtered though. API will check the channel exists, but not if the user can manage it (if user has specific permission in a given channel), or even if the channel is disabled in bot settings itself (in my bot, you can set permission to use command per channel per role, and that can't be done in API nor I saw any plans on adding that).
Slash Commands will just downgrade the experience for my bot as they are now. Even if I use them just to list commands (which don't fit in the limit, so not all commands will be available).

[ckohen]

I don't understand how that downgrades the experience. You can still do any amount of validating in your code and if it considers it invalid input, you can respond with an ephemeral error. That's a way better user experience for me. Plus, you are guaranteed whatever argument you are checking is the right type because of the API validation mentioned.

Please don't do this, but just to illustrate that slash commands can only ever expand on message commands, you could totally make a /command content: ping (where content is a string type) and then parse that command out as a message command if you really wanted. You can only gain functionality from this unless you are using something within standard messages (i.e. not a prefix) to trigger your command.

[JustCat80]

I don't understand how that downgrades the experience. You can still do any amount of validating in your code and if it considers it invalid input, you can respond with an ephemeral error. That's a way better user experience for me. Plus, you are guaranteed whatever argument you are checking is the right type because of the API validation mentioned.

Please don't do this, but just to illustrate that slash commands can only ever expand on message commands, you could totally make a /command content: ping (where content is a string type) and then parse that command out as a message command if you really wanted. You can only gain functionality from this unless you are using something within standard messages (i.e. not a prefix) to trigger your command.

also things like message attachments, and I get that it's temporary but it probably should have been added before they decided to start moving over

[UltimateSppy765]

All channel inputs in slash commands are validated by the API itself, you don't need to worry about the user sending in an invalid channel.

They can't be filtered though. API will check the channel exists, but not if the user can manage it (if user has specific permission in a given channel), or even if the channel is disabled in bot settings itself (in my bot, you can set permission to use command per channel per role, and that can't be done in API nor I saw any plans on adding that). Slash Commands will just downgrade the experience for my bot as they are now. Even if I use them just to list commands (which don't fit in the limit, so not all commands will be available).

This is a mock up of an upcoming feature posted originally in #event-info channel of DDevs, this might be what you are looking for:

Also you can use ephemeral responses to validate error messages and the channel selector only shows the channels that a user can view, plus you can further shorten that list to only specific types of channels if you wish.

[hemanth351718]

Alright so we can apply for intents if we NSFW commands right?

[ghost]

you can apply for intents, but what does that have to do with NSFW commands?

[v1ctorio]

you can apply for intents, but what does that have to do with NSFW commands?

Because you can send nsfw content in

Or add it to the 3 dots on a message "Copy Command" like there is for message urls

[UltimateSppy765]

Alright so we can apply for intents if we NSFW commands right?

I don't think so considering NSFW Slash Commands are in the works.

[GoldenAngel2]

Imo the one thing that needs to be looked into is being able to delete ephemeral messages.

Since interactions last only 15 minutes, couldn't Discord store ephemeral messages for 15 minutes then delete it from the system? that would be better than the current system. (unless there is some infrastructure issues with doing that)

[erkinalp]

Then, it would not be ephemeral anymore, it would be limited-retention.

[ghost]

Ephemeral is limited-retention.

[bassner]

This is really important. I understand that these messages are not stored, but please give us

• a timeout option that we can send with ephemeral messages that makes the receiving client auto-dismiss it after X seconds
• the ability to delete them manually using the interaction endpoint. This could be realized by sending an event to the receiving client to inform them about this.

I have a use case where users click a button, and get an ephemeral messages like "Please check your DMs". Afterwards, I have a more complicated flow in DMs.
Users may use this button several times per hours, and these "Please check your DMs" messages stack up if they don't manually dismiss it. I'd love to remove this clutter using timeouts on your or my side, whichever works best for you.

But the timeout options seems to be most feasible as it's only an additional data point when sending ephemeral messages, and one call to set a js timeout in the client, so it might be an easy option for you guys to implement.

[JackCrispy]

Also possibility to have send backs on ephemeral messages, say a user clicks a button, other than url which works.

[TurnrDev]

Discord is already using "ephemeral" wrong anyway. Ephemeral means "lasting for a short time" but Discord is treating it as also meaning "private"

[ghost]

It would be really nice for our use-case to be able to receive a slash command and not need to reply to it. Our bot currently deletes and re-sends user messages with a webhook, and this creates a lot of message deletes.

Being able to receive messages through an interaction and re-send them without having to delete the original message would be a big improvement over what we currently do; however, right now we would have to send an ephemeral message to the user, or have the client show them an "interaction failed" message.

I don't really expect this to be added, since it previously existed but was removed (I'm not sure why), but I thought I'd ask 😄

[DigiDuncan]

I haven't played with slash commands yet (my library hasn't implemented it as of time of writing) and it seems strange to me that this implies you MUST respond to the user with either an ephemeral message or an Interaction. Is that currently the case? I see tons of problems with that if true.

[ghost]

That is correct. You must reply to each command, either showing both the command and response to the chat, or showing both only to the user.

It is possible to not reply to an interaction, but it would show an "interaction failed" message.

[cmsteffey]

@Bluenix2 There used to be an ack type (type 2 and 3 both were) but they were removed once slash command usage messages were merged with the response, and "interaction failed" never showed

[JustusW]

@Bluenix2 There used to be an ack type (type 2 and 3 both were) but they were removed

Like. Seriously? I must admit I am beyond annoyed at this point with this feature. It could have been a great thing but with this hyper restrictive approach in all regards Slash commands might just be DOA at this point.

[NovaFox161]

Just for added context:
At the time they were removed because there was no way to know who was initiating the interaction (in the client), so bots (and subsequently users) were able to post messages that couldn't be moderated properly. At this time, it was also impossible to restrict certain application commands to certain roles or channels (still is, but we know that's coming)

I hope discord will add types 2 and 3 back once this happens. But these were removed for a good reason at the time.

[AnotherZane]

Allowing developers to specify a regex and maybe even a character length for the string option which can be used for client side and api side validation would be quite useful.

As for user experience, a 'replay' button for slash commands they send would be quite nice, essentially just resending the command with the exact same arguments.

[UltimateSppy765]

As for user experience, a 'replay' button for slash commands they send would be quite nice, essentially just resending the command with the exact same arguments.

For now you can implement a button bot-side that does it, I don't think Discord might be making replay commands a thing as we already have something called Copy command lol

[Mineinjava]

possibly a word filter for the string option could be useful, or specify some sort of pre-format

[Artemis21]

Is Discord seriously saying that it's not technologically feasible to make (or use) a safe regex engine?

[ooliver1]

Since they used rust-flavour - which has no lookarounds, this should still be possible.

[2br-2b]

This may have been added after this comment was left, but the replay option exists - if you run a command, then press the up arrow, then instead of editing your last message, it'll copy your last run command

[AnotherCat]

It would be nice to also have what has been seen and denied and why, so that we know it's not going to happen.
I do understand if this can't be done because it may be massive

[ghost]

With text-based commands, an user can copy paste a message to run the exact same command again. This should also be possible to do with slash commands, though I'm not sure how it would be implemented.

[RedcodesDev]

There is even a Button called "Copy Command" on Discord Mobile (Beta).

[ghost]

Related to this: a question that was asked in the live Q&A was how do two bots with similar commands resolve which slash command is being run? The answer in the moment was "you choose the bot you're using while you type the command", but there needs to be a way to copy paste a command where it also copies which bot you want to use, whether that's for your own use or for "giving" command usage to someone else for them to paste and run it.

[UltimateSppy765]

Related to this: a question that was asked in the live Q&A was how do two bots with similar commands resolve which slash command is being run? The answer in the moment was "you choose the bot you're using while you type the command", but there needs to be a way to copy paste a command where it also copies which bot you want to use, whether that's for your own use or for "giving" command usage to someone else for them to paste and run it.

If I remember correctly, copying the command on Desktop clients will invoke the same bot as the one you copied the command from. At least for me it works that way.

[ghost]

Btw, in telegram, when u call command which 2 or more bots have, you can do /ping@hehe_bot, or /ping@haha_bot, so u know that exactly this bot will be used

[2br-2b]

This may have been added after this was created, but:

To replay a command, press the up arrow on desktop to automatically re-enter your last command.
As for copying the command, click the slash command and you can see the exact code added

[alexhorner]

I would assume this is based off #3540 as well?

I'm really pleased to see that a lot of concerns from this discussion have been identified or at least match what appears on the list. There are a few bits which are missing however these are of no suprise, such as pattern matched content, the scope issues and the 100 server limit.

Hopefully we'll be able to get these into the conversation at the live event this evening, especially the pattern matching, as I think that would be quite desirable for many users and would allow us to retain some level of intimate interaction between users and bots etc. If I can make it I will certainly try to get that in!

[Rayrnond]

nice!

[paris-ci]

New options types ideas

For reminders and other calendar event, ban durations,...

• Dates
• Datetimes
• Times
• Durations

Not asking for rrulesets here, but if we could come close that'd be really helpful.

• Flags, maybe with values? (optional booleans to modify a command behaviour, think /ban @user --purge --no-log --send-reason)

[Mr-KayJayDee]

I love the idea of flags, could be very helpful for custom commands creation or user created embed etc... 👍

[Gideon-Foxo]

You could just have 'reason' be a string and look for flags yourself..?

[paris-ci]

You could just have 'reason' be a string and look for flags yourself..?

Not if I want autocomplete for flags name ?

[ToxicMushroom]

You could just have 'reason' be a string and look for flags yourself..?

You could create a slash command like /cmd arg:tempban 1d -t1 bad user and parse it like old text commands
We're suggesting improvements to slash commands, not because some stuff is impossible but because it can be a lot better.

[UltimateSppy765]

Can you not use optional options as flags?

[Snazzah]

Could there be a good way to reference a message within commands? Could be good use for messages that need to be recorded or used in reference to an action.

Another more shot-in-the-dark request is to reference stickers as an option. ¯\_(ツ)_/¯

[Gideon-Foxo]

It would be cool if you could reply to a message with slash but im not holding my breath on that coming

[Henry-Hiles]

Perhaps the upcoming context menus for bots could give a nice solution to this?

[Snazzah]

Perhaps the upcoming context menus for bots could give a nice solution to this?

Should still have options

[greysdawn]

Perhaps the upcoming context menus for bots could give a nice solution to this?

Main issue with this is that the context menu is still really clunky for people needing to follow-up for more info. Right now I have a bot that binds reacts to messages in order to open forms, and I have an argument that accepts a message ID- but there's no real validation for this except through my own code. Having an option type that explicitly asks for a message/id (or even a channel-message combo id) and validates that info for me would be an enormous help

[AnotherZane]

One thing that definitely needs to be improved is slash commands in dms, cause of how channel selection is for example (ie listing literally every channel in every guild the user has access to in no specific order), they just don't work well and fail most of the time. Would be a good idea for developers to be able to specify if commands are 'dm only' or 'guild only' - for global commands, since it doesn't make sense to create guild specific commands every time a new guild is joined.

[boehs]

Please a way to gate command visibility to certain users, roles, channels etc

Example:
Currently, any user can see mod commands when they hit slash. Not good UX wise :).

Example Two:
Only show restart and eval commands to me

Example Three:
Some commands only visible in #bot-spam

Four:
Only people with the role id 12345689 (role called regular) can use x command

Could be included in "better permissions" but unclear

[Gideon-Foxo]

I thought this one of the changes..? Unless im dumb, I figured this was kinda obvious

[boehs]

I thought this one of the changes..? Unless im dumb, I figured this was kinda obvious

Look, it was not mentioned and I have zero faith in discord given their past history. I really hope they turn it around this time.

[jhgg]

It is mentioned under the "Moderation" section.

[boehs]

It is mentioned under the "Moderation" section.

Not really, it states server mods can do it but says nothing about bot devs, as I mentioned at the bottom of my original post

[UltimateSppy765]

This is in works iirc.

[DraftProducts]

Do we have an expected date for the date picker?

[AlmostSuspense]

no, they never give release dates

[TurnrDev]

I'm also waiting on this

[ooliver1]

So are a lot of people, just be patient.

[JDJGInc]

It's likely that they are just curious nothing more.

[JDJGInc]

Mentionable/channel types for the Select message component

is not checked here, is this todo list outdated or is there more to come?

🤔

[alvgaona]

Are there any plans to improve the deployment experience? Automating different apps and bots from a CI/CD tool is essential. For that, we need an API that can configure the interaction endpoint, get bot tokens and other sensitive info safely and finally add the bots to the server. Also, remove them from the server and destroy the app if necessary.

[alvgaona]

It'd be nice if we could add the bot programmatically. Getting into the URL manually is ok, but doing it with a script it'd be awesome. Also, creating the app in the developer portal could be done programmatically. We still could get the sensitive information manually (for security reasons) and that'd still be ok.

[Artrix9095]

You mean stuff like autodeploy on git push etc?

[alvgaona]

Not exactly. Those workflows, pipelines, hooks, jobs, and whatnot can be built by the community. However, there's no way to do anything like that because Discord doesn't provide an API to create apps and associate a bot to a specific app in an individual account or even in a team. Additionally, to add a bot to a server you need to manually do it by inserting a link with the bot permissions in the browser; then, you select the server you want. All of that could be done programmatically, and we could create our own E2E bot deployments.

[greysdawn]

Discord doesn't provide an API to create apps and associate a bot to a specific app in an individual account or even in a team. [...] All of that could be done programmatically, and we could create our own E2E bot deployments.

this would all be pretty easy to abuse. the authentication flow to add bots to a server largely exists to make sure that you know what bots are being added. adding programmatic ways to do it without some kind of check would easily become an issue of abuse, whether that's through bots adding themselves to servers or something similar. there would need to be some way to force bots to only have servers that are owned by the developers be available to programmatically add to- i can get behind that, but i don't see anything good coming from a way for bots to just invite themselves willy-nilly

arguably, creating apps outright would also be easy to abuse. there are enough spam bots on the platform. adding a way for apps to be created programmatically would likely exacerbate that and make it even worse

[alvgaona]

Discord doesn't provide an API to create apps and associate a bot to a specific app in an individual account or even in a team. [...] All of that could be done programmatically, and we could create our own E2E bot deployments.

this would all be pretty easy to abuse. the authentication flow to add bots to a server largely exists to make sure that you know what bots are being added. adding programmatic ways to do it without some kind of check would easily become an issue of abuse, whether that's through bots adding themselves to servers or something similar. there would need to be some way to force bots to only have servers that are owned by the developers be available to programmatically add to- i can get behind that, but i don't see anything good coming from a way for bots to just invite themselves willy-nilly

arguably, creating apps outright would also be easy to abuse. there are enough spam bots on the platform. adding a way for apps to be created programmatically would likely exacerbate that and make it even worse

I'm afraid I have to disagree with your comment even though it's true that it could get abused as the current API is nowadays. This would be a major feature of the platform and an improvement for the community. You specifically said "...without some kind of check..." and I'm not suggesting this at all. Actually, I'm requesting for this feature but with the proper considerations taken into account, i.e., security and user experience.
The way I see it, it could only be implemented if the authentication, authorization, and accountability implementations change considerably. It is a challenge but doable, and even so, with the best security practices.

[JDJGInc]

This really needs to be updated, as mentionable selects have been added unless there are more.

[ooliver1]

There are many replies already mentioning this.

[ValiantWind]

3 Words:

Slash Command Aliases.

[JDJGInc]

Would be nice, but i don't know if discord wants to do this
I would love if this was added though

[ooliver1]

Users can see a full list of commands already and tab them in. The only reasons for aliases I found is for hard-to-read smaller forms, and for translations such as color and colour - which localisation solves.

[mrgharabaghi]

[splatterxl]

Better to make a new discussion about this as this discussion is to track current official API plans

[just-rich]

In regards to developer support, what about prompt support for developers in general?

I had an account that owner of a developer team with a verified bot that was disabled then deleted, but the ownership didn't get passed to the next and only user on the team that is marked admin. So now that user account can't add any others to the team. The verified bot is in almost 2,000 servers so asking all the servers to add a new bot just isn't logical, the team ownership needs to be transferred from the deleted account to the only other account on the team- or provide the ability to transfer the verified bot out of the team which seems like the more time consuming option.

Just my 2 cents

[AlmostSuspense]

use the bot verification one

[just-rich]

Thats a good idea, I'll try that. I just reported it as a bug and got a response an hour ago so if they aren't able to help resolve my issue I'll report it through bot verification.

[AlmostSuspense]

none of that is a bug though

[just-rich]

Seeing as how a server admin can claim ownership after 30 days, one can assume the same goes for developer team ownership

[AlmostSuspense]

it's supposed to be the case already but even if it wasnt, it wouldnt be a bug

[Mysterious-Dev]

This can be checked now, right?

https://discord.com/developers/docs/change-log#new-select-menu-components

[draxya]

We need user and channel options on modals.

[eliyya]

Why?

[draxya]

Because modals could be used for dashboard purposes for bots and there would be no need to website dashboards for many situations. And also a moderator can pick an action for a channel, user and add a description on paragraph / short text input. Just like slash command but you know only way to show a modal is not a slash command, it could be shown with a button interaction and there is no such option on buttons. I think it would be a better experience if we could see such thing!

[ooliver1]

Just in a generic term, selects in modals.

[lukasthaler]

Is there an ETA on that date picker option type? That would be really helpful to bots used across the globe and would be much better than having to force all users to convert date inputs to a time zone themselves and then read that in from a string

[DonManfred]

Discord does not give any ETA

[iced-queen]

The roadmap is outdated 😄

[ManHatos]

Very much

[vitorpsogarcia]

Hi, would be nice have the content of #5883 in discord api too!

In booth languages, js and python.

[typpo]

Hi everyone,

Closing this discussion as this roadmap is years old and outdated. I'm happy that we shipped most of the things on this list! For feature requests and suggestions, please create a new discussion here: https://github.com/discord/discord-api-docs/discussions/ and upvote other posts that you agree with.