Changelog

POST /v1/messages avec "channel": "email" accepte désormais attachments, avec un contenu rédigé ou un template.

• Format : une liste d'objets {"filename": "facture.pdf", "content": "<base64>"}, avec content_type en option (déduit du nom du fichier sinon).
• Limites : 10 fichiers et 18 Mo au total. Les fichiers exécutables (.exe, .js, .bat, .ps1…) sont refusés.
• Coût : inchangé.

L'API envoie désormais des emails et des codes de vérification par email, depuis votre propre adresse d'expéditeur vérifiée.

• Envoyer un email : POST /v1/messages avec "channel": "email", jusqu'à 30 adresses par requête. Rédigez le contenu (subject avec message et/ou html) ou utilisez l'un de vos templates email avec template_name.
• Variables : template_variables remplit les variables du type {{nom}} pour toute la requête. Une variable manquante vous est signalée au lieu de laisser un blanc.
• HTML et texte : avec html et message, chacun devient sa propre partie de l'email ; avec html seul, la version texte est construite pour vous ; avec message seul, l'email part en texte simple.
• Adresse de réponse : reply_to accepte jusqu'à 5 adresses, par exemple ["support@exemple.com"].
• Coût : un email rédigé dans la requête est transactionnel, 1 crédit par destinataire. Avec un template, sa catégorie s'applique : 1 crédit en transactionnel, 2 en marketing.
• Codes de vérification par email : POST /v1/verifications avec "channels": ["email"], seul ou avec le SMS et WhatsApp. Ajoutez email et email_sender_name ; en option email_template_name (il doit contenir {{code}}) et email_subject. Sans template, un email sobre affiche le code et sa durée de validité. Toujours 1 crédit.
• Statuts de livraison : chaque destinataire passe en livré, lu ou en échec, et votre webhook reçoit les statuts livré et échec, au même format que le SMS, avec l'adresse email dans contact.

Une campagne n'exige plus de groupe. Vous pouvez désormais choisir des contacts un par un dans votre répertoire et leur envoyer directement, sans créer de groupe au préalable.

• Trois sources, combinables : vos groupes, les contacts choisis dans le répertoire, et les numéros saisis à la main. Une seule, ou les trois dans la même campagne.
• Les récurrences aussi : la même possibilité s'applique quand vous programmez une campagne qui se répète.
• Compté une seule fois : un contact présent dans un groupe et choisi aussi individuellement ne reçoit qu'un message, et n'est facturé qu'une fois. Le nombre de destinataires affiché avant l'envoi est celui après dédoublonnage.
• Les numéros écartés sont signalés : un numéro saisi à la main invalide ou hors des pays autorisés vous est rendu avec son motif, au lieu de disparaître en silence.
• La personnalisation reste assurée : choisir un contact conserve son nom avec le message, donc un message rédigé avec le nom du destinataire part bien personnalisé.

Dans le détail d'une campagne, chaque destinataire affiche désormais le nom du contact à côté du numéro. Vous voyez d'un coup d'œil à qui un message est parti, sans retourner dans votre répertoire.

• Recherche par nom : vous pouvez retrouver un destinataire par son nom autant que par son numéro, sans avoir à l'écrire en entier. La recherche par numéro fonctionne exactement comme avant.
• Pas de nom pour certains destinataires : les numéros saisis à la main, et les campagnes envoyées avant cette évolution, n'affichent que le numéro.

Une campagne peut désormais se répéter. Vous la programmez une fois et elle repart d'elle-même : chaque jour, les jours de la semaine que vous choisissez, ou les jours du mois que vous choisissez.

• Rythme : chaque jour, un ou plusieurs jours de la semaine, un ou plusieurs jours du mois, dernier jour du mois compris. Une heure d'envoi, exacte au quart d'heure près.
• Chaque envoi est une vraie campagne : il apparaît dans votre historique avec son coût, ses statuts de livraison et ses numéros. Une intégration qui lit vos campagnes ou vos messages les voit comme les autres, sans rien changer.
• Rien n'est réservé à l'avance : aucun crédit n'est immobilisé à la création. Chaque échéance vérifie le solde au moment de partir.
• Solde insuffisant ou audience vide : l'échéance ne part pas, vous recevez un email, et la récurrence reste signalée dans l'interface jusqu'à ce qu'un envoi réussisse.
• Arrêt et reprise : une récurrence s'arrête et se relance à tout moment. Les échéances manquées ne sont jamais rattrapées : elle reprend à la suivante.
• Le message et les groupes restent modifiables : sans recréer la récurrence.

Un module d'automatisations rejoint le dashboard. Vous décrivez un parcours sous forme de blocs reliés, et la plateforme l'exécute pour chaque contact (ou chaque enregistrement) concerné, sans intervention de votre part.

