Encara no fet

Descobrir-ho provant-ho és pitjor que saber-ho. Res d'això no existeix avui:

• —Un lliurament s'intenta fins a cinc vegades: en el moment, i després al cap d'1 minut, 5, 25 i 2 hores. Cada intent es registra i es pot llegir amb GET /webhooks/{id}/deliveries, cadascun amb el seu attempt i maxAttempts. Els reintents s'aturen abans d'hora quan la resposta diu que repetir-ho no té sentit: qualsevol cosa que no sigui 408, 425, 429 o un 5xx es pren com un rebuig deliberat. Encara no hi ha cap endpoint de repetició, de manera que un endpoint caigut més estona que aquesta finestra té un buit, i el registre de lliuraments és on el trobaràs.
• —Un missatge rebotat continua llegint-se com a sent a través de GET /emails: l'informe de lliurament es fa coincidir amb l'original i s'etiqueta al fil, però no s'escriu res a la fila d'enviament, l'estat de la qual no té cap valor de rebot. La supressió que alimenta sí que és real: un rebot dur o una queixa posa l'adreça a la llista de supressió d'aquest espai de treball i el proper enviament a aquesta adreça es rebutja. És el registre d'enviament el que no n'aprèn.
• —No hi ha cap limitador general del ritme de peticions. Sí que existeixen dos sostres comptats i tots dos responen 429: un espai de treball que gasta l'assignació mensual d'enviaments que inclou el seu pla rep send_quota_exceeded en cada enviament posterior fins al dia u del mes, i encunyar bústies d'un sol ús està limitat a sis per hora i trenta per dia i client amb too_many_inboxes. Cap dels dos porta un Retry-After. Un limitador del ritme de lectures i escriptures ordinàries és una absència i no una promesa, i una absència que es corregirà.
• —No hi ha cap endpoint de PUJADA d'adjunts a l'API. Els adjunts en línia són base64 i estan limitats a 5 MB per a tot el missatge. Un fitxer més gran s'envia com a { fileId }, que anomena un fitxer que ja és a l'espai de treball, i viatja com a enllaç de descàrrega. Llegir adjunts del correu rebut sí que funciona.