Les événements webhook disponibles
Prérequis : l’option Webhooks sur votre compte et un point de terminaison déclaré. L’authentification, la signature et les tentatives sont traitées dans Configurer un endpoint webhook ; cette page ne décrit que le contenu des appels.
Les événements webhook disponibles
Prérequis : l’option Webhooks sur votre compte et un point de terminaison déclaré. L’authentification, la signature et les tentatives sont traitées dans Configurer un endpoint webhook ; cette page ne décrit que le contenu des appels.
Ce qui est émis
Un seul événement part réellement vers votre point de terminaison : certificate_completed, envoyé
quand une attribution de certificat est enregistrée. Le formulaire en propose un second,
certificate_expired, qu’aucun traitement n’émet. Dans le back-office, la section Event Types
affiche les deux sous forme d’étiquettes cliquables, certificate completed et certificate
expired ; sélectionner la seconde reste sans effet, sans erreur ni avertissement.
Les trois chemins qui déclenchent certificate_completed
Un apprenant remplit la règle d’un certificat. Le cas courant, en temps réel, au moment où son activité satisfait la règle. Seules les règles de type certificat émettent : les badges de gamification ne déclenchent aucun appel.
Un certificat dépasse sa date d’expiration. Un traitement s’exécute toutes les heures, relève les attributions échues, envoie l’e-mail de rappel, puis émet un appel. Ce chemin est étroitement délimité : il ne concerne que les certificats par capsule, dotés d’une durée de validité et dont le rappel d’expiration est activé. Un certificat par compétence n’y entre jamais, même s’il expire. L’appel ne part qu’une fois par attribution : elle est marquée comme rappelée et ne repasse plus.
Beedeez lance une passe de rattrapage sur un certificat, pour attribuer ce qui manque aux apprenants éligibles. Un appel par attribution créée.
Le contenu de l’appel
Le corps est l’attribution de certificat elle-même, relue en base au moment de l’envoi, en JSON et sans enveloppe : ni nom d’événement, ni horodatage d’émission, ni identifiant de livraison. Les champs suivants sont présents sur toute attribution créée par le produit :
| Champ | Type | Contenu |
|---|---|---|
_id | identifiant | L’attribution ; stable, utilisable comme clé d’idempotence |
_userId, _badgeId, _ownerId | identifiants | L’apprenant, le certificat, le compte |
name | texte | Libellé du certificat |
ruleType | texte | certifCapsule ou certifSkill |
creationDate | date | L’obtention |
expires | date ou null | null quand le certificat n’expire pas |
expiryReminderSent | booléen | true sur l’appel déclenché par l’expiration |
disabled | booléen | true si l’attribution a été créée déjà échue, ou retirée à un apprenant qui n’y a plus droit |
acknowledged | booléen | L’apprenant a vu son certificat dans l’application |
createdAt, updatedAt | dates | Écriture en base |
D’autres champs ne sont transmis que si le certificat ou la règle les a produits : description,
les traductions name_i18n et description_i18n sous la forme { lang, value }, puis score,
successRate, correctAnswersRate et _lessonActiveIds, qui liste les capsules ayant validé le
certificat. Traitez leur absence comme un cas normal.
{
"_id": "6712a9f4c3b5e10d2f8a4471",
"_ownerId": "5f2c1ab8d9e4470012a3c001",
"_userId": "66e1b0447a2c9d0011f4e882",
"_badgeId": "64c73f10ae5b220019d0a1c7",
"name": "Habilitation électrique B1V",
"ruleType": "certifCapsule",
"creationDate": "2026-03-11T09:42:18.204Z",
"expires": "2027-03-11T00:00:00.000Z",
"expiryReminderSent": false,
"disabled": false,
"acknowledged": false,
"successRate": 92,
"_lessonActiveIds": ["66f0d2213b8c4a0014ee7710"],
"createdAt": "2026-03-11T09:42:18.209Z",
"updatedAt": "2026-03-11T09:42:18.209Z"
}Le volume
Un appel par attribution et par point de terminaison abonné, sans regroupement : dix apprenants certifiés le même jour font dix appels, et une passe de rattrapage en produit autant que d’attributions créées.
Ce que ça ne fait pas
Le corps ne porte aucune donnée d’identité : ni nom, ni adresse e-mail, ni matricule, ni
appartenance à un groupe. _userId est un identifiant interne, donc écrire dans un SIRH demande un
appel à l’API. Et aucun événement n’existe sur les apprenants, capsules, parcours ou sessions.
Le piège
L’expiration arrive sous le nom certificate_completed. Un point de terminaison abonné à
certificate_completed reçoit donc les deux cas, obtention et expiration, avec le même corps.
💡 Pour les distinguer, lisez expiryReminderSent : true sur l’appel d’expiration, false sur
l’obtention. Comparer expires à l’heure courante le confirme.
Pour aller plus loin
- Configurer un endpoint webhook : l’authentification, la signature et le comportement en cas d’échec
- Validité, expiration et renouvellement : le rappel d’expiration qui commande le deuxième chemin
- Les ressources disponibles : l’API pour résoudre
_userIden apprenant réel - Automatiser l’export de l’activité vers votre SFTP : le chemin pour tout ce qu’aucun événement ne couvre