Még nincs elkészítve

Próbálgatással rájönni rosszabb, mint ha megmondják. Ezek közül ma egyik sem létezik:

• —Egy kézbesítés legfeljebb ötször kerül megkísérlésre: azonnal, majd 1, 5, 25 perc és 2 óra múlva. Minden kísérlet rögzítésre kerül és olvasható a GET /webhooks/{id}/deliveries útvonalon, mindegyik saját attempt és maxAttempts értékkel. Az újrapróbálkozás korábban leáll, ha a válasz szerint az ismétlés értelmetlen: a 408, 425, 429 és 5xx kivételével minden szándékos elutasításnak számít. Visszajátszó végpont továbbra sincs, így egy ennél az ablaknál hosszabban elérhetetlen végpontnál hézag keletkezik, és ezt a kézbesítési naplóban találod meg.
• —Egy visszapattant üzenet a GET /emails szerint továbbra is sent: a kézbesítési jelentés az eredetihez párosul és címkeként megjelenik a szálon, de semmi nem ír vissza a küldési sorba, amelynek állapotai között nincs visszapattant. Az általa táplált letiltás valós: egy kemény visszapattanás vagy panasz a címet a munkaterület letiltási listájára teszi, és a következő, erre a címre irányuló küldés elutasításra kerül. A küldési rekord az, ami nem értesül róla.
• —Nincs általános kérésgyakoriság-korlátozó. Két számlált plafon létezik, és mindkettő 429-cel válaszol: az a munkaterület, amely elhasználja a csomagjában foglalt havi küldési keretet, minden további küldésre send_quota_exceeded választ kap a hónap elsejéig, az eldobható postafiókok létrehozása pedig kliensenként óránként hatra és naponta harmincra van korlátozva, too_many_inboxes kóddal. Egyik sem tartalmaz Retry-After fejlécet. A szokásos olvasások és írások gyakoriságának korlátozása hiány, nem ígéret, és pótolva lesz.
• —Az API-n nincs melléklet-FELTÖLTŐ végpont. A beágyazott mellékletek base64 kódolásúak, és az üzenet egészére 5 MB a korlát. A nagyobb fájl { fileId } formában küldhető, egy már a munkaterületen lévő fájlt megnevezve, és letöltési linkként utazik. A beérkezett levelek mellékleteinek olvasása működik.