List attachments
The parts on one message, with their bytes, base64.
Runs the real call against your workspace, with your own key.
GET /temp-mail/inboxes/{id}/messages/{messageId}/attachments
The parts on one message, with their bytes, base64.
The inbox token
export OE=https://api.openemail.ukexport 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 "$OE/temp-mail/inboxes/tinb_9c2f41ab7d3e4c118a0f5d72/messages/tmail_4b81c07d2fa9418e93c6a13f/attachments" \ -H "$INBOX"{ "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.