DEV Community

Cover image for Comment Envoyer des SMS et Messages WhatsApp Plus Rapidement avec l'API Sent.dm ?
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Comment Envoyer des SMS et Messages WhatsApp Plus Rapidement avec l'API Sent.dm ?

TL;DR / Réponse rapide

L'API Sent.dm fournit un point d'intégration unique pour la messagerie d'entreprise via SMS et WhatsApp. En combinant Sent avec Apidog, vous pouvez stocker vos identifiants dans des environnements sécurisés, tester vos requêtes sans scripts jetables, valider les payloads des webhooks et documenter l'ensemble de votre workflow de messagerie au même endroit.

Essayez Apidog dès aujourd'hui

Introduction

La plupart des projets de messagerie échouent sur les détails opérationnels : gestion des clés API, identité d’expéditeur, modèles, sécurité des webhooks, règles de canal, et surtout, la difficulté de tester tout ça sans envoyer de vrais messages à l’aveugle.

Sent.dm se positionne comme une API de messagerie unifiée pour SMS et WhatsApp, offrant une logique de routage et de délivrabilité derrière une interface unique. Selon la documentation publique de Sent (consultée le 26 mars 2026), la plateforme gère la vérification de compte, la configuration des canaux, l’envoi basé sur les modèles, les contacts, les webhooks et propose un dashboard dédié aux tests.

💡 Si vous cherchez à simplifier cette configuration, Apidog est un excellent complément. Importez la référence API Sent, créez des environnements réutilisables pour x-api-key et x-sender-id, montez des scénarios de test autour de la création de messages et de la gestion des webhooks, puis partagez votre collection avec votre équipe.

Ce que l'API Sent.dm résout

Sent.dm cible les équipes souhaitant toucher leurs utilisateurs sur plusieurs canaux de messagerie sans maintenir plusieurs intégrations. Plutôt que de gérer séparément API SMS, intégration WhatsApp, formats de payload propres à chaque canal et monitoring de la délivrabilité, Sent abstrait cette complexité en une plateforme unique.

image-255

D’après la documentation officielle, la promesse est d’offrir :

  • Une URL API unique pour tous les workflows de messagerie
  • Authentification simple via l’en-tête x-api-key
  • Un modèle d'identité d'expéditeur (x-sender-id)
  • Envoi de messages basé sur des modèles
  • Gestion des contacts/audience
  • Webhooks pour les événements de livraison et de modèle
  • Routage intelligent et basculement intégrés

En pratique, la complexité ne s’arrête pas à l’envoi d’un texte. Il faut une structure de payload cohérente, une réutilisation sécurisée des modèles, le suivi fin des événements, un workflow de test qui protège vos secrets, et une documentation réellement exploitable par l’équipe.

Défi typique :

Application -> Message API -> Channel Rules -> Delivery Events -> Retry / Status Logic
Enter fullscreen mode Exit fullscreen mode

Si chaque brique est isolée dans un outil différent, déboguer devient un cauchemar. Modéliser l’ensemble du flux dans une plateforme API comme Apidog dès le début évite ces écueils.

Comment fonctionne l’API Sent.dm

Sent agit comme une couche middleware intelligente entre votre app et les canaux de messagerie. Votre application envoie une seule requête, Sent choisit le meilleur chemin de livraison selon la logique métier, le contexte du destinataire et la disponibilité des canaux.

1. Configuration du compte et conformité

Le parcours officiel commence par la création de compte, la vérification KYC et la configuration d'entreprise. Obligatoire pour des raisons de conformité et de réputation d’expéditeur.

2. Configuration du canal

Vous choisissez un numéro de téléphone et connectez WhatsApp Business. Sent recommande d’utiliser le même numéro pour SMS et WhatsApp pour une identité de marque cohérente.

3. Modèles

Indispensables au workflow. Avant tout envoi, créez un modèle. Sent met la messagerie basée sur les modèles au cœur de l’intégration.

4. Identifiants API

Les deux identifiants clés sont :

x-sender-id: YOUR_SENDER_ID
x-api-key: YOUR_API_KEY
Enter fullscreen mode Exit fullscreen mode

Vérifiez la compatibilité des en-têtes avec la version du point de terminaison (v2/v3) de votre espace Sent.

5. Requête de message

