Skip to main content
Pour obtenir les meilleurs résultats lors du développement de flux d’événements, Auth0 recommande de suivre les bonnes pratiques ci-dessous. Ces recommandations peuvent aider à réduire les obstacles, à améliorer l’efficacité et à offrir une expérience événementielle de premier plan.

​
Utilisez des files d’attente asynchrones pour traiter les événements

À la réception d’un événement, renvoyez un code HTTP 2XX OK (p. ex., 200 OK, 202 Accepted, 204 No Content) pour indiquer que l’événement a bien été livré. Sans cette réponse, Auth0 considère la livraison de l’événement comme un échec et réessaiera conformément au comportement décrit dans Comportement du système en cas d’échec de livraison d’événements. Pour éviter les problèmes d’évolutivité, configurez votre gestionnaire pour traiter les événements entrants au moyen d’une file d’attente asynchrone. Si vous traitez les événements de façon synchrone, toute forte hausse des livraisons de webhook (par exemple, au début du mois, lorsque tous les abonnements se renouvellent) risque de surcharger les serveurs qui hébergent vos endpoints. Les files d’attente asynchrones vous permettent de traiter les événements simultanés à un rythme que votre système peut prendre en charge.

​
Ignorer les événements en double

Il peut arriver que les point de terminaison webhook reçoivent le même événement plus d’une fois. Pour éviter de traiter des événements en double, consignez les ID des événements que vous avez déjà traités.

​
Gérer les événements hors séquence

Auth0 ne garantit pas que les événements sont transmis dans le même ordre que celui dans lequel ils sont générés. Par exemple, lorsqu’un utilisateur est créé, puis immédiatement mis à jour pour qu’un autre utilisateur y soit lié, vous pourriez recevoir :
  • user.updated (for User 1)
  • user.created (for User 1)
  • user.deleted (for User 2)
  • user.updated (for User 2)
Pour éviter d’écraser vos données avec des renseignements périmés, comparez l’attribut time du webhook entrant à l’horodatage des données de votre système. L’attribut data.object dans le payload peut également comprendre les champs created_at et updated_at pour des horodatages propres à l’opération. Consultez les détails de l’événement dans le catalogue des événements pour en savoir plus.

​
Écouter certains types d’événements

Configurez vos points de terminaison webhook pour recevoir uniquement les types d’événements nécessaires à votre intégration. Recevoir des événements supplémentaires (ou tous les événements) surcharge inutilement votre serveur et n’est pas recommandé. Vous pouvez modifier les événements qu’un point de terminaison webhook reçoit en mettant à jour les flux d’événements.

​
Comportement du système lors des échecs de livraison d’événements

À l’heure actuelle, Auth0 n’autorise qu’un total de quatre tentatives, soit la tentative initiale et trois nouvelles tentatives avec temporisation exponentielle (1s, 2s, 4s). Si vous recevez un code 4XX, l’événement échoue immédiatement, sans nouvelle tentative, puisqu’un nouvel essai a peu de chances de modifier la réponse. Si votre endpoint ne répond toujours pas correctement après ce délai, l’événement est marqué comme ayant échoué, et Auth0 ne tentera plus de l’envoyer. Pour en savoir plus sur les événements en échec, consultez Tests, observabilité et reprise après échec des flux d’événements.

​
Désactiver les flux d’événements défaillants

Les flux d’événements sont automatiquement désactivés dans les cas suivants :
  • Auth0 enregistre 500 échecs d’affilée (c.-à-d. tout ce qui n’est pas un 2XX).
  • Le flux d’événements atteint un total de 5 000 livraisons en échec.
  • Auth0 enregistre trois échecs consécutifs de tentative de livraison (c.-à-d. tout ce qui n’est pas un 2XX).
    • Si vous souhaitez autoriser un plus grand nombre d’échecs de tentative de livraison, soumettez un ticket de soutien en précisant le nombre d’échecs permis, et Auth0 examinera votre demande.

​
En savoir plus