Double entry is expensive in an unexpected way
It is not only the time. It is that the two records drift apart within a week. The price drops in the portal and stays high on the site. A property sells and is still listed. A client calls about something that no longer exists and the agent explains.
If your agency software offers an XML export or another export interface, the website can pick up listings from it regularly. That is the whole basis of the fix: the site fetches the export periodically and reconciles itself against it. At Spolu v realitách we built exactly that on top of the POSKI REAL export.
One source of truth, the site only reads
This is the most important decision and it is made at the start. For this type of integration we keep one system as the source of truth, and the site only reads from it. So the agent never edits the same property in two places.
A listing is edited in the agency software and the site only displays it. The agent works where they are used to. An edit on the site is overwritten by the next run, and that is deliberate, because the site is not the system of record here. Two-way integrations have their place, but they need a clear rule for which system wins for which field. For listings going from agency software to a website, a one-way flow tends to be simpler and more reliable.
Before you commit to two-way sync, settle which record is the authoritative one.
Duplicates come from matching on the title
The classic mistake: the import looks for an existing property by its heading or address. The agent then edits the heading on the site to read better, and the next run creates a second record. A month later the site holds three versions of the same property.
Matching has to use the ID from the portal, never the text. The ID does not change, whatever anyone does to the heading.
What else to watch
The size of the feed
An export with a few hundred properties and thousands of photos can run to tens of megabytes. Loaded into memory in one go, the hosting refuses it. It has to be parsed as it streams, not all at once.
Pointless writes
If every run rewrites all three hundred listings even when nothing changed, the database grows for no reason and the run takes minutes. The fix is a fingerprint of the content: compute a hash, and if it matches, skip the record.
Images
Without de-duplication every run downloads the same photo again and the media library grows into gigabytes. At the same time the order from the feed has to survive, or the main photo ends up wrong.
Controlled vocabularies
Layouts, states and property types arrive as text. If they are not matched against the real field definitions, accents included, half the listings end up with no layout and the filter on the site stops working.
How to tell it is done well
- The import can be run by hand and has a dry run that shows changes before they are written.
- You can see when it last ran and what it did.
- Two runs at once do not get in each other’s way.
- It is clear what happens to the listings if the add-on is switched off or replaced.
For this integration we chose to map the data into the ordinary fields the site was already built on, not into a table of the add-on’s own. That is why the add-on can be switched off and the site keeps working. A custom table is not automatically wrong, but here it mattered that the add-on could be replaced years later without the site depending on it. How we think about integrations more broadly is covered under integrations.
