Zatím nepostaveno

Zjišťovat to pokusem je horší než se to dozvědět. Nic z tohoto dnes neexistuje:

• —Doručení se zkouší až pětkrát: hned, pak po 1 minutě, po 5, po 25 a po 2 hodinách. Každý pokus se zaznamenává a je čitelný přes GET /webhooks/{id}/deliveries, každý nese své attempt a maxAttempts. Opakování se zastaví dřív, když odpověď říká, že to nemá smysl: cokoli jiného než 408, 425, 429 nebo 5xx se bere jako záměrné odmítnutí. Endpoint pro přehrání pořád neexistuje, takže endpoint nedostupný déle, než je tohle okno, má mezeru – a log doručení je místo, kde ji najdete.
• —Odmítnutá zpráva se přes GET /emails pořád čte jako sent: delivery report se spáruje s originálem a označí se na vlákně, ale do řádku odeslání se nic nezapisuje – jeho status žádný stav pro bounce nemá. Potlačení, které z toho plyne, je skutečné: tvrdý bounce nebo stížnost dostane adresu na suppression list tohoto workspace a další odeslání na ni bude odmítnuto. Nepoučí se právě ten záznam o odeslání.
• —Žádný obecný omezovač rychlosti požadavků. Existují dva počítané stropy a oba odpovídají 429: workspace, který vyčerpá měsíční limit odeslání obsažený v jeho plánu, dostane na každé další odeslání send_quota_exceeded až do prvního dne v měsíci, a zakládání jednorázových schránek je omezené na šest za hodinu a třicet za den na klienta s too_many_inboxes. Ani jeden nenese Retry-After. Omezovač rychlosti běžných čtení a zápisů je absence, ne slib, a bude napraven.
• —Na API není žádný endpoint pro NAHRÁVÁNÍ příloh. Vložené přílohy jsou base64 a v rámci zprávy jsou omezené na 5 MB. Větší soubor se posílá jako { fileId }, který pojmenuje soubor už uložený ve workspace, a putuje jako odkaz ke stažení. Čtení příloh z přijaté pošty funguje.