Intégration d'une API SMS et email
Le produit décide de l'envoi, pas l'outil d'emailing
Nous câblons l'email transactionnel, le SMS et la téléphonie sur vos événements métier. Facture payée, code, statut : le message part d'un état, pas d'une boîte.
- Connecteurs message en production
- transactionnel cadré
- journal RGPD
Qu'est-ce qu'une API SMS et email et quand la faire intégrer ?
Une API SMS, email ou téléphonie permet à votre application d'envoyer un message, de vérifier un numéro, de relancer un client ou de faire décrocher un agent, et d'en suivre la délivrance. Les plugins prêts à l'emploi couvrent l'envoi simple. On fait développer l'intégration quand l'OTP doit être idempotent, quand un hard bounce doit couper l'adresse, quand la fenêtre légale française s'applique côté code, ou quand l'appel doit partir de la fiche client plutôt que d'un softphone à côté.
Les API SMS, email et téléphonie que nous intégrons
Twilio
SMS, OTP, WhatsApp et voix programmable, avec suivi de délivrance.
Brevo
Email transactionnel et SMS dans un compte français, gabarits inclus.
Ringover
Téléphonie d'agents : click-to-call, remontée de fiche, journal d'appels.
Mailjet
L'envoi d'emails à volume, éditeur français, sans brique téléphonie.
Resend
L'alternative moderne pour l'email transactionnel, à brancher sur le produit.
Ce qui sort encore d'une boîte mail
L'outil d'envoi envoie. Tant que l'événement vit dans une tête, OTP, facture et désinscription restent artisanaux.
On ne sait pas si le SMS est arrivé
Le statut de délivrance revient dans votre produit. Un échec déclenche un autre canal ou une alerte, pas un silence.
On continue d'écrire à des adresses mortes
Un hard bounce coupe l'adresse dès le premier rejet. La délivrabilité se protège dans le connecteur, pas dans un rapport lu trop tard.
L'OTP part deux fois, ou jamais
Chaque création porte une clé d'idempotence. Un rejeu ne produit pas un second SMS, un incident réseau ne laisse pas l'utilisateur sans code.
Les agents tapent le numéro à la main
Click-to-call depuis la fiche, remontée à la sonnerie, journal sans saisie. La téléphonie vit dans le métier, pas à côté.
Ce que chaque API de communication implique concrètement
Brevo
Email + SMS FREmail transactionnel et SMS dans un compte français, avec gabarits et webhooks de délivrabilité. Utile quand marketing et transactionnel doivent rester dans le même outil, et quand un hard bounce doit couper l'adresse dès le premier rejet. La sync des contacts se cadre pour ne pas écraser le consentement.
- Email et SMS transactionnels
- Hard bounce coupé
- Contacts synchronisés sans écraser le consentement
Mailjet
Email à volumeUn éditeur français d'email à volume, sans brique téléphonie. Sans fiche détaillée ici : l'intégration se juge sur les gabarits, les webhooks de délivrabilité et le traitement des bounces, pas sur un catalogue de routes annoncé.
- Envoi à volume
- Délivrabilité suivie
- Périmètre tranché au cadrage
Resend
Email moderneUne option moderne pour l'email transactionnel, utile quand l'équipe produit veut une API simple plutôt qu'une suite marketing. Page courte par construction : le cadrage fixe les événements à envoyer, le domaine et le suivi des bounces. Pas de routes inventées.
- Email transactionnel dans le produit
- Domaine et bounces cadrés
- Alternative légère
Ringover
Téléphonie agentsUn opérateur français qui équipe des humains qui téléphonent : postes, supervision, click-to-call, remontée de fiche. L'API sert à greffer cette téléphonie sur le logiciel métier. Le débit est serré et l'identifiant d'appel n'est pas une clé primaire : cela se conçoit dans le connecteur, pas après coup.
- Click-to-call depuis la fiche
- Remontée à la sonnerie
- Journal sans compte rendu saisi
Twilio
SMS, OTP, voixL'opérateur programmable : SMS, Verify pour l'OTP, WhatsApp, voix. Le cluster utile est générique (api sms, api envoi sms) plus que la marque. L'intégration se juge sur l'idempotence, le suivi de délivrance et la fenêtre légale française appliquée côté code, pas sur le premier POST Messages.
- SMS, OTP et WhatsApp dans le produit
- Statut de délivrance journalisé
- Fenêtre légale côté code
Quatre envois nés d'un événement
OTP et codes depuis le compte
Le code naît dans l'application, l'envoi est un canal. Plus de SMS tapé dans un outil à côté.
Transactionnel de facturation
Émise, relancée, payée : les mails suivent l'état. Le marketing reste dans l'ESP, le transactionnel dans le produit.
Voix ou SMS de repli
Quand l'email rebondit, un second canal. Le compte est mis à jour, pas seulement la campagne.
Bounce qui corrige la fiche
Un dur bounce invalide l'adresse. Le DPO a un journal, le commercial n'écrit plus dans le vide.
Produit, ops, DPO, finance : le canal a un coût
Nous ne « branchons pas Brevo ». Nous posons la taxonomie d'événements et l'identité d'expéditeur.
Le produit possède l'événement
« facture.payée » n'est pas un template marketing. Nous le figeons, puis nous le routons.
Les ops voient les bounces
La délivrabilité redevient un signal. Un domaine qui brûle se voit avant le blacklisting.
Le DPO a un journal d'envoi
Qui a reçu quoi, sur quel fondement, jusqu'à quand. Ce n'est pas un export de campagne.
La finance plafonne le SMS
Le coût A2P se conçoit. Nous posons les gardes, pas une surprise en fin de mois.
Ce que nous avons livré, et qui s'applique ici
Ce qu'un canal d'envoi force comme méthode
Transactionnel vs marketing
Séparation des flux, des domaines, des bases d'opt-in.
Livrable : clôture des régimesIdentité d'expéditeur
Domaine authentifié, IDs d'expéditeur, environnements.
Livrable : identité d'envoiTraitement des bounces
Classes de bounce, mise à jour fiche, alerte de réputation.
Livrable : règle de bounceJournal RGPD
Journal, conservation, responsable du traitement.
Livrable : journal d'envoiCe que personne ne vous dit avant de signer
Un envoi sans suivi n'existe pas
Sans webhook de statut, vous ne savez pas si le message est arrivé. Le connecteur traite la délivrance comme un cas nominal, pas comme un rapport optionnel.
La fenêtre légale se code, elle ne se documente pas
Un SMS marketing hors créneau est un risque, pas un oubli. La règle vit dans le connecteur, avec un refus explicite plutôt qu'un envoi « on verra ».
L'idempotence n'est pas un luxe sur l'OTP
Un double envoi coûte cher et brouille l'utilisateur. Chaque création porte une clé, et un rejeu reprend le même message.
Téléphonie d'agents et voix programmable ne se mélangent pas
Ringover équipe des humains. Twilio fait téléphoner une application. Les coller sans le dire produit deux journaux et zéro vérité d'appel.
Ce que nous mesurons sur un projet SMS et email
Intégration d'une API SMS et email : vos questions
Trois étapes. D'abord figer les événements qui envoient (OTP, notification, relance) et la fenêtre légale qui s'applique. Ensuite construire un connecteur côté serveur, avec une clé d'idempotence sur chaque création, les secrets isolés et le traitement des webhooks de statut. Enfin couper les échecs : bounce, crédit insuffisant, hors créneau. La partie sensible n'est jamais l'appel d'envoi, c'est le suivi et le rejeu.
Cela dépend des canaux et des cas de bord. Un OTP Twilio se chiffre bien plus bas qu'une chaîne complète email + SMS + téléphonie d'agents. La délivrabilité, le consentement et le journal pèsent autant que le premier envoi. Nous cadrons le périmètre en amont et donnons une estimation ferme.
Twilio fait téléphoner et envoyer depuis une application : SMS, OTP, WhatsApp, voix programmable. Brevo envoie l'email transactionnel et le SMS depuis un compte français, gabarits inclus. Ringover équipe des agents humains : postes, click-to-call, remontée de fiche. On les combine souvent. Le bon schéma se décide sur qui envoie, et qui décroche.
Oui, et c'est fréquent : un canal transactionnel, un canal marketing, une téléphonie d'agents. La difficulté est de garder une seule vérité côté produit. Nous posons un modèle interne de message, indépendant du prestataire, avant d'atteindre votre logique métier. Sans cette couche, chaque canal duplique le consentement et le journal.
En traitant le webhook comme un événement métier. Un hard bounce coupe l'adresse, un soft bounce se retente selon une politique, un spam complaint sort de la liste. Relancer une adresse morte pour « voir » détruit la réputation du domaine. Cette politique se code au cadrage, avec votre équipe produit, pas dans un tableau de bord lu après coup.
Quels événements doivent vraiment partir ?
30 minutes pour séparer transactionnel et marketing, poser l'identité d'expéditeur et le journal que le DPO attend.
Parler de mon projet SMS et email