AnchorDes webhooks immobiliers pour recevoir les mises à jour sans polling continu

Les webhooks transmettent des notifications d’annonces et des exports à votre receiver HTTP. Ils réduisent le polling, mais ne remplacent pas les contrôles d’idempotence et de réconciliation de votre intégration.

AnchorRecevoir les livraisons de façon fiable

Un service classified-notification-single ou classified-notification-batch, avec onlyNew=false, livre les mises à jour en direct, tandis que classified-export livre les exports. Ces modes sont distincts : ne déduisez pas le contrat d’un service à partir d’un autre.

Les livraisons peuvent être répétées et arriver dans un ordre différent. Avant de répondre 2xx, votre application enregistre durablement le corps complet et la paire X-Immoteur-Service-Id / X-Immoteur-Event-Id dans sa propre file. Un worker traite ensuite cette file et met à jour votre base ou votre CRM, sans bloquer l’accusé de réception HTTP sur ce travail potentiellement lent.

AnchorComment Immoteur s'intègre à votre flux de travail

Utilisez les identifiants du service et de l’événement comme clé d’unicité afin de reconnaître un réessai et de ne pas traiter deux fois le même événement. X-Immoteur-Delivery-Id identifie une tentative HTTP : il sert au diagnostic, pas à dédupliquer un événement.

Si votre worker consolide les annonces par identifiant, il doit comparer la fraîcheur des données source, par exemple meta.lastModifiedAt, avant d’écraser une valeur existante. Une livraison arrivée en dernier ne contient pas nécessairement la version la plus récente.

Pour une base locale, associez les notifications à des exports de réconciliation. La file persistante, le worker et les systèmes en aval restent sous la responsabilité de votre équipe.

AnchorCommencez avec les données dont vous avez besoin

Le guide de livraison des webhooks décrit le receiver, les en-têtes et les réessais. Configurez ensuite le bon service dans la documentation des webhooks.

Créer un compte Immoteur

Schéma d’une file persistante gérée par le client : une livraison d’annonce, son réessai et une arrivée tardive sont enregistrés avant la réponse 2xx. Un worker asynchrone les déduplique par service et événement, puis met à jour l’annonce correspondante dans le CRM. — File et CRM gérés par le client
Votre application enregistre le message avant de répondre, puis un worker met le CRM à jour.
Votre application enregistre durablement chaque événement avec `X-Immoteur-Service-Id` et `X-Immoteur-Event-Id` dans sa propre file, puis renvoie `2xx`. Un worker déduplique les réessais avec cette paire et met ensuite la base ou le CRM à jour. Lorsqu’il consolide une annonce par identifiant, il compare la fraîcheur des données source, par exemple `meta.lastModifiedAt`, afin qu’une livraison tardive ne remplace pas une version plus récente.