/v1/me/mail/attachments/{id}The file itself, streamed back on your token. The path takes the id of a file
in attachments on an opened conversation, such as
att_w5k9n3q7h2t8x4mr.
Not JSON: the body is the file. Everything else on this API answers with an envelope, but a download that arrived base64 inside one would cost a third more bandwidth and a full copy in memory on a phone.
Request
curl https://api.proppertrading.com/v1/me/mail/attachments/att_w5k9n3q7h2t8x4mr \
-H "Authorization: Bearer ptat_9f2c1a44_3b8e7d2f5c9a1b4e6d8f0a2c4e6b8d1f" \
-o invoice.pdf
Response
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 84213
Content-Disposition: attachment; filename="invoice.pdf"; filename*=UTF-8''invoice.pdf
X-Content-Type-Options: nosniff
The type is always octet-stream
Deliberately, whatever the sender called the file. This arrived from a stranger, and the type they chose is the least trustworthy thing about it. Decide what to do with the bytes on your side, and hand the file to the operating system rather than rendering it yourself.
Inline images are not fetched here. They are already in the message body as signed relative links; see Open a conversation.
Errors
| Status | Code | Meaning |
|---|---|---|
| 403 | insufficient_scope | This device does not hold mail:read |
| 403 | mailbox_not_permitted | The account may not open a mailbox at all |
| 404 | resource_not_found | No such attachment, or it belongs to a mailbox you cannot read. Also answered when the bytes are no longer stored, and for a number in the path |