Llistar els adjunts
Les parts d'un missatge, amb els seus bytes, en base64.
Executa la crida real contra el teu espai de treball, amb la teva pròpia clau.
GET /temp-mail/inboxes/{id}/messages/{messageId}/attachments
Les parts d'un missatge, amb els seus bytes, en base64.
El token de la safata
export OE=https://api.openemail.ukexport INBOX="Authorization: Bearer oe_inbox_kQ8v…"Totes les crides de sota porten el token que ha retornat POST /temp-mail/inboxes, a la mateixa capçalera Authorization: Bearer que fa servir una clau d'API. L'adreça en si no autoritza res, i aquesta separació és el sentit de la funcionalitat i no pas una formalitat: una adreça d'un sol ús es lliura a la part que estàs mantenint a distància en el mateix moment en què s'emet.
L'id del camí ha d'anomenar la mateixa safata que el token. El token tot sol ja n'identifica una, de manera que això és portar cinturó i tirants, però vol dir que qui confon dues safates rep un 404 en comptes de llegir en silenci el correu equivocat.
Exemple
Metadades i contingut en una sola resposta, en comptes d'un llistat més una obtenció per part. Una safata d'un sol ús conté un grapat de fitxers petits, i dos viatges d'anada i tornada per llegir un PDF és un mal intercanvi a aquesta mida.
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 és null quan la part superava el límit d'emmagatzematge de 8 MB. Això no és un fitxer buit, que és exactament per què les metadades se serveixen igualment, de manera que un client pot dir «massa gran per conservar-lo» en comptes de mostrar una baixada de 0 bytes.
Aquests bytes els proporciona un atacant i s'han acceptat d'un remitent anònim. El que els renderitzi ho ha de fer fora de l'origen de la teva aplicació.