Todavía no construido

Descubrirlo probando es peor que que te lo digan. Nada de esto existe hoy:

• —Una entrega se intenta hasta cinco veces: en el momento, y después al cabo de 1 minuto, 5, 25 y 2 horas. Cada intento se registra y se puede leer con GET /webhooks/{id}/deliveries, cada uno con su attempt y su maxAttempts. Los reintentos se detienen antes de tiempo cuando la respuesta indica que repetir no tiene sentido: cualquier cosa distinta de 408, 425, 429 o un 5xx se interpreta como un rechazo deliberado. Sigue sin existir un endpoint de reenvío, así que un endpoint caído durante más tiempo que esa ventana tiene un hueco, y el registro de entregas es donde lo encuentras.
• —Un mensaje rebotado sigue apareciendo como sent en GET /emails: el informe de entrega se empareja con el original y se etiqueta en la conversación, pero nada se escribe de vuelta en la fila de envío, cuyo estado no tiene un valor de rebote. La supresión que alimenta sí es real: un rebote permanente o una queja pone la dirección en la lista de supresión de este espacio de trabajo y el siguiente envío a ella se rechaza. Es el registro de envío el que no aprende.
• —No hay un limitador general de tasa de solicitudes. Sí existen dos topes contabilizados y ambos responden 429: un espacio de trabajo que agota el cupo mensual de envíos que incluye su plan recibe send_quota_exceeded en cada envío posterior hasta el día uno del mes, y la creación de buzones desechables está limitada a seis por hora y treinta al día por cliente con too_many_inboxes. Ninguno lleva Retry-After. Un limitador sobre la tasa de lecturas y escrituras ordinarias es una ausencia y no una promesa, y una que se corregirá.
• —No hay endpoint de SUBIDA de adjuntos en la API. Los adjuntos en línea van en base64 y están limitados a 5 MB en todo el mensaje. Un archivo mayor se envía como { fileId }, nombrando un archivo que ya está en el espacio de trabajo, y viaja como enlace de descarga. Leer adjuntos del correo recibido sí funciona.