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.
Goal
Maintenir une copie locale (PostgreSQL/MySQL/ClickHouse) de toutes les annonces (adverts) sur un périmètre donné, synchronisée en continu sur votre webhook : alerte ADVERT pour le flux post-création + demande de backfill historique pour rattraper le passé.
Scénario
Vous êtes un agrégateur, une marketplace, ou un éditeur data immobilier qui veut :- requêter sa BDD locale sans appeler Fluximmo à chaque page vue (latence + coût) ;
- enrichir les annonces avec ses propres champs (scoring, tags internes, attribution commerciale) ;
- conserver un historique de prix et de cycle de vie indépendant des sources amont ;
- reconstruire la vue Property côté client si besoin, en groupant les adverts par
propertyFlxId.
Étapes
1. Choisir Adverts plutôt que Properties
Pour un cas réplication,
adverts est toujours le bon choix :- Payload webhook complet : l’objet advert entier est livré dans le webhook, pas uniquement un
flxId. Pas besoin de re-fetcher. - Suivi inter-portails : un même bien apparaissant sur SeLoger + LeBonCoin = 2 adverts liés au même
propertyFlxId. - Events :
PRICE,REPUBLISHED,UNPUBLISHEDsont émis sur l’advert (pas sur la property). - Reconstitution Property côté DB : grouper les adverts par
propertyFlxIdpermet de retrouver une vue dédupliquée localement.
2. Préparer le schéma de table locale
idx_adverts_property est ce qui permettra la reconstitution de la vue Property à l’étape 6.3. Demander l'activation de l'alerte ADVERT (création par Fluximmo)
La création d’alertes ADVERT sur webhook se fait sur demande par mail. Écrivez à [email protected] en précisant :
- Votre
clientId - Le
webhook_urlcible (HTTPS public, doit ack en < 1 s) - Les filtres souhaités (par exemple : département 75, achat appartement,
isOnline: true) - Les types de match désirés :
ALERT_MATCH_CREATED+ALERT_MATCH_ADVERT_EVENT(créations + eventsPRICE/REPUBLISHED/UNPUBLISHED) - Le volume estimé que votre receiver peut absorber
flxId pour la modifier ultérieurement (en PATCH, jamais en DELETE + recréation).4. Demander le backfill historique sur le même webhook
L’alerte ne fait pas de backfill automatique : elle ne match que les adverts ingérées après sa création. Pour rattraper le passé, écrivez à nouveau à [email protected] en précisant :
- Le
flxIdde l’alerte créée à l’étape 3 - La période de backfill (ex. derniers 30 jours, 6 mois, 2 ans)
- Le volume estimé que votre receiver peut absorber pendant la rejouage
advert.flxId.5. Endpoint webhook : ACK rapide + queue
Le crawler Fluximmo attend un
200 rapide (< 1 s). Toute logique métier doit être différée dans une queue (SQS / RabbitMQ / Redis Streams).6. Worker async : UPSERT + diff + reconstitution Property
Le webhook a la shape canonique Reconstitution de la vue Property côté DB — quand vous voulez interroger votre miroir comme si c’était
{ data: { created, updated } } :data.created[].adverts[]=AdvertDtocomplet → UPSERT total côté DBdata.updated[].adverts[]= DTO réduit (flxId,currentPrice,isOnlineuniquement) → UPDATE partiel + diff vs état stocké pour dériver les events PRICE / REPUBLISHED / UNPUBLISHED
/properties :7. Idempotence + reconciliation
Idempotence : Fluximmo livre parfois 2 fois le même webhook (retries sur timeout). L’
UPSERT par flxId rend le worker safe par construction.Reconciliation : si vous suspectez une dérive (panne queue, bug worker, perte webhook), demandez à Fluximmo un nouveau backfill ciblé sur la fenêtre concernée (par mail à [email protected], en précisant la période).Architecture / flow
Pièges fréquents
Pour aller plus loin
- Concepts — Property vs Advert (
propertyFlxIdpour reconstituer la dédup côté client) - Concepts — Match types & cycle d’alerte
- Concepts — Webhooks
- API — PUT /adverts/search/alerts
- API — Sample advert webhook body
- Playbook — Track price changes
- Playbook — Webhook volume architecture

