Jeszcze nie zbudowane

Dowiadywanie się przez próbowanie jest gorsze niż powiedzenie wprost. Nic z tego dziś nie istnieje:

• —Dostarczenie jest próbowane do pięciu razy: od razu, a potem po 1 minucie, 5, 25 i 2 godzinach. Każda próba jest zapisywana i czytelna przez GET /webhooks/{id}/deliveries, wraz z attempt i maxAttempts. Ponawianie kończy się wcześniej, gdy odpowiedź mówi, że powtarzanie nie ma sensu: cokolwiek innego niż 408, 425, 429 albo 5xx jest traktowane jako świadome odrzucenie. Nadal nie ma endpointu do ponownego odtworzenia, więc endpoint niedostępny dłużej niż to okno ma lukę, a dziennik dostarczeń jest miejscem, w którym ją znajdziesz.
• —Odbita wiadomość nadal czyta się jako sent przez GET /emails: raport o dostarczeniu jest dopasowywany do oryginału i oznaczany na wątku, ale nic nie zapisuje się z powrotem do wiersza wysyłki, którego status nie ma stanu odbicia. Wynikające z tego wykluczenie jest prawdziwe: twarde odbicie albo skarga umieszcza adres na liście wykluczeń tej przestrzeni roboczej, a kolejna wysyłka do niego zostaje odrzucona. To rekord wysyłki się nie uczy.
• —Brak ogólnego ogranicznika tempa żądań. Istnieją dwa liczone pułapy i oba odpowiadają 429: przestrzeń robocza, która wyda miesięczny limit wysyłek zawarty w jej planie, dostaje send_quota_exceeded przy każdej kolejnej wysyłce aż do pierwszego dnia miesiąca, a tworzenie jednorazowych skrzynek jest ograniczone do sześciu na godzinę i trzydziestu dziennie na klienta, z too_many_inboxes. Żaden z nich nie niesie Retry-After. Ogranicznik tempa zwykłych odczytów i zapisów jest brakiem, a nie obietnicą — i brakiem, który zostanie naprawiony.
• —Brak endpointu do PRZESYŁANIA załączników w API. Załączniki inline są w base64 i ograniczone do 5 MB w obrębie wiadomości. Większy plik wysyła się jako { fileId }, wskazując plik już obecny w przestrzeni roboczej, i podróżuje jako odnośnik do pobrania. Odczyt załączników z odebranej poczty działa.