Une API pour SMS, WhatsApp et RCS : le routage intelligent de Sent

Ajouter la messagerie à une app semble tenir en une ligne jusqu'à la seconde requête. SMS, WhatsApp et RCS ont chacun leurs identifiants, formats et pannes ; un marché préfère le SMS, un autre WhatsApp, un troisième ouvre à peine le RCS. La démo d'Eric Tech s'installe là et teste Sent — une API unifiée qui promet de parler aux trois depuis une seule requête — jusqu'à un vrai mobile. Le plus rapide du titre est moins slogan qu'architecture : l'app ne choisit pas le canal, la plateforme décide et montre son choix.

Pourquoi un seul canal ne suffit pas

Beaucoup démarraient en SMS, ajoutaient WhatsApp quand ça prenait, puis patchaient le RCS. Chaque branche = un fournisseur, une auth, un langage de modèle, plus un fallback maison quand un canal cale. À l'international c'est pire, SMS cher ou peu fiable ici, faible pénétration WhatsApp là. Le code se ramifie, la matrice de tests gonfle, chaque canal ouvre une fenêtre de maintenance. La vidéo résume : envoyer est facile, livrer partout est difficile.

Comment fonctionne le routage intelligent de Sent

Sent inverse la charge. Pas de SMS/WhatsApp/RCS dans la requête ; on donne un destinataire et une référence de modèle, la plateforme choisit. La doc décrit un routeur qui pèse disponibilité, signaux d'engagement et coût pour élire le meilleur canal live et reformater le contenu. Les modèles gardent le texte hors du code, le même appel peut tomber en SMS aujourd'hui et en RCS demain sans changer le code. Conformité, identité et secours restent côté plateforme — code léger, délivrabilité robuste.

Câbler le flux de notification en TypeScript

Démo volontairement modeste. Nouveau projet TypeScript, SDK Sent, clé API et numéro cible en env ; l'expéditeur partagé fait démarrer vite. Une identité dédiée existe aussi, mais l'approbation US 10DLC/TCR prend 1–3 jours ouvrés, autant commencer tout de suite. Le flux tourne autour de sent.message avec modèle et variables, pas de texte en dur, ce qui aide l'adaptation multi-canal et la maintenance. Le squelette ressemble à une petite feature de notification mais peut vivre dans une plus grande app.

Le premier envoi renvoie ID et état initial. Un instant plus tard le canal choisi devient visible — là l'abstraction prouve sa valeur. La même requête peut donner SMS, WhatsApp ou RCS sans branche côté app ; les détails se résolvent côté plateforme. La décision est observable, pas cachée. Voir le chemin dans les logs rend debug et optimisation coût possibles et supprime les suppositions de canal à l'international.

La livraison est asynchrone : de sent à delivered via webhook

Un accept API n'est pas une livraison ; la messagerie est asynchrone. D'où le second acte : les webhooks. Dans le dashboard Sent on enregistre un endpoint, on s'abonne à message.sent et message.delivered, on expose le handler local via tunnel. Le handler logue ID, type, canal et état, vérifie la signature secrète d'env pour ignorer le bruit internet. On rejoue : sent d'abord, delivered quand l'opérateur confirme, trace complète dans un terminal. Le message qui s'affiche sur un vrai mobile est la preuve live — pas un mock.

Preuve sur mobile réel et sens à l'échelle

À la fin la promesse se précise : quand les canaux se multiplient, pas de branches en plus dans le code. Même requête, même ref modèle, même webhook ; quand la couverture RCS s'étend ou les prix bougent, le routeur met à jour son choix sans toucher la couche notification. L'abstraction réduit la maintenance et améliore la délivrabilité pour transactionnel, vérification ou alertes, surtout à l'international. Les pages lifecycle, setup et events de la doc bouclent la boucle.