Aller à la documentation
API

Pas encore construit

Listé plutôt qu'omis.

Ce qui manque

Pas encore disponible

Le découvrir en essayant est pire que d'en être informé. Rien de tout cela n'existe aujourd'hui :

  • Une livraison est tentée jusqu'à cinq fois : au moment où elle se produit, puis après 1 minute, 5, 25 et 2 heures. Chaque tentative est enregistrée et lisible via GET /webhooks/{id}/deliveries, chacune portant son attempt et son maxAttempts. Les réessais s'arrêtent plus tôt lorsque la réponse indique qu'il est inutile de recommencer : tout ce qui n'est ni 408, 425, 429 ni un 5xx est pris pour un rejet délibéré. Il n'existe toujours pas de point de terminaison de rejeu : un point de terminaison hors service plus longtemps que cette fenêtre présente donc un trou, et c'est dans le journal des livraisons que vous le trouverez.
  • Un message rejeté se lit toujours comme sent via GET /emails : le rapport de livraison est rapproché de l'original et étiqueté sur le fil, mais rien n'est réécrit dans la ligne d'envoi, dont le statut n'a pas d'état « rejeté ». La suppression qu'il alimente, elle, est bien réelle : un rebond définitif ou une plainte place l'adresse sur la liste de suppression de cet espace de travail et le prochain envoi vers elle est refusé. C'est l'enregistrement d'envoi qui n'apprend rien.
  • Pas de limiteur général de débit des requêtes. Deux plafonds comptabilisés existent bel et bien et répondent tous deux 429 : un espace de travail qui épuise le quota d'envoi mensuel inclus dans son forfait reçoit send_quota_exceeded sur chaque envoi supplémentaire jusqu'au premier du mois, et la création de boîtes de réception jetables est plafonnée à six par heure et trente par jour et par client avec too_many_inboxes. Ni l'un ni l'autre ne porte de Retry-After. Un limiteur sur le débit des lectures et écritures ordinaires est une absence plutôt qu'une promesse, et une absence qui sera corrigée.
  • Pas de point de terminaison de TÉLÉVERSEMENT de pièces jointes sur l'API. Les pièces jointes en ligne sont en base64 et plafonnées à 5 Mo pour l'ensemble du message. Un fichier plus volumineux est envoyé sous la forme { fileId }, désignant un fichier déjà présent dans l'espace de travail, et voyage sous forme de lien de téléchargement. Lire les pièces jointes du courrier reçu fonctionne, en revanche.