SDK
Wersje robocze
`drafts.list`, `listAll`, `iterate`, `get`, `create`, `update` i `delete`.
Wszystkie metody
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 zachowuje identyfikator wersji roboczej, więc zwracana wartość jest zawsze tą, którą przekazałeś. Nieznany identyfikator daje 404, a nie nową wersję roboczą.
list stronicuje tak jak threads.list: pageToken z API wraca jako nextCursor i wchodzi jako cursor, a listAll i iterate podążają za nim za Ciebie.
Żeby wysłać wersję roboczą, przekaż jej identyfikator do emails.send. Wersja robocza dostarcza treść, a wysyłka dostarcza kopertę.
await openemail.emails.send({ from: '[email protected]', to: '[email protected]', draftId: 'draft_…',})Parametry: drafts.create i drafts.update (DraftInput)
tostring[]- Adresy odbiorców jako zwykłe ciągi znaków, a nie formy `RecipientInput`, które przyjmuje `emails.send`, bo ten endpoint skleja tablicę w listę rozdzieloną przecinkami, jakiej oczekuje sterownik. Przy tworzeniu pominięta tablica zapisuje się jako pusta; przy aktualizacji pominięte pole zostawia zapisanych odbiorców w spokoju, bo handler najpierw czyta wersję roboczą i scala.
ccstring[]- Adresy Cc, w tej samej postaci zwykłych ciągów co `to`. Puste przy tworzeniu, gdy pominięte, i nietknięte przy aktualizacji, gdy pominięte.
bccstring[]- Adresy Bcc, w tej samej postaci zwykłych ciągów co `to`. Puste przy tworzeniu, gdy pominięte, i nietknięte przy aktualizacji, gdy pominięte.
subjectstring- Temat wersji roboczej, najwyżej 998 znaków, czyli limit linii z RFC 5322. Przy tworzeniu domyślnie pusty ciąg, więc wersja robocza zawsze jakiś ma.
htmlstring- Treść wersji roboczej jako znaczniki, najwyżej 1 000 000 znaków. To ta treść wygrywa: `html` i `text` zasilają jedno pole wiadomości sterownika, więc wysłanie obu zapisuje tę.
textstring- Treść czystym tekstem, najwyżej 1 000 000 znaków, używana tylko wtedy, gdy nie ma `html`. Wersja robocza przechowuje jedną treść, a nie dwie części, więc podany tu tekst wraca w `html` przy odczycie wersji roboczej.
fromstring- Adres nadawcy do zapisania na wersji roboczej. Przy aktualizacji jest przenoszony z zapisanej wersji roboczej, gdy go pominiesz. Sterownik odbudowuje całą wiadomość z tego, co dostanie, więc częściowa modyfikacja, która by go pominęła, po cichu zmieniłaby wybranego nadawcę.
threadIdstring- Dołącz wersję roboczą do istniejącego wątku, żeby zapisała się jako odpowiedź. Tak jak `from`, przy aktualizacji jest przenoszone, gdy pominięte, bo odbudowanie wiadomości bez niego oderwałoby odpowiedź od jej wątku.
Odpowiedź: DraftResource (drafts.get)
object'draft'- Zawsze `draft`.
idstring- Identyfikator wersji roboczej. Zapisy odpowiadają `SavedDraftResource`, a nie całą wersją roboczą, więc odczytaj identyfikator z wyniku, zamiast używać ponownie tego, który wysłałeś.
tostring[]- Adresy odbiorców w postaci, w jakiej zapisała je wersja robocza. Pusta tablica, nigdy null, gdy nie ma żadnych.
ccstring[]- Adresy Cc w postaci zapisanej. Pusta tablica, nigdy null, gdy nie ma żadnych.
bccstring[]- Adresy Bcc w postaci zapisanej. Pusta tablica, nigdy null, gdy nie ma żadnych.
subjectstring- Zapisany temat albo pusty ciąg, gdy wersja robocza go nie ma. To pole nigdy nie jest null, więc sprawdzaj jego długość, a nie obecność.
htmlstring- Zapisana treść albo pusty ciąg, gdy wersja robocza jej nie ma. Na wyjściu nie ma osobnego pola tekstowego: wersja robocza zapisana z samym `text` jest zwracana tutaj.