Configurer Webhook
- Saisissez l’adresse du récepteur. Enregistrez dans DGrid une URL HTTPS publique fournie par vous ou votre équipe technique.
- Activez Webhook.
- 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.
- Choisissez les événements. Activez les types souhaités.
- 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 champeventType 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 HTTPPOST à 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 uniquementdata dans la structure commune. Les identifiants, dates et soldes sont des exemples.
Solde rechargé faible : balance.low
Solde rechargé épuisé : balance.depleted
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
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 onttest: 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é :
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é.
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 HTTP2xx en moins de cinq secondes. Par exemple, persistez-la dans une file et renvoyez :
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.

