Événements
Ce que la plateforme a enregistré et les endpoints qu'elle a atteints.
Un événement est l'enregistrement par la plateforme d'une action survenue : un paiement a réussi, un transfert a échoué ou un client a été supprimé. Les livraisons de webhooks reposent sur les événements. Cette vue répond donc à la question qui précède « pourquoi mon endpoint ne s'est-il pas déclenché ? », à savoir « l'événement a-t-il seulement été créé ? ».
Eventstrx_CSUGajfv9xh0XQ5wu2lx
payment.created12:31:48.001
25,000 XAF, channel cm.mtn
route.evaluatedmomo-cm-mtn-first12:31:48.044
Rule "MoMo CM, MTN first" matched
provider.attempt.failedMTN MoMo12:31:48.901
MTN MoMo returned a 503 error
route.fallbackwaterfall12:31:49.220
Automatic waterfall fallback to next provider
provider.attempt.succeededOrange Money12:31:50.130
Payment accepted
payment.succeeded12:31:50.140
trx_CSUGajfv9xh0XQ5wu2lx, 1 940 ms over 2 attempts
Contenu d'une ligne
| Colonne | Remarque |
|---|---|
| Identifiant de l'événement | evt_ en mode live, evt_test_ dans la sandbox |
| Type | payment.succeeded et les 56 autres |
| Objet | La ressource concernée, avec son identifiant |
| Livraisons | Jusqu'à cinq tentatives récentes, chacune avec l'endpoint, le code de statut et la durée |
| En attente | Le nombre d'endpoints qui doivent encore répondre |
| Version de l'API | La version pour laquelle le payload a été construit |
La colonne des livraisons rend cette vue plus utile que la liste brute des événements de l'API : vous voyez l'événement et son résultat sur la même ligne.
Filtres
| Filtre | Élément recherché |
|---|---|
| Recherche | L'identifiant de l'événement, le type, l'identifiant de l'objet ou celui de la requête |
| Type | Un type précis, choisi parmi ceux réellement produits par votre compte |
| Catégorie | Tout ce qui se trouve sous un préfixe, par exemple tous les types payment. |
| Date de début, date de fin | Des journées calendaires entières |
| Statut de livraison | delivered signifie que rien n'est en attente, pending qu'au moins un endpoint n'a pas répondu |
Cinquante résultats par page, du plus récent au plus ancien. Le sélecteur de type repose sur votre historique. Il propose uniquement les types réellement produits. Vous repérez ainsi plus rapidement un type manquant qu'en parcourant le catalogue.
Les événements internes sont filtrés
Les lignes transaction.* contiennent des données de télémétrie sur la chronologie du checkout, utilisées au sein de la plateforme. Elles sont exclues de cette vue et ne sont jamais livrées aux endpoints.
Deux types présents uniquement ici
payment.checkout_page_opened et payment.redirected_to_callback sont enregistrés comme événements et visibles dans cette liste, mais ne sont jamais envoyés à un endpoint. Ils permettent de reconstituer un checkout après coup : le moment où le payeur a ouvert la page et son éventuel retour vers votre URL de retour.
Si un paiement n'a jamais réussi et qu'il n'existe aucun événement payment.checkout_page_opened, le payeur n'a jamais atteint la page. Le problème vient généralement du lien ou de la redirection, pas du paiement.
Relancer une livraison
La relance se trouve dans la vue voisine, Webhooks, car vous relancez une livraison vers un endpoint précis. Le quota mensuel affiché ici et dans cette vue utilise le même compteur, max_webhooks, selon votre plan.
Une relance cible tous les endpoints abonnés
Elle ne cible pas uniquement celui qui a échoué. Sur un compte avec deux endpoints, celui qui fonctionne reçoit l'événement une deuxième fois. C'est une raison supplémentaire pour que votre handler s'appuie sur l'identifiant de l'événement.
Exportation
Vous pouvez exporter les filtres actuels au format CSV ou JSON. Cette opération est décomptée du quota mensuel max_exports de votre plan.
Un exemple utile : filtrez sur delivery_status: pending pendant les sept derniers jours, puis exportez les résultats. Cette liste correspond exactement aux événements que votre intégration n'a pas fini de traiter.