Guide de démarrage :

POST https://api.sent.dm/v2/messages/phone
Enter fullscreen mode Exit fullscreen mode

Payload JSON :

{
  "phoneNumber": "RECIPIENT_PHONE_NUMBER",
  "templateId": "TEMPLATE_ID"
}
Enter fullscreen mode Exit fullscreen mode

À retenir : Ne cherchez pas à construire une usine à gaz omnicanale d’entrée de jeu. Commencez par l’envoi basé sur les modèles, validez le comportement, puis seulement élargissez.

Envoyez votre première requête API Sent.dm

Passons à la pratique.

Exemple cURL 

curl -X POST "https://api.sent.dm/v2/messages/phone" \
  -H "x-sender-id: YOUR_SENDER_ID" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "phoneNumber": "RECIPIENT_PHONE_NUMBER",
    "templateId": "TEMPLATE_ID"
  }'
Enter fullscreen mode Exit fullscreen mode

Exemple JavaScript 

const response = await fetch("https://api.sent.dm/v2/messages/phone", {
  method: "POST",
  headers: {
    "x-sender-id": process.env.SENT_SENDER_ID,
    "x-api-key": process.env.SENT_API_KEY,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    phoneNumber: process.env.TEST_PHONE_NUMBER,
    templateId: process.env.SENT_TEMPLATE_ID
  })
});

if (!response.ok) {
  throw new Error(`Sent request failed: ${response.status}`);
}

const data = await response.json();
console.log(data);
Enter fullscreen mode Exit fullscreen mode

Exemple Python 

import os
import requests

response = requests.post(
    "https://api.sent.dm/v2/messages/phone",
    headers={
        "x-sender-id": os.environ["SENT_SENDER_ID"],
        "x-api-key": os.environ["SENT_API_KEY"],
        "Content-Type": "application/json",
    },
    json={
        "phoneNumber": os.environ["TEST_PHONE_NUMBER"],
        "templateId": os.environ["SENT_TEMPLATE_ID"],
    },
    timeout=30,
)

response.raise_for_status()
print(response.json())
Enter fullscreen mode Exit fullscreen mode

Une réponse réussie retournera un code HTTP 200 et un messageId. Capturez ce messageId dans vos tests Apidog, logs applicatifs, workflows de support et gestion des webhooks.

Testez l’API Sent.dm dans Apidog

Apidog va au-delà de l’exécution de requêtes : il centralise la requête, les variables, les assertions, la documentation, et le partage d’équipe.

image-256

Étape 1 : Créez un environnement Sent

Dans Apidog, définissez les variables d’environnement :

base_url = https://api.sent.dm
sender_id = YOUR_SENDER_ID
api_key = YOUR_API_KEY
template_id = YOUR_TEMPLATE_ID
test_phone = RECIPIENT_PHONE_NUMBER
Enter fullscreen mode Exit fullscreen mode

Avantages :

  1. Pas de secrets codés en dur.
  2. Changement rapide entre sandbox, staging, production.
  3. Partage facile de la collection, chacun avec ses propres credentials.

Étape 2 : Créez la requête une seule fois

Dans Apidog, créez une requête :

  • Méthode : POST
  • URL : {{base_url}}/v2/messages/phone
  • Headers :
    • x-sender-id: {{sender_id}}
    • x-api-key: {{api_key}}
    • Content-Type: application/json
  • Body : 
{
  "phoneNumber": "{{test_phone}}",
  "templateId": "{{template_id}}"
}
Enter fullscreen mode Exit fullscreen mode

Votre équipe visualise la structure exacte du payload, l’authentification et la réponse attendue, tout au même endroit.

Étape 3 : Ajoutez des assertions

Ajoutez des tests dans Apidog pour valider le succès.

pm.test("Status is 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Response contains a messageId", function () {
  const json = pm.response.json();
  pm.expect(json.messageId).to.exist;
});
Enter fullscreen mode Exit fullscreen mode

Repérez immédiatement les régressions (perte de messageId, erreur d’authentification, etc).

Étape 4 : Transformez-le en scénario

Construisez un workflow multi-étapes :

  1. Envoyer un message
  2. Stocker le messageId
  3. Interroger le statut si dispo
  4. Comparer avec les événements webhook reçus

