Creating an interaction response should return the message data

[DenverCoder1]

When responding to an interaction with /callback, currently the API returns No Content (204).

This means if you want to later reference the sent message, such as to to add reactions, store the message ID etc. it will require an extra API call to /@original to get the message data.

In a Discord API wrapper, it would help to have the send method able to return a Message object (just like it works for channel messages and webhooks). Having the library make an extra API call for the user after sending the response is not a practical solution.

If the data is available, there should be no reason not to include it in the callback response.

If necessary, there could instead be a wait=True parameter similar to webhooks which would make it wait for a server confirmation in order to be able to return the data (but I assume waiting for confirmation is the default behavior of creating an interaction response, so as far as I can tell I don't think it will require that).

[lsdimagine]

What's your use case here?

[DenverCoder1]

What's your use case here?

@lsdimagine I believe I've already listed a few use cases in the original post but I can go into even further detail.

1. A scenario where you want to edit interaction messages at a later time when the message is referenced later (for example, detecting someone replied to an interaction response or mentioned it's message ID, and then updating the message)

   • In order to do this we need to store the message ID of the interaction when it is sent along with the interaction token so that when we see a message replied to we can look up the interaction token it references and use Edit Original Interaction Response or Delete Original Interaction Response with application permissions.
   • Getting the message ID currently can't be done without 2 API calls

2. A scenario where you want to add reactions to an interaction response (for example, a role reaction menu, pagination menu, or custom emojis used as status indicators)

   • The regular message endpoint needs to be used for this and that requires the message ID to be known

3. In a scenario you want to take the response and pin it, publish it, create a thread from it, wait for users to add reactions to it and count them, etc.

   • All of these actions require the message ID as well

4. Logging / storing interaction messages.

   • In order to know whether a message has been sent by the application's interaction or not, you would need the API to tell you the message ID of the interaction so you can store them in a collection.

5. For general convenience of use

   • This is the lowest of all reasons, since the use cases above should be enough of a reason on their own
   • API users expect endpoints to return messages because that's how it works for everything until now (channel messages, webhooks, etc)
   • Implementing it differently causes inconsistencies and confusion among users of third-party libs who expect to be able to get back their message when using a send() method. (API wrapper libs will not return the Message object since it requires an extra API call behind the user's back to do so).
   • Making it not require an extra API call would allow libs to return the Message and make all of the above use cases easier for the user to implement

[DenverCoder1]

Another important use case:

In API v10, existing attachments must be specified when editing a message with new attachments. Any attachments not specified will be removed and replaced with the specified list.

What this means is, you can no longer easily append files to a message without having a list of the existing attachments in the message.

Therefore, if the message attachments are not returned in the content of the Interaction response, appending files to an interaction message requires two additional API calls instead of just one.

[advaith1]

this has been added! Use ?with_response=true to get the response details back. #7106

https://discord.com/developers/docs/interactions/receiving-and-responding#create-interaction-response