Document multi file upload #3860
Conversation
|
This behavior may be subject to change, so going to hold off merging for now |
typpo
added
the
not released
| @@ -311,6 +311,7 @@ We highly recommend checking out our [Community Resources](#DOCS_TOPICS_COMMUNIT | |||
| ## Create Interaction Response % POST /interactions/{interaction.id#DOCS_INTERACTION_RECEIVING_AND_RESPONDING/interaction}/{interaction.token#DOCS_INTERACTION_RECEIVING_AND_RESPONDING/interaction-object}/callback | |||
|
|
|||
| Create a response to an Interaction from the gateway. Takes an [interaction response](#DOCS_INTERACTION_RECEIVING_AND_RESPONDING/interaction-response-object). | |||
| This endpoint also supports file attachments similar to the webhook endpoints. Refer to [Uploading Files](#DOCS_RESOURCES_CHANNEL/create-message-uploading-files) for details on uploading files and `multipart/form-data` requests. | |||
There was a problem hiding this comment.
Is this a case of you can include file attachments with the initial response for interactions received over the gateway but not for interactions received over REST or does this pr just not document it for rest responses?
There was a problem hiding this comment.
Since the file uploads haven't been documented for that response at all, I excluded it intentionally. Theoretically, it would work identically but with a multipart body response.
| > This endpoint supports both `application/json` and `multipart/form-data` bodies. When uploading files the `multipart/form-data` content type must be used. | ||
| > Note that in multipart form data, the `embeds` and `allowed_mentions` fields cannot be used. You can pass a stringified JSON body as a form value as `payload_json` instead. | ||
| > **If you supply a `payload_json` form value, all fields except for `file` fields will be ignored in the form data**. | ||
| > Note that when sending a message, you must provide a value for at **least one of** `content`, `embeds`, or `file`. |
There was a problem hiding this comment.
What do you think of saying "attachments" (no code backticks) instead of file? cc @msciotti
Feels like since it isn't the parameter name, we should style it differently
There was a problem hiding this comment.
Isn't it? Looking at the param table below, there is an attachments parameter
| > Note that in multipart form data, the `embeds`, `allowed_mentions`, and `attachments` fields cannot be used. You can pass a stringified JSON body as a form value as `payload_json` instead. | ||
| > **If you supply a `payload_json` form value, all fields except for `file` fields will be ignored in the form data**. | ||
| Refer to [Uploading Files](#DOCS_REFERENCE/uploading-files) for details on attachments and `multipart/form-data` requests. | ||
| Any provided files will be **appended** to the message. To remove or replace files you will have to supply the `attachments` field which specifies the files to retain on the message after edit. |
There was a problem hiding this comment.
I'm not sure what the API version callout style guide is, but do we want to include a note that in v10 users will need to patch with the complete attachment array?
There was a problem hiding this comment.
implying that there is a style guide :^)
I think get active channel threads has a deprecation notice tho
There was a problem hiding this comment.
I think a warn block would do when functionality is expected to change in the next version
|
Looks good to me, pinged Mason about possibly taking a pass |
IanMitchell
removed
the
not released
This brings support for multiple attachments up to date with discord/discord-api-docs#3860 with the exception of support for setting description initially as there is not support for it yet.
This brings support for multiple attachments up to date with discord/discord-api-docs#3860 with the exception of support for setting description initially as there is not support for it yet.
Since @IanMitchell showed us multi attachment support will be added to the client, I see no reason to keep this undocumented any longer.
I'm not sure if documenting the uploading mechanism only under
Create Messagemakes sense, maybe a dedicated section outside of endpoint docs would be better. I do think it makes sense to just link to the specific section rather than duplicating it 3 times.