:::endpoint GET /v1/me/mail/attachments/{id}

The file itself, streamed back on your token. Ids come from `attachments` on an
[opened conversation](/docs/api/mail/message).

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

```bash
curl https://api.proppertrading.com/v1/me/mail/attachments/110 \
  -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
```

:::warning 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](/docs/api/mail/message).

## 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 |