The company website became the next part of the route to go under the microscope. Andreas opened the page of a development that was being promoted through both portals and agents. Buyers could explore the architecture, read about the location and submit a general enquiry, but they could not see which apartments were actually available at that moment.
The unit list lived elsewhere. The team updated it in an internal system, sales managers checked availability before speaking to buyers, and new materials were periodically prepared for agents. The website, meanwhile, continued to present the project as a static showcase even when the prices or statuses of individual apartments had changed.
— If buyers reach our website after viewing a listing, why are we asking them to send another general request? — Andreas asked during a meeting with the technical team. — They already know the project. At this point, they need a useful next step, not the same introduction in a different wrapper.
What the Website Actually Needed
The obvious answer was to add a table of apartments to the project page. But simply copying the inventory would create yet another list for the team to maintain manually. Every change in price, status or unit details could produce a mismatch between the internal system, the website and the materials used by partners.
— We can add an availability section, — the developer said. — But first we need to decide where the data comes from. If the team still edits several separate lists, someone will always have to check which version is current.
Andreas was not looking for another shop window. He wanted a single process in which a change was entered once and then reflected across the website and other connected channels. Buyers, sales managers and partners needed to work with the same live inventory rather than their own slightly different copies.
How an IDX Feed Works
The first option the team considered was an IDX feed. It allows a property catalogue to appear on the developer’s website while drawing its information from a central source. The team does not have to move every unit across manually or keep checking several versions of the same inventory.
Prices, statuses and property details are maintained in MLS RealtyHub. The IDX feed sends this information to a structured catalogue on the website, where buyers can browse a project, apply filters and view available units. When the status of an apartment changes, the update moves through the configured feed and is reflected in the catalogue.
For the company, this route could support a quicker launch. If the standard catalogue logic matched what the website needed, there would be no reason to build the entire data and display layer from the ground up. Buyers would see current options, while the team would continue managing inventory from one central source.
When an API Is the Better Fit
The developer’s website already had its own established design system, so the technical team also proposed an API. This approach would still deliver information from MLS RealtyHub, but it would give the developers more control over how the data appeared and behaved. They could build custom filters, unit cards, floor-plan pages and enquiry flows inside the existing interface.
— So IDX gives us a faster route to a ready-made catalogue, while an API lets us build the experience around our own website? — Andreas asked. — Either way, the availability data still comes from the same place?
— That’s right, — the developer confirmed. — The implementation changes, but the principle stays the same. The website doesn’t maintain a separate manual copy of the inventory; it receives current data from MLS RealtyHub.
The choice between IDX and API was not about which term sounded more impressive. It depended on the website’s existing structure, the filters buyers needed, available development resources and the required level of customisation. Both routes addressed the same practical goal: connecting the developer’s owned website to live inventory.
From a Unit Page to a Useful Enquiry
On the first test layout, a new enquiry button appeared next to each available apartment. A buyer could view the price and floor plan, select a specific unit and submit a request linked directly to it. Instead of receiving a vague question about the project, the sales manager would have a clear starting point for the conversation.
The workflow became much cleaner. The team updated inventory in MLS RealtyHub, the feed passed current information to the website, the buyer explored available options, and the enquiry entered the CRM with its source, project and selected unit attached. Each system still had its own role, but the information no longer broke into disconnected versions along the way.
Andreas placed the portal listing next to the new website prototype. The portal helped buyers discover the development, while the website allowed them to continue their search. External reach and the developer’s own route were no longer being asked to do the same job.
More Than a Digital Brochure
Live inventory would not turn the company website into a replacement for every other channel. Portals would continue to support discovery, while agents would present suitable projects within a more personal buying context. The feed simply created a working connection between those channels and the developer’s own infrastructure.
Until then, the website had explained what the company was building. With current inventory in place, it could also show buyers what they were able to choose right now. The change was not merely an extra block on the page; it gave the buyer journey a practical, manageable continuation.
Before leaving the meeting, Andreas sent one final message to the team: “We’re not adding another apartment list. We’re connecting the website to the inventory we already maintain.” It sounded simple, but that was the whole point — the best workflows usually do once the moving parts are properly connected.
Author
This material was written by Maria Vashchenko.
For questions, collaboration, or further discussion, feel free to contact me on LinkedIn.
