Bonjour,
Après plusieurs tests sur l’envoi de mails transactionnels programmés via l’API, nous rencontrons un comportement que nous ne comprenons pas.
Pour la programmation des mails, nous utilisons la méthode sendTransacEmail, visible ici Send a transactional email, via le nugget C# (GitHub - getbrevo/brevo-csharp), à laquelle nous passons une date pour le paramètre scheduledAt, ainsi qu’un UUIDv4 converti en string pour le paramètre batchId.
Suite à l’appel de la méthode sendTransacEmail, nous recevons les messages Id correspondant à chacun des envois programmés.
Lorsque les mails finissent par partir effectivement (à la date programmée), et que l’on récupère l’activité de nos emails transactionnels (via le point d’entrée « tous les évènement » : Get all your transactional email activity (unaggregated events)), nous récupérons bien les évènements liés à ces mails, mais les messages Id ont été mis à jour à la date d’envoi programmée, et ne correspondent plus à ceux récupérés au départ (par exemple 202501061637.25580983331.1@smtp-relay.mailin.fr devient 202501061641.50876278835.1@smtp-relay.mailin.fr lorsque programmé 4 minutes plus tard).
Le problème, c’est que dans les tests nous voyons bien qu’il s’agit des mêmes car nous n’avons pas fait plusieurs envois, mais dans nos développements, nous n’avons aucun moyen d’être sûr qu’il s’agit bien des mêmes, l’identifiant unique étant censé être le message Id.
S’agit-il d’un comportement « normal » ? Et si oui, pourriez-vous nous indiquer comment faire le lien entre les messages programmés et ceux effectivement envoyés ?
Merci d’avance pour votre éclairage là dessus.
Bonjour,
Merci pour ces détails. Je ne suis pas un expert de ce sujet, mais essayons d’y réfléchir ensemble.
J’ai l’impression que le nouvel id, en tout cas la partie avant le premier « . », correspond à la date et l’heure d’envoi effective du message, est-ce que c’est une hypothèse valable ?
Bonjour @ahudavert,
Merci pour votre retour.
Alors, de ce que je vois, cela semble plutôt être la date et l’heure d’envoi programmés.
J’ai par exemple réalisé un test ou je programmais plus de mails que de crédits disponibles au moment de l’heure de programmation.
Même ceux partis après recharge du crédit ont la date et l’heure d’envoi programmé comme ceux partis effectivement à cette heure là.
Pour ce qui est du chiffre entre les deux « . » il semble s’agir d’un chiffre identifiant une vague de mail programmés (un appel au EndPoint permettant l’envoi) indépendamment d’un éventuel batchId qui ait été défini.
En effet, sur deux mailings programmés à la même date et même heure mais réalisés à deux moments différents, les mails de l’un et de l’autre ont chacun un chiffre différents.
Toutefois, il diffère aussi de celui reçu au moment de la programmation.
Le dernier chiffre avant l’arobase semble être un compteur pour différencier chaque mail au sein d’une vague de programmation.
Il semblerait que l’ordre soit conservé entre l’ordre reçu au moment de la programmation et l’ordre d’envoi effectif, mais je n’ai fait le test que sur des petits volumes, donc je ne peux pas confirmer que ça soit réellement le cas.
Je ne sais pas si je suis bien clair, mais pour l’instant c’est les seules conclusions que j’ai réussi à faire à partir de mes tests.