• Quatre familles de déclencheurs : un contact créé, modifié, ajouté à un groupe ou retiré d'un groupe ; une date atteinte ; un enregistrement lu dans votre propre API ; un message livré, un message en échec, ou une réponse reçue.
• Des blocs qui s'enchaînent : condition, attente (pendant une durée ou jusqu'à une date), envoi d'un message SMS, WhatsApp ou email, enregistrement du contact, ajout ou retrait d'un groupe, variable, appel d'une URL.
• Votre API devient un déclencheur : le déclencheur de lecture interroge une adresse GET publique que vous exposez et qui renvoie du JSON, à l'intervalle que vous choisissez (30 secondes minimum) ou selon un calendrier. Vous associez les champs de vos enregistrements aux variables du parcours, avec normalisation des numéros, lecture des dates et valeurs par défaut au passage. La pagination est prise en charge : numéro de page, décalage, curseur, ou adresse next.
• Vos systèmes sont appelés : le bloc d'appel permet à un parcours de notifier votre application à l'étape exacte que vous voulez, avec les variables collectées jusque-là.
• Rien ne change pour vos intégrations : le module se pilote depuis le dashboard. Vos SID et Secret Token ne sont pas concernés, et aucun appel existant ne se comporte différemment.

Le dashboard applique désormais une Content Security Policy. Le navigateur reçoit la liste exacte des origines auxquelles l'application a le droit de s'adresser, et refuse tout le reste : un script injecté dans la page ne peut plus charger son propre code ni envoyer vos données vers une adresse extérieure.

• Rien ne change pour l'API : ces en-têtes ne concernent que le navigateur. Les appels de serveur à serveur, vos SID et Secret Token, et vos intégrations existantes ne sont pas touchés.
• Plus d'intégration en cadre : le dashboard ne peut plus être affiché dans une frame sur un autre site, ce qui ferme la porte au clickjacking.
• Exfiltration bloquée : les connexions et les envois de formulaire sont limités à Nimba SMS et aux quelques services dont l'interface a réellement besoin.
• Caméra, micro et localisation refusés : l'interface n'en a jamais besoin, le navigateur les refuse d'emblée.
• Extensions de navigateur : une extension qui injecte du code dans la page peut faire apparaître des messages dans la console. C'est la politique qui joue son rôle, sans conséquence sur votre compte.

Un même compte peut désormais détenir plusieurs organisations. Chacune est un environnement entièrement isolé, avec ses propres données et ses propres identifiants API, sans avoir à ouvrir un second compte.

• Données isolées : contacts, groupes, campagnes, sender names et historique des messages appartiennent à une organisation et ne sont jamais visibles depuis une autre.
• Ses propres clés API : chaque organisation créée reçoit son SID et son Secret Token. Pour qu'une intégration travaille dans une organisation, utilisez les identifiants de celle-ci.
• Ses propres crédits : chaque organisation porte son solde SMS, WhatsApp et Email, et achète ses propres crédits. Rien n'est partagé entre organisations, et une nouvelle organisation démarre à zéro.
• Membres : vous invitez des personnes dans chaque organisation séparément, avec le rôle de votre choix.
• Bascule : le sélecteur en haut de la barre latérale liste les organisations que vous détenez et celles où vous avez été invité. Cinq organisations par compte au maximum ; contactez le support pour relever cette limite.
• Rien ne change pour vos intégrations actuelles : vos SID et Secret Token existants continuent de fonctionner à l'identique, sur l'organisation d'origine de votre compte. Aucun en-tête à ajouter, aucun appel à modifier.

Une série d'ajustements qui accompagnent les organisations.

• Clés masquées par défaut : sur la page Développeur, le Secret Token et l'en-tête Authorization sont masqués ; un œil les révèle. La copie fonctionne sans rien afficher. Le Service ID reste visible : c'est un identifiant, pas un secret.
• En-tête Authorization expliqué : une mention précise qu'il s'agit de la combinaison de votre Service ID et de votre Secret Token, encodée en base64, à envoyer telle quelle.
• Un seul bouton de filtre : sur les listes de messages, d'envois API et de vérifications OTP, les trois filtres sont regroupés derrière un unique bouton Filtrer qui ouvre une fenêtre avec statut, expéditeur et période. Le bouton indique le nombre de filtres actifs.
• Barre latérale : le logo laisse la place au nom de l'organisation courante et au nombre d'organisations détenues par le compte.
• Informations personnelles : nom, entreprise, email, téléphone et mot de passe ne se modifient que depuis l'organisation d'origine, puisqu'ils appartiennent au compte et non à un espace de travail.

