Webhooks (Endpoints)
Les webhooks permettent à Sangho de notifier votre serveur en temps réel lors d’événements importants — paiement réussi, remboursement effectué, abonnement annulé, etc. Plutôt que de poller l’API, votre serveur reçoit une requête HTTP POST dès que l’événement se produit.
Chaque endpoint webhook écoute une liste d’événements configurables et dispose de son propre secret de signature HMAC-SHA256. Consultez la Référence des événements pour la liste complète des types disponibles.
Chaque requête webhook inclut un header Sangho-Signature.
Vérifiez systématiquement cette signature HMAC-SHA256 avant de traiter l’événement —
cela garantit que la requête vient bien de Sangho et non d’un tiers malveillant.
Consultez le guide de vérification de signature.
Événements disponibles
| Événement | Déclencheur |
|---|---|
payment_intent.succeeded | PaymentIntent passé en statut succeeded. |
payment_intent.failed | PaymentIntent passé en statut canceled après échec. |
transaction.succeeded | Transaction créée et complétée. |
refund.succeeded | Remboursement restitué à l'acheteur. |
refund.failed | Remboursement échoué côté opérateur. |
invoice.paid | Facture réglée. |
invoice.payment_overdue | Date d'échéance dépassée sans paiement. |
checkout.session.completed | CheckoutSession passée en statut complete. |
subscription.created | Nouvel abonnement créé. |
subscription.canceled | Abonnement annulé. |
subscription.payment_failed | Tentative de renouvellement échouée. |
customer.created | Nouveau Customer créé. |
customer.deleted | Customer supprimé. |
Endpoints
| Méthode | Endpoint | Description |
|---|---|---|
| POST | /webhooks/ | Créer un endpoint webhook |
| GET | /webhooks/ | Lister les endpoints |
| GET | /webhooks/{id}/ | Récupérer un endpoint |
| PATCH | /webhooks/{id}/ | Modifier un endpoint |
| DELETE | /webhooks/{id}/ | Supprimer un endpoint |
| POST | /webhooks/{id}/disable/ | Désactiver (suspendre les envois) |
| POST | /webhooks/{id}/enable/ | Réactiver un endpoint désactivé |
| POST | /webhooks/{id}/roll-secret/ | Régénérer le secret de signature |
| POST | /webhooks/{id}/test/ | Envoyer un événement de test |
| GET | /webhooks/{id}/deliveries/ | Logs de livraison |
| POST | /webhooks/{id}/deliveries/{did}/retry/ | Rejouer une livraison échouée |
Schéma de l’objet
Créer un endpoint webhook
Enregistre une nouvelle URL sur laquelle Sangho enverra les événements sélectionnés. Le secret de signature HMAC est retourné une seule fois à la création — stockez-le immédiatement dans votre gestionnaire de secrets.
nameRequisNom descriptif de l’endpoint. Affiché dans votre dashboard — utilisez un nom qui identifie clairement l’environnement ou l’usage.
Max 255 caractères. Un bon nom inclut l’environnement et la portée fonctionnelle,
par exemple “Production — paiements & abonnements” ou “Staging — tous événements”.
urlRequisURL de votre endpoint webhook. Doit être accessible publiquement via HTTPS. Sangho effectue un ping de validation à la création.
L’URL doit répondre avec un code HTTP 2xx dans les 10 secondes pour être validée. Pour les tests en local, utilisez un tunnel comme ngrok ou localtunnel.
eventsRequisListe des types d’événements à écouter sur cet endpoint. Utilisez [“*”] pour recevoir tous les événements.
Préférez une liste explicite plutôt que “*” pour réduire
le volume de requêtes sur votre serveur et simplifier le débogage. Chaque endpoint
peut écouter jusqu’à 50 types d’événements distincts. Consultez la référence des événements
pour la liste complète.
security_profileOptionnelMéthode de signature des requêtes webhook.
En savoir plus
Valeurs : HMAC_SHA256 (recommandé — header Sangho-Signature), JWT (token JWT
signé dans le header Authorization), BASIC (Basic Auth —
déconseillé en production). Consultez le guide de signature pour les
détails d’implémentation.
ssl_verificationOptionnelActive la vérification du certificat SSL de votre endpoint.
En savoir plus
Ne désactivez ssl_verification qu’en environnement de
développement avec un certificat auto-signé. En production, maintenez toujours
cette option à true.
retry_policyOptionnelPolitique de retry en cas d’échec de livraison (timeout, erreur 5xx).
En savoir plus
Objet avec deux champs : max_attempts (défaut : 5, max : 10)
et backoff_type (exponential ou linear, défaut : exponential). Avec
le backoff exponentiel, les retries se font à 1 min, 5 min, 30 min, 2 h, 8 h. Avec linear : toutes les 30 minutes.
metadataOptionnelDonnées libres associées à l’endpoint — environnement, équipe responsable, etc.
Le champ secret retourné à la création ne sera plus jamais
affiché. Stockez-le immédiatement dans votre gestionnaire de secrets (variable
d’environnement, Vault, AWS Secrets Manager…). Si vous le perdez, régénérez-en un
nouveau via POST /webhooks/{id}/roll-secret/.
Créer un endpoint
Vérifier la signature
À chaque envoi, Sangho calcule une signature HMAC-SHA256 du corps de la requête avec
votre secret et l’inclut dans le header Sangho-Signature.
Vous devez recalculer cette signature côté serveur et comparer avec une méthode
résistante aux timing attacks.
La signature est calculée sur le corps brut de la requête, avant tout
parsing JSON. En Express.js, configurez express.raw({ type: 'application/json' })
sur la route webhook — ne passez pas par express.json() qui
transformerait le body.
Gestion des livraisons
L’endpoint GET /webhooks/{id}/deliveries/ retourne l’historique
des tentatives de livraison pour un endpoint donné. En cas d’échec, vous pouvez rejouer
une livraison via POST /webhooks/{id}/deliveries/{did}/retry/.
Votre endpoint doit retourner un 200 dans les 10 secondes.
Pour les traitements longs (envoi d’email, appel à un service tiers), enfilez la tâche
dans une queue (Celery, Bull, Sidekiq…) et répondez immédiatement. Passé ce délai,
Sangho considère la livraison comme échouée et déclenche la politique de retry.