It seems like attachment data received from the API doesn't always follow the same format as sent from the client..
The official docs only show "image", "location", "split", and "emoji", and the get/post examples show them to be identical, i.e. all Attachment objects are assembled by a client, sent to the server in a Message, and the server simply spits out the same Attachment object verbatim without additional processing, (as if it's part of the message itself).
However, I think there are some additional attachment types found only in responses, which would be worth noting if you are consuming the API rather than sending to it.
I propose some kind of classification on the Attachments page to distinguish "verbatim" attachment types (image, emoji, etc.) from "special" ones (event, linked_image, etc.)
It seems like attachment data received from the API doesn't always follow the same format as sent from the client..
The official docs only show "image", "location", "split", and "emoji", and the get/post examples show them to be identical, i.e. all Attachment objects are assembled by a client, sent to the server in a Message, and the server simply spits out the same Attachment object verbatim without additional processing, (as if it's part of the message itself).
However, I think there are some additional attachment types found only in responses, which would be worth noting if you are consuming the API rather than sending to it.
I propose some kind of classification on the Attachments page to distinguish "verbatim" attachment types (
image,emoji, etc.) from "special" ones (event,linked_image, etc.)