Vous pouvez désormais vous connecter à votre dashboard avec votre identifiant Apple, en plus de Google et LinkedIn.

• Où : un bouton Apple figure en tête de la fenêtre de connexion, aux côtés de Google et LinkedIn.
• Comptes existants : comme pour les autres fournisseurs, la connexion Apple vous rattache au compte Nimba SMS portant déjà la même adresse email. Elle ne crée pas de compte : pour en ouvrir un, passez par l'inscription classique.
• Masquer mon adresse email : si vous demandez à Apple de masquer votre adresse, il nous transmet une adresse relais (@privaterelay.appleid.com) qui ne correspond à aucun compte. Choisissez de partager votre adresse réelle, celle de votre compte Nimba SMS.
• Mot de passe inchangé : votre mot de passe reste valable. Apple est une porte d'entrée supplémentaire, pas un remplacement.

Tout SMS déjà envoyé peut être réexpédié en un clic depuis vos historiques, sans avoir à le ressaisir.

• Où : une icône de renvoi apparaît sur chaque ligne des historiques Envois individuels, Messages API et Vérifications OTP.
• SMS uniquement : le canal WhatsApp n'est pas éligible : l'historique conserve le corps rendu du message, pas le template ni ses variables, exigés par Meta.
• Contenu à l'identique : la fenêtre affiche un récapitulatif en lecture seule (expéditeur, destinataire, message). Rien n'est modifiable ; pour changer un élément, passez par un envoi classique.
• Un message neuf : le renvoi n'est pas rattaché au message d'origine : il est facturé comme un nouvel envoi et apparaît dans Envois individuels, quel que soit l'historique de départ. Sur une vérification OTP, le message est renvoyé tel quel : ni nouveau code, ni nouvelle expiration.

Nous avons intégré une gestion complète des templates WhatsApp Business directement dans le dashboard. Créez, modifiez et soumettez vos templates à Meta pour validation, puis utilisez-les dans vos campagnes.

• Création de templates : deux catégories disponibles : Marketing et Utilité, en français ou en anglais. Chaque template se compose d'un en-tête optionnel (texte simple ou média : image, vidéo, document ou localisation), d'un corps avec des variables dynamiques ({{1}}, {{2}}…), d'un pied de page optionnel, et jusqu'à 3 boutons (numéro de téléphone, lien site web ou réponse rapide).
• Aperçu en temps réel : un aperçu téléphone se met à jour à la frappe, reproduisant exactement l'affichage côté destinataire, avec substitution des variables.
• Soumission à Meta : une fois enregistré en brouillon, cliquez sur Soumettre pour envoyer le template à Meta pour examen. Le template passe alors en lecture seule jusqu'à son approbation ou rejet. Une fois approuvé, il est disponible pour les campagnes.
• Édition des templates validés : les templates avec le statut Actif ou Rejeté peuvent être modifiés et re-soumis à Meta. La catégorie et la langue sont immuables après la première soumission. Lors de la re-soumission, le template repasse en état En attente le temps que Meta le réexamine.
• Templates d'authentification : provisionnés automatiquement (un en français, un en anglais) à la validation d'un sender WhatsApp. Ils incluent le corps OTP standard et un bouton « Copier le code » optionnel, configurable depuis le dashboard.
• Synchronisation webhook : le statut du template (en attente → actif / rejeté) est mis à jour automatiquement en temps réel via les webhooks Meta, avec le motif de rejet affiché le cas échéant.

Nimba SMS dispose désormais d'un serveur MCP (Model Context Protocol) disponible à l'adresse https://mcp.nimbasms.com, permettant aux modèles d'IA (Claude, Cursor, etc.) d'interagir directement avec votre compte : envoyer des SMS, gérer vos contacts et plus encore. La configuration prête à l'emploi peut être copiée depuis le menu API Keys de votre dashboard.

La longueur maximale du champ message a été portée de 5 à 7 parties SMS, permettant jusqu'à 1071 caractères (7 × 153 caractères pour les messages multi-parties GSM-7bit). Cela s'applique aux endpoints messages, campagnes et notifications.

La documentation développeur est désormais disponible en français et en anglais. Vous pouvez changer de langue depuis la barre de navigation en haut. Le schéma OpenAPI, les descriptions d’opérations, paramètres et exemples de réponses sont traduits selon la langue choisie. Les réponses du schéma sont servies sans cache pour que le changement de langue soit pris en compte immédiatement.

Ajout du champ message_cost dans les réponses API des messages et des vérifications. Ce champ en lecture seule indique le nombre de SMS consommés (longueur du message en nombre de SMS × nombre de destinataires pour les messages, ou 1 pour les vérifications). Il permet de suivre la consommation directement depuis la réponse API.