Passer au contenu principal
Utilisez ce guide pour exploiter une copie locale des données d’annonces sélectionnées par vos filtres Immoteur. Il associe un export complet pour le premier snapshot, des notifications en direct pour les mises à jour rapides et des exports delta pour réconcilier les changements dans le temps. Il ne s’agit pas d’une copie non filtrée de toutes les ressources Immoteur. Elle contient les annonces publiquement exportables qui correspondent actuellement aux filtres de votre service. La référence API générée reste la source de vérité pour les schémas de payload.

Démarrez le receiver avant le baseline

Configurez un receiver HTTPS et rendez-le opérationnel avant de demander ou planifier le premier export. Si votre receiver limite les IP sources, autorisez les IP d’egress Immoteur avant tout test. Gardez le handler HTTP minimal : persistez ou mettez la requête en queue, renvoyez 2xx, puis traitez-la dans votre propre worker. Consultez Livraison, tentatives et idempotence des webhooks pour le contrat du receiver, des timeouts, des en-têtes et des réessais.

Établissez le premier snapshot avec un export complet

Choisissez un export classifieds complet pour établir le baseline. Il envoie chaque annonce correspondant actuellement à vos filtres dans un ou plusieurs chunks, suivi d’un payload de fin vide. Chaque élément est un snapshot public complet de Classified.
Il s’agit de la forme du payload d’export, et non d’un schéma complet. Ne supposez ni taille de chunk fixe, ni ordre de livraison, ni nombre de livraisons. Traitez isComplete: true avec un tableau items vide comme le signal final de cet export.

Traitez les notifications d’annonces en direct

Utilisez le type de payload classified pour les notifications en direct. Elles donnent à votre copie locale des mises à jour rapides lorsqu’une annonce est créée ou lorsqu’un champ normalisé éligible change. Persistez un registre de livraison indexé par X-Immoteur-Service-Id et X-Immoteur-Event-Id avant d’accuser réception d’une notification en direct. Cet event ID reste stable entre les réessais d’une notification d’annonce. X-Immoteur-Delivery-Id identifie seulement une tentative HTTP : conservez-le pour le diagnostic, mais ne l’utilisez pas comme clé d’idempotence. Un revisit ne modifiant que meta.lastSeenAt est enregistré pour la réconciliation par export et ne produit pas de notification directe. Utilisez meta.lastModifiedAt pour les changements normalisés de la source et meta.lastSeenAt pour conserver le dernier revisit observé.

Réconciliez avec les exports delta

Utilisez un export complet pour le premier baseline et chaque fois que vous avez besoin d’un nouveau snapshot du périmètre de filtre actuel. Il sélectionne chaque annonce publiquement exportable qui correspond actuellement aux filtres.
S’il n’existe pas de baseline réussi compatible, si le filtre ou la destination change, ou si le baseline date de plus de 7 jours, un export delta bascule vers un export complet. Configurez les jours d’export dans le dashboard selon la cadence de réconciliation de votre intégration.

Rendez les écritures locales sûres face aux doublons et retards

Stockez chaque snapshot source par identifiant d’annonce, conservez le payload brut et gardez vos propres enrichissements dans des champs ou tables séparés. Ne laissez ni l’ordre d’arrivée, ni la position dans un chunk, ni le delivery ID, ni le nombre de réessais déterminer quel snapshot source prévaut. Lors de l’application d’un snapshot, privilégiez le meta.lastModifiedAt le plus récent. Lorsque le timestamp de modification est identique, vous pouvez conserver le meta.lastSeenAt le plus récent sans écraser des données normalisées plus récentes. status.current est un champ de cycle de vie ; ne déduisez pas une suppression du seul fait qu’un élément manque dans un export ultérieur. Un filtre modifié crée un nouveau périmètre de sélection et n’ordonne pas automatiquement de supprimer des données de votre base.

Utilisez la copie locale pour l’analyse et l’enrichissement

Une fois les snapshots source stockés, exécutez vos propres analyses, jointures, scores, synchronisations CRM ou enrichissements dans votre base de données. Gardez ces valeurs dérivées séparées du snapshot Immoteur afin qu’une mise à jour source entrante reste un simple upsert et ne crée pas de conflit avec votre travail local.

Questions fréquentes des développeurs

Cette synchronisation copie-t-elle toutes les données Immoteur ?

Non. Elle copie les données d’annonces publiquement exportables qui correspondent actuellement aux filtres configurés pour votre service. Utilisez la référence API et la configuration du service pour comprendre le payload et la sélection exacts.

Puis-je compter sur l’ordre d’arrivée ou recevoir chaque événement une seule fois ?

Non. Les livraisons de webhook peuvent être réessayées et les exports peuvent utiliser plusieurs chunks. Persistez un registre d’idempotence pour les notifications en direct et faites les upserts des snapshots par identifiant d’annonce.

Quand choisir un export complet ou delta ?

Commencez par un export complet. Gardez les notifications en direct actives pour les mises à jour rapides, puis utilisez les exports delta pour une réconciliation régulière. Un delta bascule automatiquement vers un export complet sans baseline récent compatible.

Dois-je supprimer un enregistrement local absent d’un export ultérieur ?

Pas automatiquement. Un export reflète son périmètre de filtre courant. Gardez les décisions de cycle de vie explicites et utilisez le snapshot d’annonce, notamment status.current, plutôt que d’interpréter une absence comme une instruction de suppression.