Vēl nav uzbūvēts

Uzzināt, mēģinot, ir sliktāk, nekā tikt brīdinātam. Nekā no tā šodien nav:

• —Piegāde tiek mēģināta līdz piecām reizēm: uzreiz, tad pēc 1 minūtes, 5, 25 un 2 stundām. Katrs mēģinājums tiek reģistrēts un lasāms ar GET /webhooks/{id}/deliveries, katrs ar savu attempt un maxAttempts. Atkārtošana apstājas agrāk, kad atbilde liecina, ka tās atkārtošana ir bezjēdzīga: viss, kas nav 408, 425, 429 vai 5xx, tiek uztverts kā apzināts noraidījums. Atkārtotas nosūtīšanas galapunkta joprojām nav, tāpēc galapunktam, kas nedarbojas ilgāk par šo logu, veidojas robs, un piegāžu žurnāls ir vieta, kur to atrast.
• —Ziņojums, kas atlēca, caur GET /emails joprojām lasās kā sent: piegādes ziņojums tiek sasaistīts ar oriģinālu un atzīmēts uz pavediena, bet sūtījuma rindā nekas netiek ierakstīts atpakaļ, un tās statusam nav atlēkuša stāvokļa. Apturēšana, ko tas baro, ir reāla: pastāvīga atlēkšana vai sūdzība ieliek adresi šīs darbvietas apturēto sarakstā, un nākamais sūtījums uz to tiek atteikts. Tieši sūtījuma ieraksts neko neuzzina.
• —Vispārīga pieprasījumu ātruma ierobežotāja nav. Divi skaitīti griesti gan pastāv, un abi atbild ar 429: darbvieta, kas iztērē sava plāna mēneša sūtīšanas limitu, katram nākamajam sūtījumam saņem send_quota_exceeded līdz mēneša pirmajam datumam, un vienreizlietojamo iesūtņu izveide katram klientam ir ierobežota ar sešām stundā un trīsdesmit dienā ar too_many_inboxes. Neviens no tiem nenes Retry-After. Parasto lasīšanas un rakstīšanas pieprasījumu ātruma ierobežotājs ir trūkums, nevis solījums, un tas tiks izlabots.
• —API nav pielikumu AUGŠUPIELĀDES galapunkta. Iegultie pielikumi ir base64 un ierobežoti ar 5 MB uz visu ziņojumu. Lielāks fails tiek sūtīts kā { fileId }, nosaucot failu, kas jau ir darbvietā, un ceļo kā lejupielādes saite. Pielikumu lasīšana no saņemtā pasta gan darbojas.