Skip to main content
Use this guide to operate a local copy of the classified data selected by your Immoteur filters. It combines a full export for the first snapshot, live notifications for prompt updates, and delta exports to reconcile changes over time. This is not an unfiltered copy of every Immoteur resource. It contains the public-exportable classifieds that currently match your configured service filters. The generated API reference remains the source of truth for payload schemas.

Start the receiver before the baseline

Configure an HTTPS receiver and make it ready before requesting or scheduling the first export. If your receiver restricts source IPs, allowlist Immoteur egress IPs before testing. Keep the HTTP handler small: persist or enqueue the request, return 2xx, then process it in your own worker. See Webhook delivery, retries, and idempotency for the receiver, timeout, header, and retry contract.

Establish the first snapshot with a full export

Choose a full classifieds export to establish the baseline. It sends every classified that currently matches your filters as one or more chunks, followed by an empty completion payload. Each item is a full public Classified snapshot.
This is the export payload shape, not a complete schema. Do not assume a fixed chunk size, delivery order, or number of deliveries. Treat isComplete: true with an empty items array as the terminal completion signal for that export.

Process live classified notifications

Use the classified payload type for live notifications. They give your local copy prompt updates when a classified is created or when an eligible normalized field changes. Persist a delivery ledger keyed by X-Immoteur-Service-Id and X-Immoteur-Event-Id before acknowledging a live notification. That event ID is stable across retries of a classified notification. X-Immoteur-Delivery-Id identifies an HTTP attempt only, so record it for diagnostics but do not use it as the idempotency key. A meta.lastSeenAt-only revisit is recorded for export reconciliation and does not produce a direct live notification. Use meta.lastModifiedAt for normalized source changes and meta.lastSeenAt to retain the most recent observed revisit.

Reconcile with delta exports

Use a full export for the first baseline and whenever you deliberately need a new snapshot of the current filter scope. It selects every currently matching public-exportable classified.
If no compatible successful baseline exists, the filter or destination changes, or the baseline is older than 7 days, a delta export falls back to a full export. Configure export days in the dashboard according to the reconciliation cadence your integration needs.

Make local writes safe for duplicates and late delivery

Store each source snapshot by classified identifier, retain the raw payload, and keep your own enrichment in separate fields or tables. Do not let arrival order, chunk position, delivery ID, or retry count decide which source snapshot wins. When applying a snapshot, prefer the newer meta.lastModifiedAt. When the modified timestamp is equal, you may retain the later meta.lastSeenAt without overwriting newer normalized data. status.current is a lifecycle field; do not infer deletion solely because an item is absent from a later export. A changed filter creates a new selection scope and is not an automatic instruction to remove records from your database.

Use the local copy for analysis and enrichment

Once source snapshots are stored, run your own analysis, joins, scoring, CRM sync, or enrichment against your database. Keep those derived values separate from the Immoteur snapshot so an incoming source update remains a straightforward upsert rather than a conflict with your local work.

Questions developers ask

Does this mirror all Immoteur data?

No. It mirrors the public-exportable classified data that currently matches the filters configured for your service. Use the API reference and your service configuration to understand the exact payload and selection.

Can I rely on arrival order or receive each event once?

No. Webhook deliveries can be retried and exports can use several chunks. Persist an idempotency ledger for live notifications and upsert snapshots by classified identifier.

When should I choose full or delta?

Start with a full export. Keep live notifications running for prompt updates, then use delta exports for regular reconciliation. A delta automatically falls back to a full export when there is no compatible recent baseline.

Should I delete a local record missing from a later export?

Not automatically. An export reflects its current filter scope. Keep lifecycle decisions explicit and use the classified snapshot, including status.current, instead of treating absence as a deletion command.