Skip to main content
Webhook envoie les notifications DGrid à votre récepteur. Il fonctionne indépendamment de l’e-mail lié ; aucune adresse e-mail n’est requise. Consultez Notifications pour l’e-mail et Lark. Ce guide concerne un récepteur HTTPS personnalisé.

Configurer Webhook

  1. Saisissez l’adresse du récepteur. Enregistrez dans DGrid une URL HTTPS publique fournie par vous ou votre équipe technique.
  2. Activez Webhook.
  3. Récupérez votre Signing Secret. Cliquez sur Rotate Secret, copiez le secret de manière sécurisée et configurez votre récepteur. Gardez-le privé. Chaque rotation génère un nouveau secret ; conservez l’ancienne clé jusqu’à la fin des livraisons en attente.
  4. Choisissez les événements. Activez les types souhaités.
  5. Testez les notifications. Vérifiez que le récepteur accepte la notification et valide sa signature.

Événements disponibles

Les six événements suivants sont disponibles dans les paramètres Webhook. Utilisez le champ eventType au niveau supérieur pour les identifier, en conservant exactement la casse, les points et les underscores. Les soldes rechargé et d’abonnement sont distincts. L’alerte de solde d’abonnement faible est envoyée au plus une fois par abonnement et par mois UTC. Il n’existe pas d’événement distinct de solde d’abonnement épuisé. L’échec Auto Deposit désigne une tentative réellement échouée, pas un avertissement de fonds ou d’autorisation avant une tentative.

Requête entrante

DGrid envoie un HTTP POST à l’URL enregistrée avec Content-Type: application/json. Chaque notification utilise la même structure externe :

Données des événements

Les exemples suivants remplacent uniquement data dans la structure commune. Les identifiants, dates et soldes sont des exemples.

Solde rechargé faible : balance.low

Solde rechargé épuisé : balance.depleted

Pour ces deux événements, eventType est une chaîne et test un booléen. balance est une chaîne décimale signée en USD, éventuellement nulle ou négative. Elle représente le solde rechargé, hors allocation d’abonnement. Préservez la précision sans conversion en virgule flottante ni application des règles d’arrondi ou de troncature de l’e-mail.

Auto Deposit terminé : auto_recharge.succeeded

Auto Deposit échoué : auto_recharge.failed

Les trois champs sont des chaînes. attemptId identifie la tentative ; state vaut respectivement confirmed ou failed ; occurredAt est l’heure de l’événement au format UTC RFC 3339, avec éventuellement des fractions de seconde. Seuls ces trois champs sont présents : aucun eventType ou test interne, montant, hash de transaction, portefeuille ou motif d’échec.

Abonnement actif : subscription.activated

sourceId est l’UUID de l’abonnement.

Solde d’abonnement faible : subscription.balance_low

sourceId combine l’UUID et le mois UTC au format <subscription UUID>:YYYY-MM. Les trois champs d’abonnement sont des chaînes ; occurredAt est un horodatage UTC RFC 3339. Ils ne contiennent ni nom de formule, ni dates d’abonnement, ni quota, ni pourcentage, ni portefeuille. Ne supposez pas qu’ils incluent les détails de l’e-mail.

Notifications de test

Les tests ont test: true au niveau supérieur. Chaque événement utilise la même structure de test à trois champs ; data.eventType correspond à l’événement choisi et au eventType externe. Exemple pour Auto Deposit terminé :
Vérifiez la signature et accusez réception normalement, mais examinez le test externe avant de valider le schéma réel ou de traiter des données métier. Les tests n’ont pas de champs réels tels que attemptId ou sourceId. Un balance vide ne signifie pas zéro. N’utilisez pas un test pour modifier des soldes, enregistrer un dépôt ou activer un abonnement.

Vérifier la signature

Chaque requête contient quatre en-têtes : Les noms d’en-têtes sont insensibles à la casse. Aucun en-tête séparé n’indique la version de la clé. Le Signing Secret affiché par Rotate Secret est l’encodage base64url sans padding d’une clé de 32 octets. Décodez-le en octets avant de calculer le HMAC ; n’utilisez pas le texte affiché directement comme clé.
Préservez les octets exacts du corps brut. Vérifiez la signature avant de parser le JSON. Parser puis sérialiser le JSON peut modifier les octets et invalider la vérification. Comparez la signature attendue et DGrid-Signature en temps constant. Exigez la version v1. Une fenêtre d’horodatage de cinq minutes est recommandée pour limiter le rejeu ; synchronisez l’horloge du récepteur. Après vérification, parsez le JSON et vérifiez que DGrid-Event-Id correspond à id.

Répondre aux livraisons

Acceptez durablement la notification vérifiée, puis renvoyez un HTTP 2xx en moins de cinq secondes. Par exemple, persistez-la dans une file et renvoyez :
Aucun corps JSON ni enveloppe n’est nécessaire. DGrid utilise le statut HTTP pour déterminer l’acceptation : même un HTTP 200 dont le JSON indique une erreur compte comme accepté. Les réponses non 2xx, erreurs réseau et délais dépassés déclenchent de nouvelles tentatives, jusqu’à cinq tentatives au total, première incluse. Les redirections ne sont pas suivies. Effectuez les traitements longs après l’acceptation durable. Les livraisons peuvent être dupliquées et leur ordre n’est pas garanti. Dédupliquez avec le id externe, stable lors des nouvelles tentatives. Répondez 2xx à un doublon déjà accepté sans reproduire ses effets métier. Les horodatages, signatures et octets bruts peuvent changer ; ne les utilisez pas, ni createdAt, pour dédupliquer ou établir l’ordre des événements métier.

Changement d’URL, rotation du secret et désactivation

Les livraisons en attente conservent l’URL et la clé utilisées à leur mise en file. Après un changement d’URL ou de secret, maintenez l’ancien récepteur accessible et conservez l’ancienne clé de vérification jusqu’à la fin de ces livraisons. Désactiver Webhook n’annule pas les livraisons déjà en attente. Votre récepteur peut encore les recevoir et doit les traiter.