Skip to main content

Documentation Index

Fetch the complete documentation index at: https://doc.fluximmo.io/llms.txt

Use this file to discover all available pages before exploring further.

Fluximmo expose deux entités parce que le marché immobilier français est structurellement bruité : un même bien physique apparaît typiquement sur 3 à 8 portails (SeLoger, Bien’ici, PAP, Logic-Immo, sites d’agences, etc.) avec des descriptions, des prix et des photos qui divergent. Compter les annonces brutes mène à de la double-comptabilité ; ne regarder que le bien dédupliqué fait perdre la trace fine des publications.
  • Advert : 1 annonce sur 1 portail = 1 advert. Vue brute, exhaustive, source-par-source. Accessible uniquement via alerte webhook (pas de search public).
  • Property : 1 bien physique unique = N adverts agrégés côté Fluximmo. Vue dédupliquée, accessible via POST /v2/protected/properties/search (BAAS API à la demande) + alerte webhook qui livre des IDs.

​
Quand choisir lequel — version courte

Par défaut → PROPERTY. Si votre besoin est “rechercher des biens sur plusieurs portails sans les compter en double” (BAAS API, marketplace, analytics, scoring, AVM), Property est la primitive simple : une requête, un résultat dédupliqué, payez à l’usage. C’est ce que 90 % des intégrations veulent. ADVERTS est nécessaire si vous voulez :
  • répliquer la donnée Fluximmo dans votre propre DB (le seul moyen — il n’y a pas d’export bulk côté property) ;
  • recevoir tous les events de cycle de vie en temps réel avec le payload complet self-contained (PRICE, REPUBLISHED, UNPUBLISHED) ;
  • tracker l’inventaire d’une agence ou d’un seller portail-par-portail.

​
Décision rapide

​
Modèle d’agrégation

Une Property est créée (ou enrichie via MERGED) dès qu’un advert ingéré est rattaché à un bien physique déjà connu.

​
Reconstituer la dédup côté client (propertyFlxId)

Chaque advert porte un champ propertyFlxId. Deux adverts avec le même propertyFlxId sont des doublons d’un même bien physique. La règle d’attribution :
  • La première advert non-dupliquée d’une chaîne de dédup a flxId == propertyFlxId (l’advert est sa propre racine).
  • Chaque advert ingérée ensuite et reconnue comme doublon hérite du propertyFlxId de la racine.
Concrètement, si vous recevez deux adverts en webhook : 
// Advert 1 — racine de la chaîne
{ "flxId": "adv_aaa", "propertyFlxId": "adv_aaa", "source": { "website": "seloger" } }

// Advert 2 — doublon ingéré 12 h plus tard
{ "flxId": "adv_bbb", "propertyFlxId": "adv_aaa", "source": { "website": "bienici" } }
Vous savez côté DB que adv_bbb est un doublon de adv_aaa. Un client ADVERTS-only peut ainsi reconstruire sa propre vue agrégée à la Property en groupant par propertyFlxId — sans avoir à appeler le côté property de Fluximmo.

​
Cas d’usage

Recherche multi-portail (BAAS API)

Property — Cas d’usage principal côté API : POST /v2/protected/properties/search retourne directement les biens dédupliqués multi-portails. Une requête, un résultat propre, facturé à l’appel.

Marketplace / agrégateur

Property — Affichez un bien unique avec ses N sources en bas de fiche. Évitez les doublons visuels qui dégradent l’UX.

Analytics / market intel

Property — Comptez des biens, pas des publications. Les KPIs (stock, durée moyenne en ligne, prix médian) doivent être basés sur la déduplication serveur.

Fintech / scoring crédit

Property — Estimer la valeur d’un bien suppose un objet unique. Utilisez Property + estimatedPrice pour la valorisation.

Réplication BDD locale

Advert — Seule option pour avoir un stream complet de la donnée Fluximmo en local. Le webhook livre le payload entier et tous les events de cycle de vie.

Tracking concurrentiel par agence

Advert — seller.flxId + source.website permettent de suivre l’inventaire d’un acteur sur un portail donné, et de mesurer la durée de vie de chaque annonce.

​
Coût / perf

AxeADVERTS (alerte webhook)PROPERTIES (search API + alerte)
ModePush continu, payload complet, doublons inclusPull à la demande (search) + push allégé (alerte = IDs)
Volume webhookÉlevé : toutes les annonces matching, doublons inter-portailsFaible côté alerte (IDs uniquement, refetch optionnel)
Ownership de la donnéeFort — vous pouvez tout répliquer en localMoindre — pas de stream continu côté client
Quand c’est gagnantRéplication DB, market intel temps réel, analytics interneRecherche BAAS, scoring à la demande, UI temps réel
Volume webhook ADVERTS — c’est un mode haut débit. Sur des filtres larges (un département, plusieurs régions), prévoyez la capacité receiver en conséquence avant d’activer l’alerte. Côté PROPERTIES, l’alerte MERGED ne se déclenche que quand une nouvelle advert est fusionnée dans une property déjà matchée — pas à chaque check de fraîcheur.

​
Anti-patterns

Stocker en DB les résultats d’un search PROPERTIES — KO. L’API properties n’est pas conçue pour ce cas. Aucun event UNPUBLISHED n’est émis côté property : si un bien est retiré du marché, votre cache local va dériver sans signal. Pour répliquer Fluximmo en local, utilisez ADVERTS (alerte webhook avec payload complet + events UNPUBLISHED).
Faire de l’analytics agrégé sur Adverts sans grouper par propertyFlxId — KO. Un même bien physique compté 5 fois (une fois par portail) gonfle le stock, fausse les médianes prix/m² et biaise les durées en ligne. Si vous répliquez les adverts en DB, groupez par propertyFlxId au moment du calcul KPI pour retrouver la vue dédupliquée — ou utilisez directement l’API PROPERTIES côté Fluximmo.
Recréer une advert pour “rafraîchir” une property — KO. Les adverts sont fusionnées automatiquement par le moteur de matching. Ne cherchez pas à recréer ou dupliquer manuellement : la déduplication est un service de Fluximmo.

​
Pour aller plus loin