CIIFragments Studio est agréée CII : récupérez jusqu'à 20 % de vos dépenses en développement logicielEn savoir plus

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
En bref

À 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.

Cas d'usage

Ce que nos clients construisent sur l'API Mailjet

01

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.

02

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.

03

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.

04

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.

Pour vous

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.

Méthode

Comment nous livrons votre connecteur Mailjet

01

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.

02

Développement

Send v3.1, table d'envois, CustomID stable, handler webhook v2 avec dédup MessageID + event + time, clés par environnement.

03

Recette

SandboxMode en CI, From validé, To indépendants (N Messages, pas N adresses), 429 avec backoff, secret d'URL webhook non HMAC.

04

Monitoring

Alertes sur bounce et 429, file morte inspectable, tableau CustomID. Vous voyez une clé révoquée avant vos clients.

L'API

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.
Vocabulaire

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.
À savoir

Les contraintes réelles de l'API Mailjet

01

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.

02

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.

03

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.

04

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

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èreMailjetCette pageResendAPI d'envoi
ProduitESP : tx, marketing, contacts, SMSAPI d'envoi, broadcasts limités
IdempotenceCustomID (corrélation, pas anti-doublon)Idempotency-Key, fenêtre 24 h
Webhookseventcallbackurl v2, pas de HMAC dans le guideSvix, HMAC, en-têtes svix-*
SandboxSandboxMode racineDomaine resend.dev / clés de test
RésidenceDPA du compte à relireCompte US, envoi optionnel eu-west-1
Débit documenté429, chiffres non publiés10 req/s par équipe, en-têtes IETF
Le bon casTx + marketing + SMS dans un compteEmail 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.

Notre expertise

Ce que nous mesurons sur une intégration Mailjet

15 j
premier flux Mailjet en production
7
types d'événements webhook traités
0
e-mail envoyé deux fois sur un rejeu
4
développeurs seniors sur le projet

On combine Mailjet avec

La stack qui entoure Mailjet sur nos projets.

  • Stripe
  • HubSpot
  • n8n
  • PostgreSQL
  • Node.js
FAQ

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
Parler de mon projet Mailjet