अटैचमेंट सूचीबद्ध करें
एक संदेश के भाग, उनके bytes के साथ, base64।
असली कॉल आपकी अपनी कुंजी से आपके वर्कस्पेस पर चलाता है।
GET /temp-mail/inboxes/{id}/messages/{messageId}/attachments
एक संदेश के भाग, उनके bytes के साथ, base64।
इनबॉक्स टोकन
export OE=https://api.openemail.ukexport INBOX="Authorization: Bearer oe_inbox_kQ8v…"नीचे की हर कॉल वही टोकन ले जाती है जो POST /temp-mail/inboxes ने लौटाया था, उसी Authorization: Bearer header में जिसे API कुंजी इस्तेमाल करती है। पता अपने आप में कुछ भी अधिकृत नहीं करता, और वह अलगाव औपचारिकता नहीं, इस फ़ीचर का मूल है: डिस्पोजेबल पता जारी होते ही उसी पक्ष को थमा दिया जाता है जिसे आप दूर रख रहे हैं।
path में दी गई id उसी इनबॉक्स का नाम लेनी चाहिए जिसका टोकन लेता है। अकेला टोकन ही एक इनबॉक्स की पहचान कर देता है, इसलिए यह दोहरी सावधानी है, पर इसका मतलब है कि दो इनबॉक्स गड्डमड्ड करने वाले कॉलर को चुपचाप गलत मेल पढ़ने के बजाय 404 मिलता है।
उदाहरण
एक ही जवाब में मेटाडेटा और content, न कि एक listing और फिर प्रति भाग एक fetch। फेंकने लायक इनबॉक्स मुट्ठी भर छोटी फ़ाइलें रखता है, और उस आकार पर PDF पढ़ने के लिए दो राउंड ट्रिप गलत सौदा है।
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 तब null होता है जब वह भाग 8 MB की भंडारण सीमा से ऊपर था। वह खाली फ़ाइल नहीं है, और ठीक इसीलिए मेटाडेटा दोनों हालतों में परोसा जाता है, ताकि क्लाइंट 0-byte डाउनलोड दिखाने के बजाय "रखने के लिए बहुत बड़ा" कह सके।
ये bytes हमलावर के दिए हुए हैं और एक अनाम भेजने वाले से स्वीकार किए गए थे। जो भी इन्हें रेंडर करे, वह आपके ऐप के origin से बाहर करे।