Ce niveau de test API est indispensable pour les systèmes de messagerie.

Étape 5 : Ajoutez des exemples de webhook à la collection

Après avoir validé l’envoi, ajoutez des exemples d’événements webhook pour couvrir tout le cycle.

{
  "field": "message.status",
  "messageId": "msg_123",
  "status": "delivered",
  "channel": "whatsapp"
}
Enter fullscreen mode Exit fullscreen mode

Backend, QA et support peuvent ainsi travailler sur des exemples communs, facilitant la validation et la compréhension du cycle de vie des messages.

Étape 6 : Publiez des documents internes

Avec Apidog, documentez et partagez :

  • En-têtes requis
  • Payloads d’exemple
  • Réponses d’erreur
  • Événements webhook
  • Notes d’environnement

Vous facilitez ainsi l’onboarding de nouveaux membres ou la validation QA sans scripts obscurs.

Gérez les modèles, les contacts et les webhooks correctement

Obtenir un premier 200 n’est qu’un début. La gestion en production demande plus de rigueur.

Modèles

Les modèles doivent être versionnés, étiquetés par usage, locale et statut d’approbation. Séparez test et production, documentez l’association modèle/parcours utilisateur. Conservez un exemple par modèle dans Apidog.

Contacts

Même si vos utilisateurs sont déjà stockés côté app, créez des objets contact dans Sent pour :

  • Opérations audience
  • Ciblage de modèles
  • Historique des communications

Documentez : source de vérité, normalisation des numéros, gestion du consentement, changement de canal.

Webhooks

Sent fournit une sécurité HMAC-SHA256 via :

  • x-webhook-signature
  • x-webhook-id
  • x-webhook-timestamp

Format : v1,{base64_signature}. Protection contre les replays (fenêtre de 5 minutes).

Checklist :

  1. Lisez le corps brut
  2. Vérifiez la signature avant parsing
  3. Refusez les timestamps obsolètes
  4. Idempotence des traitements
  5. Accusez réception rapidement, déléguez les tâches lourdes en asynchrone

Exemple Express :

import crypto from "crypto";
import express from "express";

const app = express();

app.post("/webhooks/sent", express.raw({ type: "*/*" }), (req, res) => {
  const signature = req.header("x-webhook-signature");
  const webhookId = req.header("x-webhook-id");
  const timestamp = req.header("x-webhook-timestamp");
  const secret = process.env.SENT_WEBHOOK_SECRET;
  const rawBody = req.body.toString("utf8");

  const signedContent = `${webhookId}.${timestamp}.${rawBody}`;
  const expected = crypto
    .createHmac("sha256", Buffer.from(secret.replace(/^whsec_/, ""), "base64"))
    .update(signedContent)
    .digest("base64");

  if (signature !== `v1,${expected}`) {
    return res.status(401).send("Unauthorized");
  }

  const event = JSON.parse(rawBody);
  console.log("Received webhook event:", event.field);

  return res.sendStatus(200);
});
Enter fullscreen mode Exit fullscreen mode

Stockez des exemples de payloads webhook dans Apidog et documentez-les pour une gestion d’équipe efficace.

Pourquoi Apidog convient à ce workflow

Sent.dm fournit la couche de messagerie. Apidog fournit la couche de workflow, de test, de documentation et de collaboration.

Tâche Sent.dm Apidog
Envoyer SMS/WhatsApp Oui Non (mais teste l’API qui le fait)
Gérer modèles/config expéditeur Oui Documente et valide les requêtes associées
Tester les requêtes authentifiées Basique via le playground Générateur de requêtes puissant, environnements, assertions, scénarios
Partager la doc API avec l’équipe Documents de la plateforme Collections collaboratives et doc générée
Déboguer le flux requête/réponse Partiel Inspection répétable, collaboration
Scénarios de test de bout en bout Axé messagerie Meilleur pour les workflows API multi-étapes

Pour les équipes, Apidog couvre la conception collaborative, les tests, le débogage, la planification de maquettes et la doc dans un espace unique.

Exemples d’utilisation :

  • Onboarding de plusieurs développeurs via une collection de requêtes partageable
  • Validation QA sans scripts maison
  • Tests reproductibles pour les changements de version, nouveaux modèles ou payloads webhooks

