Send interaction commandName & options in message object #7369
-
The ProblemWith the current state of the Okay, but what is the problem?Many bots (most noticeably ticket bots) require the Example Use Case:![]() Proposed SolutionInclude the name of the slash command and its options in the interaction metadata. This will allow many new possibilities for ticket bots and the way they store transcripts. It would also be better for moderation bots as they can inspect the contents of interaction options. And last but not least, the bot itself also has a great advantage because it can find back messages where interactions of itself were used and could edit them, etc. If anyone has any more suggestions or use cases, please suggest them in the replies below. Proposed Interaction Metadata Object:{
"id":"<interaction-id>",
//...existing properties
"application_command_metadata":{
"id":"<command-id>",
"applicationId":"<command-command-id>",
"name":"<command-name>",
"type":1,
"options":[
{
"type":3,
"name":"<option-name>",
"value":"<option-value>",
"required":true
},
{
"type":1,
"name":"<option-name>",
"value":null,
"required":true,
"options":[
{
"type":3,
"name":"<option-name>",
"value":"<option-value>",
"required":true
}
]
}
]
}
} |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
the command name is already included in the interaction_metadata field but it is intentionally not documented because it merges subcommand names together in a way that Discord does not want bots relying on. options are not included in the message data because that would be too much data and would bloat the message payload. |
Beta Was this translation helpful? Give feedback.
the command name is already included in the interaction_metadata field but it is intentionally not documented because it merges subcommand names together in a way that Discord does not want bots relying on.
options are not included in the message data because that would be too much data and would bloat the message payload.