Skip to main content
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

Champs déclarés par les annonceurs — plus tu rajoutes de filtres spécifiques (ex. numberOfToilets, floor, etc.), plus tu risques de louper des annonces : peu d’annonceurs renseignent les champs très détaillés. En production, démarre avec un set minimal (location + type + offer + price) puis affine si besoin.
Le payload se compose de search.filterProperty (les filtres) + size, sortBy, orderBy, searchAfterHash (pagination & tri) + search.fullTexts / search.keywords (recherche textuelle, max 20 items chacun).
Le filtre location[].city est ignoré côté moteur de recherche. Utilisez postalCode, inseeCode ou department pour filtrer par zone administrative — sinon le résultat couvre toute la France.

​
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 dans location[] 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’un offset. 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 :
  1. Premier appel : envoyer le payload sans searchAfterHash.
  2. La réponse contient un champ searchAfterHash (string opaque). Conservez-le.
  3. Pour la page suivante : renvoyer le même payload (mêmes filtres, même sortBy/orderBy), en ajoutant searchAfterHash: "<valeur reçue>".
  4. Quand searchAfterHash est absent / null dans la réponse, vous avez atteint la fin des résultats.
Paramètres :
  • size : 1 à 100 (recommandé : 25 pour search full ; 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 est FIRST_SEEN_AT DESC.
  • orderBy ∈ ASC, DESC.
  • ⚠️ Ne changez pas sortBy/orderBy entre deux pages — le cursor devient invalide.
Pagination Python

Authorizations

​
x-api-key
string
header
required

Body

application/json
​
orderBy
enum<string>
required
Available options:
ASC,
DESC
Example:

"DESC"

​
search
object
required
​
size
number
default:10
required
Required range: 1 <= x <= 100
Example:

10

​
sortBy
enum<string>
required
Available options:
FIRST_SEEN_AT,
PRICE,
LAST_UPDATED_AT,
LAST_SEEN_AT,
RELEVANCE
Example:

"FIRST_SEEN_AT"

​
searchAfterHash
string

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.

Response

​
data
object
required