Téléchargez Apidog gratuitement pour tester vos requêtes Sent.dm, stocker vos environnements et transformer votre premier appel API en workflow d’équipe réutilisable.

Conseils avancés et erreurs courantes

Pour fiabiliser votre intégration :

Meilleures pratiques

  1. Gardez les identifiants uniquement côté serveur (jamais dans le frontend)
  2. Suivez le messageId dans vos logs/supports
  3. Séparez modèles de staging et prod
  4. Vérifiez chaque webhook avant traitement
  5. Utilisez des environnements Apidog distincts pour chaque contexte

Erreurs courantes à éviter

  1. Considérer un 200 comme une livraison finale (ce n’est que le début)
  2. Coder en dur les IDs de modèle
  3. Négliger l’identité d’expéditeur jusqu’au dernier moment
  4. Mal normaliser les numéros de téléphone
  5. Tester avec de vrais identifiants dans des scripts isolés

Conseils de dépannage

En cas d’échec de requête, vérifiez :

  1. La x-api-key est-elle valide et active ?
  2. Le point de terminaison correspond-il à la version attendue ?
  3. x-sender-id est-il requis sur ce chemin ?
  4. Le modèle est-il approuvé et disponible ?
  5. Le numéro de téléphone est-il au bon format ?

Apidog permet de comparer instantanément une requête qui échoue avec une version connue comme fonctionnelle.

Alternatives et comparaisons à Sent.dm

Vous comparez peut-être Sent.dm à :

Option Force Compromis
Fournisseurs directs Contrôle granulaire Plus de maintenance/intégration
Plateforme Twilio Écosystème large Orchestration multicanal + complexité accrue
Sent.dm Messagerie unifiée, abstraction des canaux Dépendance conventions/structure de docs Sent
Sent.dm + Postman Tests de requêtes familiers Documentation et collaboration API plus fragmentées
Sent.dm + Apidog Messagerie unifiée + tests/collab API Deux outils à gérer

La meilleure configuration ? Plateforme de livraison + couche de test/collaboration API robuste. Si vous utilisez déjà Postman, la valeur d’Apidog réside dans les environnements, la documentation consolidée, les assertions, la planification de maquettes et le partage d’équipe.

Conclusion

Sent.dm centralise la messagerie SMS et WhatsApp. Son vrai atout : permettre de tester et structurer les modèles, l’identité d’expéditeur, les contacts et les webhooks.

Pour accélérer, commencez par écrire votre première requête Sent dans Apidog, ajoutez des assertions messageId, puis documentez vos webhooks dans le même espace. Vous disposerez ainsi d’un workflow reproductible, maintenable, et partageable, loin des scripts dispersés et des connaissances informelles.

FAQ

À quoi sert l’API Sent.dm ?

Pour la messagerie d’entreprise sur SMS et WhatsApp via une intégration unique. Elle gère l’expéditeur, les modèles, les contacts et les webhooks.

Sent.dm prend-il en charge WhatsApp et SMS dans une seule API ?

Oui. La plateforme abstrait la complexité multicanale derrière une seule API. Utilisez de préférence le même numéro pour tous les canaux.

Quels en-têtes sont nécessaires pour les requêtes API Sent.dm ?

x-api-key (authentification principale) et souvent x-sender-id. Vérifiez la version exacte du point de terminaison (v2/v3) avant déploiement.

Ai-je besoin de modèles pour envoyer des messages avec Sent.dm ?

Oui, à l’intégration. Créez un modèle puis utilisez son templateId pour envoyer le premier message.

Comment tester l’API Sent.dm sans scripts personnalisés ?

Avec Apidog : stockez vos identifiants comme variables d’environnement, enregistrez des requêtes, ajoutez des assertions, montez des scénarios, documentez les payloads webhooks et publiez la doc API interne.

Comment sécuriser les webhooks Sent.dm ?

Vérifiez la signature HMAC, validez l’horodatage, traitez les événements de façon idempotente. Les en-têtes à vérifier : x-webhook-signature, x-webhook-id, x-webhook-timestamp.

Sent.dm suffit-il seul pour les workflows API d’équipe ?

Il couvre la messagerie, mais il vous faut un outil collaboratif pour les tests, la documentation et la validation continue. C’est là qu’Apidog entre en jeu.

Top comments (0)