Search properties
Search
Rechercher des biens (search PROPERTIES)
Recherche analytique avec déduplication multi-portails. Filtres riches, géo avancée, pagination cursor.
Search properties
Cet endpoint est l’outil principal pour interroger le catalogue Fluximmo dédupliqué. Une ligne de réponse = un bien physique unique (
flxId), agrégé à partir d’une ou plusieurs annonces source. Utilisez-le dès que vous avez besoin d’un état du marché propre, sans doublons inter-portails — idéal pour la recherche multi-portail BAAS.
Côté ADVERTS, il n’existe pas d’endpoint de search public : les annonces brutes (1 URL = 1 advert) sont accessibles uniquement via une alerte webhook ADVERT. Le payload de filtres d’une alerte advert est identique à celui d’un search property côté schéma. Voir Property vs Advert pour la décision.
Variante allégée : POST /v2/protected/properties/search/lite — schéma de réponse réduit, perf supérieure, filtres restreints. Utilisez-la pour UI temps réel, mobile, autocomplete.
Cas d’usage
- Cartographier l’offre d’un secteur (zone géographique × type × budget)
- Construire un AVM / peer comparison à partir d’un combo prix + surface + chambres
- Alimenter un dashboard analytique (suivi mensuel, séries temporelles via
meta.firstSeenAt) - Sourcer des biens pour un chasseur / mandataire (sortBy
FIRST_SEEN_AT DESC) - Backtester une thèse d’investissement (rendement m², rotation de stock)
Filtres clés
Le payload se compose desearch.filterProperty (les filtres) + size, sortBy, orderBy, searchAfterHash (pagination & tri) + search.fullTexts / search.keywords (recherche textuelle, max 20 items chacun).
| Filtre | Rôle | Voir |
|---|---|---|
location[] | Champs administratifs + geoBoundingBox + geoDistance (OR multi-zones) | Recherche géographique |
offer[].type | OFFER_BUY, OFFER_RENT, etc. | Filtres communs |
type[] | Classes de biens : CLASS_FLAT, CLASS_HOUSE, CLASS_PROGRAM, etc. | Filtres communs |
price.{initial,latest} + price.{currency,scope,variation,isAuction,warrantyDeposit} | Prix valeur (value), par m² (valuePerArea), variation, scope, currency | Filtres communs |
habitation | Surface, roomCount, bedroomCount, bathroomCount, EPC, heat | Filtres communs |
meta.isTotallyOffline | Exclure les biens offline (best practice prod : false) | Filtres communs |
meta.{firstSeenAt,lastSeenAt,lastUpdatedAt} | Filtres temporels | Filtres communs |
adverts[] (nested) | Filtres sur les annonces source (isOnline, isPro, source…) | Filtres communs |
land, parking, tags, process, hasAnomaly, isUrgent | Filtres avancés / niches | DTO référence |
Exemples
Tous les payloads ci-dessous utilisent le wrapper officiel{ size, sortBy, orderBy, search: { filterProperty: { ... } } } conformément au DTO SearchPropertyPayloadDto.
Exemple 1 — Combo standard dominant (Paris achat appartement)
Le combo prod le plus fréquent : Paris 1er, achat appartement/maison/programme neuf, budget 100-350 k€, surface 30-110 m², 1-3 chambres, biens offline exclus, recherche limitée aux annonces vues à partir du 1er janvier 2025, tri du plus récent au plus ancien.Exemple 2 — Recherche par département (location maison)
Cas exhaustivité : tout un département en location, maisons uniquement, surface ≥ 80 m² et 3+ chambres.department est un champ administratif indexé (code à 2 chiffres), idéal quand postalCode est trop fin.
Exemple 3 — geoDistance rayon 20 km autour de la Tour Eiffel
Cas chasseur urbain : rayon centré sur un point géocodé. Le pin est en{lat, lon} (WGS84). Calcul euclidien (DistanceType Plane) — fiable jusqu’à ~50 km, au-delà préférer geoBoundingBox.
Exemple 4 — geoBoundingBox Paris (carte interactive)
Cas type : “search in this map area” sur une UI de cartographie.topLeft.lat doit être supérieur à bottomRight.lat (latitudes décroissantes du nord vers le sud).
Exemple 5 — Multi-zones OR (Paris + petite couronne)
Plusieurs entrées danslocation[] sont combinées en OR : au moins une zone doit correspondre. Vous pouvez mixer libellés administratifs (postalCode, department, inseeCode) et modes géo (geoDistance, geoBoundingBox) dans la même requête — utile pour une agence multi-territoires.
Pagination
L’API utilise une pagination cursor stable plutôt qu’unoffset. C’est la méthode recommandée pour itérer sur de gros volumes : insertions et suppressions concurrentes ne décalent pas les pages.
Workflow :
- Premier appel : envoyer le payload sans
searchAfterHash. - La réponse contient un champ
searchAfterHash(string opaque). Conservez-le. - Pour la page suivante : renvoyer le même payload (mêmes filtres, même
sortBy/orderBy), en ajoutantsearchAfterHash: "<valeur reçue>". - Quand
searchAfterHashest absent / null dans la réponse, vous avez atteint la fin des résultats.
size: 1 à 100 (recommandé : 25 poursearchfull ; voir DTO). Plus grand = plus de coût et de latence.sortBy∈FIRST_SEEN_AT,LAST_UPDATED_AT,LAST_SEEN_AT,PRICE,RELEVANCE. Le tri canonique en prod estFIRST_SEEN_AT DESC.orderBy∈ASC,DESC.- ⚠️ Ne changez pas
sortBy/orderByentre deux pages — le cursor devient invalide.
Pagination Python
Authorizations
Body
application/json
Available options:
ASC, DESC Example:
"DESC"
Required range:
1 <= x <= 100Example:
10
Available options:
FIRST_SEEN_AT, PRICE, LAST_UPDATED_AT, LAST_SEEN_AT, RELEVANCE Example:
"FIRST_SEEN_AT"
The searchAfterHash parameter allows you to retrieve the next page of results by using the searchAfterHash value returned in the response from the previous page. This method eliminates the complexities of traditional pagination methods and ensures accurate results, regardless of insertions or deletions in the dataset.

