Przejdź do dokumentacji
SDK

Planowanie i anulowanie

`scheduledAt`, `emails.reschedule` i `emails.cancel`.

Wysyłka później

schedule.ts
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' })

Date, instant ISO-8601 albo czas trwania w rodzaju PT1H / P2D. Do roku naprzód, nigdy w przeszłość.

Przenoszenie i zatrzymywanie

reschedule.ts
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)

Zatrzymać można tylko wiadomości queued i scheduled; cokolwiek dalej to conflict_error, bo część z tego jest już w czyjejś skrzynce. Anulowanie już anulowanej wiadomości kończy się sukcesem i nic nie zmienia.

Zamiast tego okno cofnięcia

undo-window.ts
await openemail.emails.send({ ...message, cancellableForSeconds: 30 })

Zaplanowaną wiadomość i tak można anulować do chwili wyjścia, więc tych dwóch nie da się połączyć i serwer to odrzuca. Tego używaj do okna cofnięcia wysyłki przy wiadomości natychmiastowej.

Parametry: planowanie

scheduledAtDate | string
Kiedy wysłać, w `emails.send`: `Date`, instant ISO-8601 albo czas trwania w rodzaju `PT1H` czy `P2D`, który klient renderuje do ciągu na łącze. Co najmniej sekundę w przyszłości i najwyżej 365 dni naprzód, przy czym każda z granic daje `validation_error` na `scheduledAt`; język naturalny nie jest przyjmowany, bo błędne sparsowanie „w następny wtorek” wysyła wiadomość w chwili, której nie da się cofnąć.
cancellableForSecondsnumber
Okno cofnięcia wysyłki przy wysyłce NATYCHMIASTOWEJ: liczba całkowita od 0 do 900, domyślnie 0. Każda wartość powyżej 0 jest odrzucana obok `scheduledAt`, które i tak można anulować do chwili wyjścia, a wiadomość wstrzymana w ten sposób siedzi w `queued`, a nie w `scheduled`. To ten sam mechanizm odroczenia z krótkim opóźnieniem.
idstringwymagane
Identyfikator `msg_…`, czyli pierwszy argument zarówno `emails.cancel`, jak i `emails.reschedule`. Oba potrzebują `emails:send`, a nie własnego zakresu, i oba rozwiązują się w obrębie przestrzeni roboczej klucza, więc identyfikator należący do innej to `not_found_error`, dokładnie jak identyfikator, który nigdy nie istniał.
reschedule.scheduledAtDate | stringwymagane
Nowy czas, jako drugi argument `emails.reschedule`, parsowany tymi samymi regułami i w tym samym rocznym oknie, i jedyna rzecz, jaką zmieni leżące pod spodem `PATCH /emails/{id}`. Czas trwania jest liczony względem chwili, w której SERWER go czyta, więc ponowione przełożenie ląduje nieco później, niż zrobiłoby to pierwsze: później, nigdy wcześniej.

Odpowiedź: EmailResource

object'email'
Zawsze `email`. Oba wywołania odpowiadają całą wiadomością, a nie potwierdzeniem, więc nic nie trzeba pobierać ponownie, żeby zobaczyć, co się zmieniło; `emails.send` zwraca tę samą postać plus `replayed`.
idstring
Uchwyt `msg_…`. Stabilny przez całe życie wiadomości i przyjmowany przez każde inne wywołanie na niej.
statusEmailStatus
`cancelled` po anulowaniu i `scheduled` po przełożeniu, także dla wiadomości, która była jedynie `queued` za oknem cofnięcia, a którą przełożenie zamienia w prawdziwy plan. Przenosić i zatrzymywać można tylko wiadomości `queued` i `scheduled`; cokolwiek dalej to `conflict_error` z kodem `email_not_cancellable`, bo część z tego jest już w czyjejś skrzynce.
scheduledAtstring | null
Instant ISO, w którym wiadomość ma zostać wysłana. Ustawiany zarówno dla okna cofnięcia, jak i dla wysyłki z `scheduledAt`, bo to jeden mechanizm, i null przy zwykłej wysyłce natychmiastowej.
cancellableUntilstring | null
Kiedy anulowanie przestaje działać, czyli w tym samym instancie co `scheduledAt` na obu odroczonych ścieżkach. Null przy wysyłce natychmiastowej, która w chwili powrotu z wywołania już poszła.
sentAtstring | null
Kiedy wiadomość faktycznie wyszła. Null, dopóki czeka, i na zawsze null na anulowanej.
messageIdstring | null
Message-ID z RFC 5322, null, dopóki nie powstanie MIME, więc zawsze null na wiadomości, na którą te dwa wywołania mogą działać. Nie służy do adresowania API i nie jest też tym, na czym wraca późniejszy bounce: usługa wysyłkowa przepisuje ten nagłówek na wyjściu.
threadIdstring | null
Wątek, do którego należy ta wiadomość, wzięty z żądania i przepisany tym, co zgłosi transport po wysłaniu. Null, gdy to nie jest odpowiedź.
transportEmailTransport | (string & {}) | null
Jak wyszły bajty, null do czasu wysłania, więc null na każdej wiadomości, którą może zwrócić anulowanie albo przełożenie. Wysyłka w trybie testowym zapisuje `test`, a unia pozostaje otwarta, żeby transport, którego ten SDK jeszcze nie nazywa, nie był zmianą łamiącą.
attemptsnumber
Ile razy wysyłanie zgłosiło roszczenie do tego wiersza. Zwiększane przez samo zgłoszenie, a nie przez udaną wysyłkę, i równe 0 dla wszystkiego, co wciąż czeka.
lastErrorstring | null
Ostatnia porażka zapisana przy wiadomości, null, dopóki nic się nie wywróciło. Odroczona wysyłka, której zadania nie udało się zakolejkować, jest zapisywana tutaj jako `Could not schedule: …` i przenoszona do `failed`, co jest jedynym sposobem, w jaki zaplanowana wiadomość przestaje być anulowalna bez niczyjej prośby.
fromstring
Adres, pod którym wiadomość była autoryzowana do wyjścia, zapisany samodzielnie i małymi literami. Nie zawsze ten, o który proszono (zawężony klucz, który nie nazywa żadnego `from`, rozwiązuje się do pierwszego adresu, którego może użyć), a nazwa wyświetlana jest tutaj pomijana, bo filtr `from` w `emails.list` porównuje przez równość.