Skip to main content
Un match est l’événement métier qu’émet Fluximmo lorsqu’une advert ou une property satisfait les critères d’une alerte. Chaque match est livré au webhook de l’alerte. Le type de match indique la nature de l’événement : nouveau bien découvert, fusion, ou événement sur un bien déjà matché.

​
Match types — Adverts

​
Match types — Properties

​
Comparatif Adverts vs Properties

Si vous avez besoin d’événements granulaires (variation de prix, online/offline), utilisez les alertes Adverts. Les alertes Properties ne livrent que des notifications de découverte/fusion.

​
Events ADVERT — à dériver côté client

Le webhook ADVERT pousse les advert evolved dans data.updated[] avec un DTO minimal (flxId, currentPrice {value, valuePerArea}, isOnline). Il n’y a pas de champ event_type côté serveur — vous reconstituez l’événement par comparaison avec votre état stocké local :
Pré-requis : maintenez localement (flxId → { price, isOnline }) à jour à chaque webhook (data.created ET data.updated) pour pouvoir comparer au prochain. Sans état local, impossible de dériver les events.CHECK non émis. Les vérifications périodiques sans changement réel ne déclenchent aucun webhook — pas de bruit.

​
Pas de backfill à la création

Une alerte ne match que les annonces ingérées après sa création (createdAt). Les annonces déjà présentes dans le catalogue qui rempliraient les critères ne déclencheront pas de match. Pattern recommandé pour couvrir passé + futur :
  1. Côté PROPERTIES : POST /v2/protected/properties/search one-shot avec vos critères pour récupérer les biens déjà ingérés ; en parallèle, créez une alerte property pour le flux continu.
  2. Côté ADVERTS : créez l’alerte ADVERT pour le flux continu, et demandez par mail à [email protected] la réception du backfill historique sur votre webhook (volume + dates précisés).
  3. Dédupliquez côté client : un même flxId peut réapparaître si ingéré à nouveau (rare). Utilisez flxId comme clé d’idempotence.

​
Pour aller plus loin