Nog niet gebouwd

Erachter komen door het te proberen is erger dan het te horen te krijgen. Niets hiervan bestaat vandaag:

• —Een aflevering wordt tot vijf keer geprobeerd: op het moment zelf, daarna na 1 minuut, 5, 25 en 2 uur. Elke poging wordt vastgelegd en is te lezen via GET /webhooks/{id}/deliveries, elk met zijn attempt en maxAttempts. Het opnieuw proberen stopt eerder wanneer het antwoord zegt dat herhalen zinloos is: alles anders dan 408, 425, 429 of een 5xx wordt opgevat als een bewuste afwijzing. Er is nog steeds geen replay-endpoint, dus een endpoint dat langer dan dat venster uit de lucht is heeft een gat, en het afleveringslogboek is waar je het vindt.
• —Een gebouncet bericht leest via GET /emails nog steeds als sent: het bezorgrapport wordt aan het origineel gekoppeld en op de thread gelabeld, maar er wordt niets teruggeschreven naar de verzendrij, waarvan de status geen bounced-toestand kent. De onderdrukking die het voedt is echt: een hard bounce of een klacht zet het adres op de onderdrukkingslijst van deze workspace en de volgende verzending ernaartoe wordt geweigerd. Het is het verzendrecord dat niets leert.
• —Geen algemene rate limiter op verzoeken. Er bestaan wel twee getelde plafonds en beide antwoorden met 429: een workspace die het maandelijkse verzendtegoed van zijn plan opmaakt krijgt send_quota_exceeded op elke verdere verzending tot de eerste van de maand, en het aanmaken van wegwerp-inboxen is begrensd op zes per uur en dertig per dag per client met too_many_inboxes. Geen van beide draagt een Retry-After. Een limiet op de snelheid van gewone lees- en schrijfacties is een afwezigheid en geen belofte, en een die nog rechtgezet zal worden.
• —Geen UPLOAD-endpoint voor bijlagen op de API. Inline bijlagen zijn base64 en zijn begrensd op 5 MB over het hele bericht. Een groter bestand wordt verstuurd als { fileId }, dat een bestand noemt dat al in de workspace staat, en reist mee als downloadlink. Bijlagen uitlezen uit ontvangen post werkt wel.