---
title: "List attachments"
description: "The parts on one message, with their bytes, base64."
url: "https://openemail.uk/docs/api/temp-mail/attachments"
area: "API"
category: "Disposable inboxes"
---

# List attachments

The parts on one message, with their bytes, base64.

`GET /temp-mail/inboxes/{id}/messages/{messageId}/attachments`

## GET /temp-mail/inboxes/{id}/messages/{messageId}/attachments

The parts on one message, with their bytes, base64.

## The inbox token

**shell**

```
export OE=https://api.openemail.uk
export INBOX="Authorization: Bearer oe_inbox_kQ8v…"
```

Every call below carries the token `POST /temp-mail/inboxes` returned, in the same `Authorization: Bearer` header an API key uses. The address itself authorises nothing, and that separation is the point of the feature rather than a formality: a disposable address is handed to the party you are keeping at arm’s length the moment it is issued.

> The id in the path has to name the same inbox the token does. The token alone identifies one, so this is belt and braces, but it means a caller that muddles two inboxes gets a 404 instead of quietly reading the wrong mail.

## Example

Metadata and content in one answer rather than a listing plus a fetch per part. A throwaway inbox holds a handful of small files, and two round trips to read a PDF is the wrong trade at that size.

**curl**

```
curl "$OE/temp-mail/inboxes/tinb_9c2f41ab7d3e4c118a0f5d72/messages/tmail_4b81c07d2fa9418e93c6a13f/attachments" \
  -H "$INBOX"
```

**Response**

```
{
  "object": "list",
  "data": [
    {
      "object": "attachment",
      "attachmentId": "tmail_4b81c07d2fa9418e93c6a13f-0",
      "filename": "invoice.pdf",
      "contentType": "application/pdf",
      "size": 12345,
      "content": "JVBERi0xLjQKJc…"
    }
  ]
}
```

> `content` is null when the part was over the 8 MB storage ceiling. That is not an empty file, which is exactly why the metadata is served either way, so a client can say "too large to keep" instead of showing a 0-byte download.

> These bytes are attacker-supplied and were accepted from an anonymous sender. Whatever renders them must do it out of your app’s origin.