AnchorBuild a local real estate listing dataset with Full and Delta exports

Build a local dataset for the listings your team needs. Begin with a ready receiver and active live service, request a Full export to establish the initial selection, and run Delta exports to reconcile gaps every seven days. Run an additional Delta export after a delivery issue or receiver recovery.

Each export contains source Classified snapshots. A Classified is a source listing, not a deduplicated property, so this workflow does not create an unfiltered copy of Immoteur's database or one record per property.

Before you request the first Full export, make the receiver ready and activate a classified-notification-single or classified-notification-batch service with onlyNew set to false and a filter scope compatible with classified-export. Keep that live service active while the Full export establishes the initial dataset and while later Full or Delta exports run.

Configure a classified-export service for the filters and account access your team needs. A Full export selects the public-exportable listings that currently match that scope, including eligible removed listings. It may have no data batches when nothing matches, or deliver full Classified snapshots in one or more batches.

Public export eligibility is limited to France. Eligible listings have a French location with city INSEE code, city name, postcode, and department; a property type, transaction price and type; a euro currency or no currency; and a known value for whether the publisher is professional.

They also have a visible linked Property. Service filters and account access can narrow that scope, but cannot select a listing in another country.

Prepare the receiver before you request the export. Durably store or enqueue each received export delivery, including data batches and the terminal message, before returning 2xx. Your worker can then upsert each source snapshot by classified.id.

Use classified-notification-single when your receiver handles one snapshot per live event. Use classified-notification-batch when it handles batches. Set onlyNew to false when the live service must receive eligible updates as well as newly created listings.

Keep the live service separate from classified-export, even when both use the same receiver URL. The two services must use compatible filter scopes, but live notifications can still include records outside the Full export's public-exportable scope.

Handle those records separately in your local model. Persist or enqueue a complete delivery before returning a 2xx response, then let your own worker apply it.

Schedule Delta exports every seven days, even when live notifications are healthy. A meta.lastSeenAt-only revisit does not emit a live notification, so Delta reconciliation also covers changes that live delivery leaves out.

A Delta export requires a successful baseline compatible with the current filter scope and created no more than eight days earlier. Schedule the weekly run with enough time for a successful export before that eligibility window ends. If the baseline is missing, expired, or tied to different filters, the requested Delta export can be delivered as a Full export instead.

Process the delivered exportType, which tells you whether the export is effectively full or delta. Changing only the receiver URL does not make a compatible baseline invalid.

A terminal export message has an empty items array and isComplete: true. Do not infer completion from a chunk count, delivery order, or a period with no messages. Keep your own idempotency and completion records so retries and interrupted receivers can be handled deliberately.

Store the received source snapshot separately from your team's annotations, scores, CRM stages, and analysis fields. An incoming listing update can then replace the source data without erasing local work.

Upsert each source snapshot by classified.id and keep a durable idempotency record. Do not let arrival order, chunk position, delivery ID, or retry count decide which source snapshot wins.

Use meta.lastModifiedAt to prefer newer normalized source updates, but do not treat meta.lastModifiedAt and meta.lastSeenAt as a complete ordering key. With equal timestamps, still apply a changed propertyId relationship because clustering can emit that change without updating either timestamp.

If the relationship and source fields are unchanged, a later meta.lastSeenAt can record a revisit without overwriting newer source data.

A listing absent from a later export is not, by itself, a deletion command for your database.

Keep classified.id and propertyId as separate values. A Property groups related listings for an underlying asset, but a listing or property can also represent a programme with multiple dwellings.

When a snapshot contains price history, retain it as source evidence. Do not turn prices, areas, or room counts from a programme-level group into a complete history for one dwelling.

Use the classified-export reference↗ for the export envelope and its fields. Read the local data mirror guide↗ for the Full, live, and Delta workflow.

Read the webhook delivery guide↗ for acknowledgement, retries, and idempotency. Consult the API resource guide↗ when your application also retrieves listings or properties directly.

Create an account at Immoteur sign-up when the selected scope is ready to configure.