Ainda por construir

Descobrir por tentativa é pior do que ser avisado. Nada disto existe hoje:

• —Uma entrega é tentada até cinco vezes: no momento, depois ao fim de 1 minuto, 5, 25 e 2 horas. Todas as tentativas ficam registadas e são legíveis através de GET /webhooks/{id}/deliveries, cada uma com o seu attempt e maxAttempts. As tentativas param mais cedo quando a resposta diz que repetir não serve de nada: qualquer coisa que não seja 408, 425, 429 ou um 5xx é entendida como uma rejeição deliberada. Continua a não haver endpoint de reenvio, por isso um endpoint em baixo durante mais tempo do que essa janela fica com uma lacuna, e o registo de entregas é onde a encontra.
• —Uma mensagem devolvida continua a aparecer como sent através de GET /emails: o relatório de entrega é associado ao original e etiquetado na conversa, mas nada escreve de volta na linha do envio, cujo estado não tem um estado de devolução. A supressão que isso alimenta é real: um hard bounce ou uma queixa põe o endereço na lista de supressão deste espaço de trabalho e o envio seguinte para ele é recusado. É o registo do envio que não aprende.
• —Não há limitador geral de taxa de pedidos. Existem dois tectos contados e ambos respondem 429: um espaço de trabalho que gaste a quota mensal de envios incluída no seu plano recebe send_quota_exceeded em todos os envios seguintes até ao dia 1 do mês, e a criação de caixas descartáveis está limitada a seis por hora e trinta por dia por cliente, com too_many_inboxes. Nenhum deles traz um Retry-After. Um limitador sobre o ritmo de leituras e escritas comuns é uma ausência e não uma promessa, e é algo que será corrigido.
• —Não há endpoint de CARREGAMENTO de anexos na API. Os anexos embutidos são base64 e estão limitados a 5 MB no total da mensagem. Um ficheiro maior é enviado como { fileId }, nomeando um ficheiro que já está no espaço de trabalho, e viaja como uma ligação de transferência. Ler anexos de correio recebido funciona.