Présentation des webhooks
Lisoloo livre les mises à jour de statut de façon asynchrone à une URL que vous configurez sur votre clé API. Chaque événement est un seul POST HTTP avec un corps JSON et les identifiants HTTP Basic optionnels que vous avez définis.
Pourquoi les webhooks
Section intitulée « Pourquoi les webhooks »Pour tout envoi de plus que quelques destinataires, interroger
GET /status/{message_id} est le mauvais outil — cela brûle votre
limite de débit 120 lectures/minute et ajoute de la latence. Les
webhooks poussent l’état final directement vers votre serveur, en
temps réel, gratuitement (aucun coût supplémentaire de limite de
débit chez vous).
┌──────────────┐ webhook POST ┌────────────────┐ POST /send ─▶ │ Lisoloo API │ ──────────────▶ │ Votre endpoint │ └──────────────┘ à chaque event └────────────────┘ │ └─ transitions de statut internes : pending → processing → sent → deliveredSémantique de livraison
Section intitulée « Sémantique de livraison »- Méthode HTTP :
POST. - Content-Type :
application/json. - Corps : un seul objet événement (voir Types d’événements).
- Authentification : HTTP Basic avec les identifiants configurés sur votre clé API, si définis. Pas de signature HMAC aujourd’hui.
- Relances : jusqu’à 4 tentatives sur les réponses
5xxou les échecs de connexion, avec backoff exponentiel30s → 2m → 10m → 1h. Après 4 échecs l’événement est abandonné. - Ordre : pas garanti. Un événement
sms.deliveredpour un destinataire peut arriver avant l’événementsms.sentpour un autre du même lot. Utilisezrecipient_phonepour corréler ; basez- vous sur l’état faisant autorité dansGET /statussi l’ordre compte. - Idempotence : chaque événement a un
event_id(UUID v4). Votre endpoint doit être idempotent — un replay avec le mêmeevent_iddoit être un no-op.
Configurer un webhook
Section intitulée « Configurer un webhook »La configuration de webhook vit sur la clé API, pas sur le compte marchand. Vous la configurez dans le portail développeur :
- Ouvrez Bloonio → Lisoloo → Developer → Clés API.
- Déroulez vers Configuration webhook.
- Définissez
webhook_urlà un endpoint HTTPS sur votre serveur. - (Optionnel mais recommandé) définissez
webhook_basic_auth_usernameetwebhook_basic_auth_password. La passerelle utilisera ceux-ci pour l’auth HTTP Basic sur chaque POST. - Enregistrez.
La visite guidée complète — y compris le champ mot de passe write-only et l’indicateur « Basic auth configured » — est à Webhooks → Configuration.
Ce que vous recevrez
Section intitulée « Ce que vous recevrez »Chaque événement a la même enveloppe extérieure :
{ "event_id": "f8a3b7c1-2e4d-4a9b-9d8f-7c6e5b4a3d2c", "event_type": "sms.delivered", "timestamp": "2026-05-27T10:15:08Z", "message_id": "507f1f77bcf86cd799439011", "data": { ...charge utile spécifique à l'événement... }}Les valeurs event_type et les formes data par événement sont
documentées à Types d’événements webhook.
Ce que vous devez renvoyer
Section intitulée « Ce que vous devez renvoyer »Un statut 2xx (200, 201 ou 204) acquitte l’événement. Le corps
est ignoré. Tout 4xx est traité comme un échec permanent
(l’événement ne sera pas retenté — typiquement utilisé pour refuser
les événements mal routés). Tout 5xx ou erreur de connexion
déclenche la séquence de relance.
HTTP/1.1 204 No ContentVisez à répondre en moins de 5 secondes. Les acks au-delà de 5
secondes sont traités comme un timeout et déclenchent une relance. Si
votre traitement est lent, acceptez d’abord et traitez en async —
poussez l’événement dans une file et renvoyez 204 immédiatement.
Tester les webhooks en local
Section intitulée « Tester les webhooks en local »webhook.site et smee.io exposent tous deux une URL publique qui forwarde vers votre poste. Utile pour l’intégration précoce ; pour le routage de production utilisez votre propre domaine avec TLS.
Pour les tests unitaires, le sandbox webhook_url accepte n’importe
quelle URL HTTPS — déclenchez un sandbox POST /send contre une URL
webhook.site et voyez les événements arriver en quelques secondes.