SDK
Terminieren und abbrechen
`scheduledAt`, `emails.reschedule` und `emails.cancel`.
Später senden
await openemail.emails.send({ ...message, scheduledAt: 'PT1H' })await openemail.emails.send({ ...message, scheduledAt: new Date('2027-01-01T09:00:00Z') })await openemail.emails.send({ ...message, scheduledAt: '2027-01-01T09:00:00.000Z' })Ein Date, ein ISO-8601-Zeitpunkt oder eine Dauer wie PT1H / P2D. Bis zu ein Jahr voraus, nie in der Vergangenheit.
Verschieben und stoppen
const queued = await openemail.emails.send({ ...message, scheduledAt: 'PT1H' }) await openemail.emails.reschedule(queued.id, new Date(Date.now() + 86_400_000))await openemail.emails.cancel(queued.id)Nur Nachrichten mit queued und scheduled lassen sich stoppen; alles Weitergehende ergibt einen conflict_error, denn ein Teil davon liegt bereits in jemandes Postfach. Das Abbrechen einer bereits abgebrochenen Nachricht gelingt und ändert nichts.
Stattdessen ein Rückgängig-Fenster
await openemail.emails.send({ ...message, cancellableForSeconds: 30 })Eine geplante Nachricht ist bis zum Versand ohnehin abbrechbar, beides lässt sich daher nicht kombinieren, und der Server lehnt es ab. Verwenden Sie dies für ein Rückgängig-Fenster bei einer sofortigen Nachricht.
Parameter: Terminierung
scheduledAtDate | string- Wann gesendet wird, bei `emails.send`: ein `Date`, ein ISO-8601-Zeitpunkt oder eine Dauer wie `PT1H` oder `P2D`, die der Client für die Leitung zu einem String rendert. Mindestens eine Sekunde in der Zukunft und höchstens 365 Tage voraus, jede verletzte Grenze ergibt einen `validation_error` auf `scheduledAt`, und natürliche Sprache wird nicht akzeptiert, denn "nächsten Dienstag" falsch zu deuten sendet eine Nachricht zu einer Zeit, die sich nicht zurückholen lässt.
cancellableForSecondsnumber- Ein Rückgängig-Fenster bei einem SOFORTIGEN Versand: ein integer von 0 bis 900, Standard 0. Jeder Wert über 0 wird zusammen mit `scheduledAt` abgelehnt, das bis zum Versand ohnehin abbrechbar ist, und eine so zurückgehaltene Nachricht steht auf `queued` statt auf `scheduled`. Es ist derselbe Aufschubmechanismus mit kurzer Verzögerung.
idstringerforderlich- Die `msg_…`-id und das erste Argument sowohl von `emails.cancel` als auch von `emails.reschedule`. Beide benötigen `emails:send` statt eines eigenen Scopes, und beide lösen innerhalb des eigenen Workspace des Schlüssels auf, eine id aus einem anderen ergibt daher genau wie eine nie existierende id einen `not_found_error`.
reschedule.scheduledAtDate | stringerforderlich- Die neue Zeit, als zweites Argument von `emails.reschedule`, nach denselben Regeln und gegen dasselbe Ein-Jahres-Fenster geparst, und das Einzige, was das zugrunde liegende `PATCH /emails/{id}` ändert. Eine Dauer ist relativ zu dem Zeitpunkt, zu dem der SERVER sie liest, eine wiederholte Neuterminierung landet daher etwas später als die erste: später, nie früher.
Antwort: EmailResource
object'email'- Immer `email`. Beide Aufrufe antworten mit der gesamten Nachricht statt mit einer Bestätigung, es muss also nichts erneut geholt werden, um zu sehen, was sich geändert hat; `emails.send` gibt dieselbe Form plus `replayed` zurück.
idstring- Das `msg_…`-Handle. Stabil über die Lebensdauer der Nachricht und die id, die jeder andere Aufruf darauf entgegennimmt.
statusEmailStatus- `cancelled` nach einem Abbruch und `scheduled` nach einer Neuterminierung, auch bei einer Nachricht, die nur hinter einem Rückgängig-Fenster `queued` war und die eine Neuterminierung in eine echte Terminierung verwandelt. Nur Nachrichten mit `queued` und `scheduled` lassen sich verschieben oder stoppen; alles Weitergehende ergibt einen `conflict_error` mit dem Code `email_not_cancellable`, denn ein Teil davon liegt bereits in jemandes Postfach.
scheduledAtstring | null- Der ISO-Zeitpunkt, zu dem die Nachricht versendet werden soll. Gesetzt sowohl bei einem Rückgängig-Fenster als auch bei einem Versand mit `scheduledAt`, da beides ein Mechanismus ist, und null bei einem einfachen sofortigen Versand.
cancellableUntilstring | null- Wann das Abbrechen nicht mehr funktioniert, derselbe Zeitpunkt wie `scheduledAt` auf beiden aufgeschobenen Wegen. Null bei einem sofortigen Versand, der bereits hinaus ist, wenn der Aufruf zurückkehrt.
sentAtstring | null- Wann die Nachricht tatsächlich hinausging. Null, solange sie wartet, und für immer null bei einer abgebrochenen.
messageIdstring | null- Die Message-ID nach RFC 5322, null, bis das MIME existiert, also immer null bei einer Nachricht, auf die diese beiden Aufrufe wirken können. Nichts, womit man die API anspricht, und auch nicht das, worüber ein späterer Bounce zurückkommt: Der Versanddienst schreibt den Header auf dem Weg hinaus um.
threadIdstring | null- Der Thread, zu dem diese Nachricht gehört, aus der Anfrage übernommen und mit dem überschrieben, was der Transport beim Senden meldet. Null, wenn es keine Antwort ist.
transportEmailTransport | (string & {}) | null- Wie die Bytes hinausgingen, und null bis zum Versand, also null bei jeder Nachricht, die ein Abbruch oder eine Neuterminierung zurückgeben kann. Ein Versand im Testmodus erfasst `test`, und die Union bleibt offen, damit ein Transport, den dieses SDK noch nicht benennt, keine Breaking Change ist.
attemptsnumber- Wie oft der Versand diese Zeile beansprucht hat. Der Wert wird durch das Beanspruchen erhöht, nicht durch einen erfolgreichen Versand, und ist 0 für alles, was noch wartet.
lastErrorstring | null- Der letzte zur Nachricht erfasste Fehler, null, solange nichts fehlgeschlagen ist. Ein aufgeschobener Versand, dessen Job nicht eingereiht werden konnte, wird hier als `Could not schedule: …` geschrieben und auf `failed` gesetzt, was der einzige Weg ist, auf dem eine geplante Nachricht ohne Zutun aufhört, abbrechbar zu sein.
fromstring- Die Adresse, unter der die Nachricht hinausgehen durfte, blank und in Kleinbuchstaben gespeichert. Nicht immer die angeforderte Adresse (ein eingeschränkter Schlüssel ohne `from` löst auf die erste Adresse auf, die er verwenden darf), und jeder Anzeigename entfällt hier, weil der `from`-Filter von `emails.list` auf Gleichheit vergleicht.