SDK
پیشنویسها
`drafts.list`، `listAll`، `iterate`، `get`، `create`، `update` و `delete`.
همهٔ متدها
const page = await openemail.drafts.list({ query: 'invoice', limit: 25 })const draft = await openemail.drafts.get('draft_…') const created = await openemail.drafts.create({ to: ['[email protected]'], cc: [], bcc: [], subject: 'Your September invoice', html: '<p>Draft body.</p>', from: '[email protected]', threadId: 'thread_…',}) const updated = await openemail.drafts.update(created.id!, { subject: 'Revised' })await openemail.drafts.delete(updated.id!)update شناسهٔ پیشنویس را نگه میدارد، پس مقداری که با آن پاسخ میدهد همیشه همانی است که فرستادهاید. شناسهٔ ناشناخته بهجای پیشنویسی تازه، یک 404 است.
list به همان شیوهٔ threads.list صفحهبندی میکند: pageToken مربوط به API به شکل nextCursor برمیگردد و به شکل cursor فرستاده میشود، و listAll و iterate آن را بهجای شما دنبال میکنند.
برای ارسال یک پیشنویس، شناسهاش را به emails.send بدهید. پیشنویس محتوا را تأمین میکند و ارسال، پاکت را.
await openemail.emails.send({ from: '[email protected]', to: '[email protected]', draftId: 'draft_…',})پارامترها: drafts.create و drafts.update (DraftInput)
tostring[]- نشانی گیرندگان به شکل رشتهٔ ساده، نه شکلهای `RecipientInput` که `emails.send` میپذیرد، چون این endpoint آرایه را به فهرستِ جداشده با کاما که درایور میخواهد میچسباند. هنگام create، آرایهٔ نیامده خالی ذخیره میشود؛ هنگام update، فیلدِ نیامده گیرندگان ذخیرهشده را دستنخورده میگذارد، چون هندلر اول پیشنویس را میخواند و ادغام میکند.
ccstring[]- نشانیهای Cc، به همان شکل رشتهٔ سادهٔ `to`. هنگام create اگر نیاید خالی است، و هنگام update اگر نیاید دستنخورده میماند.
bccstring[]- نشانیهای Bcc، به همان شکل رشتهٔ سادهٔ `to`. هنگام create اگر نیاید خالی است، و هنگام update اگر نیاید دستنخورده میماند.
subjectstring- موضوع پیشنویس، حداکثر 998 نویسه، همان حد طول خط RFC 5322. هنگام create پیشفرض آن رشتهٔ خالی است، پس هر پیشنویس همیشه یکی دارد.
htmlstring- بدنهٔ پیشنویس به شکل نشانهگذاری، حداکثر 1,000,000 نویسه. همین بدنه است که برنده میشود: `html` و `text` هر دو به تنها فیلد پیام در درایور میریزند، پس اگر هر دو را بفرستید همین یکی ذخیره میشود.
textstring- بدنهٔ متن ساده، حداکثر 1,000,000 نویسه، که فقط وقتی `html` نباشد به کار میرود. پیشنویس یک بدنه ذخیره میکند نه دو بخش، پس متنی که اینجا داده شود هنگام خواندن پیشنویس روی `html` برمیگردد.
fromstring- نشانی فرستنده که روی پیشنویس ذخیره میشود. هنگام update اگر نیاید، از پیشنویس ذخیرهشده منتقل میشود. درایور کل پیام را از آنچه به او داده میشود بازمیسازد، پس وصلهای ناقص که این را انداخته باشد بیسروصدا فرستندهٔ انتخابشده را عوض میکرد.
threadIdstring- پیشنویس را به یک thread موجود بچسبانید تا بهصورت پاسخ ذخیره شود. مانند `from`، هنگام update اگر نیاید منتقل میشود، چون بازسازی پیام بدون آن، پاسخ را از thread خودش جدا میکرد.
پاسخ: DraftResource (drafts.get)
object'draft'- همیشه `draft`.
idstring- شناسهٔ پیشنویس. نوشتنها بهجای یک پیشنویس کامل با یک `SavedDraftResource` پاسخ میدهند، پس شناسه را از روی نتیجه بخوانید، نه اینکه همانی را که فرستادهاید دوباره به کار ببرید.
tostring[]- نشانی گیرندگان، همانطور که پیشنویس ذخیرهشان کرده است. وقتی پیشنویس هیچکدام را ندارد آرایهای خالی است، هرگز null.
ccstring[]- نشانیهای Cc همانطور که ذخیره شدهاند. وقتی پیشنویس هیچکدام را ندارد آرایهای خالی است، هرگز null.
bccstring[]- نشانیهای Bcc همانطور که ذخیره شدهاند. وقتی پیشنویس هیچکدام را ندارد آرایهای خالی است، هرگز null.
subjectstring- موضوع ذخیرهشده، یا رشتهٔ خالی در جایی که پیشنویس موضوعی ندارد. این فیلد هرگز null نیست، پس بهجای وجودش طولش را بررسی کنید.
htmlstring- بدنهٔ ذخیرهشده، یا رشتهٔ خالی در جایی که پیشنویس بدنهای ندارد. در مسیر خروج فیلد جداگانهای برای متن وجود ندارد: پیشنویسی که فقط با `text` ذخیره شده باشد همینجا برگردانده میشود.