
Intégration API Mailjet
Nous développons votre connecteur Mailjet
Nous branchons Mailjet à votre produit : emails transactionnels, relances et hygiène de base. Chaque message est rattaché à une intention métier, la recette ne pollue pas les boîtes.
- Équipe produit senior
- connecteurs email en production
- du cadrage au monitoring
À quoi sert l'API Mailjet et quand choisir Mailjet pour ses emails applicatifs ?
Mailjet est un outil français d'envoi d'emails transactionnels et marketing qui permet à votre application d'envoyer des emails déclenchés par des événements métier : confirmation, relance, notification, et de gérer des campagnes depuis la même plateforme. On choisit Mailjet quand les équipes marketing veulent garder la main sur les templates sans passer par les développeurs, et que les emails transactionnels et les campagnes doivent cohabiter dans le même outil avec des statistiques consolidées. La plateforme est hébergée en Europe, ce qui facilite la conformité RGPD.
Ce que nos clients construisent sur l'API Mailjet
Emails transactionnels par gabarit
Invitation, facture, reset : TemplateID côté métier, CustomID stable, variables dans le message. Le bounce n'est plus un e-mail perdu.
Hygiène de base depuis les webhooks
bounce, blocked, spam, unsub redescendent dans le produit. On arrête d'écrire à une adresse morte, pas seulement dans Mailjet.
Relance devis et transactionnel ensemble
Même domaine authentifié, même désinscription. Un SaaS qui n'envoie que du « mot de passe oublié » n'a pas besoin de ça ; un éditeur qui relance des devis si.
SMS OTP via v4, si le contrat est ouvert
Si le contrat SMS est ouvert, l'OTP part sur un accès dédié. On ne mélange pas le canal email et le canal SMS.
Ce que ça change dans vos communications
La technique au service d'un résultat mesurable : une clé métier, une base propre, une recette sans polluer les boîtes.
Chaque envoi a une clé métier
Facture, reset, invitation : la notification se rattache à l'intention, pas seulement à l'adresse e-mail.
La recette ne brûle pas la réputation
En test, l'e-mail n'est pas livré aux vrais destinataires. La clé de production n'entre pas dans la CI.
Un rejeu ne double pas l'envoi
La déduplication vit dans votre table d'envois. Si la file rejoue, le client ne reçoit pas deux fois le même message.
Le marketing et le produit partagent la liste
Une désinscription vaut pour les deux flux. Vous n'avez pas deux bases à réconcilier en fin de mois.
Comment nous livrons votre connecteur Mailjet
Cadrage
Quels messages, quel volume, gabarits ou HTML, SMS ou non. On tranche CustomID, webhooks v2, et ce qui reste du côté Resend si l'idempotence native est un critère.
Développement
Send v3.1, table d'envois, CustomID stable, handler webhook v2 avec dédup MessageID + event + time, clés par environnement.
Recette
SandboxMode en CI, From validé, To indépendants (N Messages, pas N adresses), 429 avec backoff, secret d'URL webhook non HMAC.
Monitoring
Alertes sur bounce et 429, file morte inspectable, tableau CustomID. Vous voyez une clé révoquée avant vos clients.
Ce que permet l'API Mailjet
- Send v3.1
- Corps racine Messages, From préalablement validé, TextPart et/ou HTMLPart ou TemplateID. Plafond de 50 éléments dans les tableaux (erreur mj-0008).
- CustomID métier
- Identifiant renvoyé dans les webhooks, filtrable en GET /v3/REST/message. C'est le pont entre l'ESP et votre dossier, qu'un SMTP nu n'a jamais.
- Webhooks eventcallbackurl
- open, click, bounce, spam, blocked, unsub, sent. Version 2 : événements regroupés, au plus une fois par seconde. Version 1 : un POST par événement.
- ESP complet, SMS à part
- Contacts, listes, campagnes, gabarits, stats, parse inbound. Le SMS v4 vit sur /v4/ avec un token, plus la Basic v3.
Le vocabulaire de l'API Mailjet
- CustomID
- Identifiant métier posé à l'envoi, renvoyé dans les webhooks, filtrable sur /message. C'est de la corrélation, pas de l'anti-double envoi : un retry POST renvoie quand même.
- SandboxMode
- Propriété racine du POST /v3.1/send. L'e-mail n'est pas livré, les erreurs de validation si. Idéal en CI, jamais avec la clé de production.
- Messages[]
- Tableau racine v3.1. Les To d'un même message se voient entre eux. Pour N destinataires indépendants, N objets Messages, pas N adresses dans To.
- eventcallbackurl v2
- Webhooks regroupés, au plus une fois par seconde. La v1 plus l'événement sent à fort volume saturent votre endpoint ou Mailjet. La doc pousse la v2.
- mj-0008
- Erreur si un tableau (Messages, pièces jointes, headers, variables) dépasse 50 éléments. Le batch se découpe côté application, pas en gonflant un seul POST.
- From validé
- L'expéditeur doit être préalablement validé et actif. Un From inconnu échoue. C'est un prérequis DNS (SPF, DKIM) autant qu'API.
Les contraintes réelles de l'API Mailjet
Pas d'Idempotency-Key documentée
CustomID corrèle, il ne déduplique pas. Un retry de POST /v3.1/send peut double-envoyer. La protection est une table d'envois, ou un autre fournisseur sur ce critère.
Pas de HMAC webhook dans le guide officiel
Le guide décrit événements et champs, pas de secret HMAC. Authentifier l'appelant (secret dans l'URL, allowlist IP, TLS) se conçoit côté produit. Ce n'est pas Svix.
Les chiffres de débit ne sont pas publics
429 si dépassement, plafond « élevé » en transactionnel, « beaucoup plus bas » ailleurs. Aucun req/s publié. Bulk, cache, sous-comptes, backoff.
HTML seul, pas de text/plain généré
Mailjet ne fabrique pas la partie texte à votre place. Accessibilité et filtres anti-spam : on envoie TextPart, ou on assume le risque.
Mailjet ou Resend pour vos emails ?
Un ESP (transactionnel, marketing, contacts, SMS) d'un côté, une API d'envoi idempotente de l'autre. Ce n'est pas un choix de SDK.
| Critère | MailjetCette page | ResendAPI d'envoi |
|---|---|---|
| Produit | ESP : tx, marketing, contacts, SMS | API d'envoi, broadcasts limités |
| Idempotence | CustomID (corrélation, pas anti-doublon) | Idempotency-Key, fenêtre 24 h |
| Webhooks | eventcallbackurl v2, pas de HMAC dans le guide | Svix, HMAC, en-têtes svix-* |
| Sandbox | SandboxMode racine | Domaine resend.dev / clés de test |
| Résidence | DPA du compte à relire | Compte US, envoi optionnel eu-west-1 |
| Débit documenté | 429, chiffres non publiés | 10 req/s par équipe, en-têtes IETF |
| Le bon cas | Tx + marketing + SMS dans un compte | Email transactionnel idempotent de SaaS |
Les deux se combinent : Mailjet pour le cycle de vie et les listes, Resend pour un magic link qui ne doit pas partir deux fois. C'est un arbitrage de cadrage, pas un choix définitif.
Ce que nous mesurons sur une intégration Mailjet
Les autres API d'envoi
Si l'ESP n'est pas le produit que vous voulez, ces options se discutent au cadrage.
MailjetNous développons votre connecteur MailjetCette page
TwilioOpérateur programmable : SMS, WhatsApp, voix et OTP prêt à l'emploi.
BrevoEmail transactionnel et SMS dans un compte français, gabarits inclus.
RingoverTéléphonie française : appels, remontée de fiche et SMS métier.
ResendNous développons votre connecteur ResendOn combine Mailjet avec
La stack qui entoure Mailjet sur nos projets.
Intégration Mailjet : vos questions
Trois étapes. Générer une paire de clés par environnement, en HTTP Basic, et un token distinct si le SMS v4 est au programme. Construire un connecteur Send v3.1 qui pose un CustomID stable, découpe à 50 messages, envoie TextPart et HTMLPart, et refuse de partir tant que le From n'est pas validé. La déduplication vit dans votre table d'envois, parce que Mailjet ne documente pas d'Idempotency-Key. Puis brancher les webhooks en v2, handler 200 rapide, file, dédup sur MessageID + event + time. Sans HMAC dans le guide officiel, l'appelant s'authentifie par secret d'URL, allowlist IP et TLS, et un événement ne vaut jamais autorisation.
Un premier flux utile, typiquement les emails transactionnels par gabarit avec CustomID et bounce en webhook, se livre en deux à trois semaines. Une chaîne complète avec listes, campagnes, parse inbound, SMS v4 et centre de préférences demande plutôt six à huit semaines. Le DNS (SPF, DKIM) et l'état de la base pèsent souvent plus que le POST /send. Nous cadrons le périmètre en amont et donnons une estimation ferme avant de commencer.
Le guide officiel des webhooks décrit les événements, les champs et le groupement v2, pas un secret HMAC. Nous ne l'affirmons pas. En l'état, l'authentification de l'appelant se conçoit côté produit : URL non devinable, secret dans l'URL, allowlist IP, TLS, validation stricte du schéma. Surtout, un bounce reçu ne coupe pas une adresse tout seul : on déduplique, on rattache le CustomID, on revérifie l'état. C'est le contraste le plus net avec Resend, dont les webhooks Svix portent svix-id, svix-timestamp et svix-signature.
Mailjet est un ESP : transactionnel, marketing, contacts, gabarits, SMS v4. CustomID corrèle un bounce à une commande. SandboxMode teste sans livrer. Resend est une API d'envoi avec Idempotency-Key sur 24 h et des webhooks Svix signés. Les données de compte Resend restent aux États-Unis, même en envoyant depuis eu-west-1. On choisit Mailjet quand le marketing et le produit partagent la liste. On choisit Resend quand un magic link ne doit pas partir deux fois, et que le DPA US est accepté. Il arrive que la réponse soit les deux.
Parce que les To d'un même objet Message se voient entre eux. Pour N destinataires indépendants (facture, reset, invitation), il faut N objets dans le tableau Messages, pas N adresses dans To. C'est le piège le plus fréquent au premier branchement v3.1, avec le plafond de 50 et SandboxMode oublié en recette. Nous ajoutons un test qui refuse un To multiple sur un gabarit transactionnel unitaire, et nous découpons les lots avant mj-0008.
Un projet d'intégration Mailjet ?
Parlons-en. 30 minutes pour cadrer vos envois, vérifier ce que l'API permet vraiment et vous dire franchement ce qui est faisable.
Parler de mon projet Mailjet