WP to XML

Tag: Real Estate Feed Development

  • Case Study 14: Custom Real Estate XML Feed Integration for International Property Portals

    Client Background

    A real estate agency based in Spain approached us with approximately 750 property listings stored in a multi-agency property database. The agency already had several XML feeds but needed a new custom XML feed for a German property portal with very specific technical and data requirements.

    The client wanted the feed to follow the receiving portal’s specification precisely rather than simply exporting the existing property data.

    The Challenge

    The main challenge was creating an XML feed that could:

    • Retrieve property information from the client’s external property database.
    • Transform the available property data into the required XML structure.
    • Follow the receiving portal’s exact XML specification.
    • Support the required API-based delivery process.
    • Work independently of the client’s main website.

    The client initially shared their website, but after reviewing the requirements, it became clear that the primary data source was Resales Online, rather than the agency’s WordPress or website content.

    This distinction was important because the XML feed did not need to be generated from the agency’s public website. Instead, the integration needed to work with the external property database and the receiving portal’s requirements.

    Understanding the Data Source

    The client’s properties were maintained through the Resales Online network. The project therefore required access to the relevant property database rather than relying on the agency website.

    After discussing the architecture with the client, we clarified that website access was not required. Instead, the integration would use the appropriate database/API access and a hosting environment capable of running the PHP-based conversion script.

    This helped simplify the implementation and avoided unnecessary changes to the client’s existing website.

    German Portal Requirements

    The receiving company provided technical specifications explaining that XML data had to be submitted through its REST API according to its own XML specification.

    The client supplied the technical documentation for the receiving platform, including information about its Import API and Import/Export API. The receiving company also indicated that use of the API was subject to its own service requirements and fees.

    This meant the project was more than simply producing an XML file. The feed had to be structured and prepared in a way compatible with the receiving portal’s technical requirements.

    API Access and Authentication

    During implementation, it became necessary to obtain the appropriate API credentials from the receiving platform.

    The client was guided through the API permission process and the relevant self-service area for generating API credentials. When necessary, the client also provided account access so that the integration work could proceed.

    Authentication was coordinated with the client because the platform required additional verification during login. The client provided the required verification code while the integration was being configured.

    Solution

    The solution involved creating a custom XML feed specifically around the client’s external property data source and the receiving portal’s requirements.

    The general workflow was:

    Property Database → Data Retrieval → Data Transformation → Custom XML Generation → Portal/API Delivery

    The approach avoided modifying the client’s main website and instead focused on the data integration layer.

    A separate PHP-capable hosting environment could be used to execute the conversion script, allowing the feed generation process to operate independently from the public-facing real estate website.

    Project Delivery

    The initial project was agreed including revisions and source code.

    The project required communication between three important components:

    1. The real estate agency
    2. The external property database
    3. The receiving property portal

    This made requirement clarification particularly important before development began.

    A Successful Follow-Up Project

    The relationship continued after the initial XML feed project.

    On March 17, 2025, the same client returned with another requirement: an XML feed for Idealista, a Spanish property portal.

    The client explained that Idealista required the feed developer to contact them directly to obtain the XML feed specification. The new feed was expected to be similar to the previous integration, but without the translation requirement used for the earlier project.

    A new custom offer was subsequently prepared to develop a feed specifically for Idealista.

    Key Lessons

    1. Identify the Real Data Source First

    A client’s public website is not necessarily the source of truth for a real estate feed.

    In this project, the agency website was initially shared, but the actual property data was maintained through an external property database. Identifying this early prevented unnecessary work on the website.

    2. Follow the Receiving Portal’s Specification

    International property portals often have their own XML structures, required fields, APIs and authentication procedures.

    A successful feed therefore needs to be designed around the destination portal’s specification, not simply around the source database.

    3. Separate Website Development From Feed Integration

    Because the client’s website was not required for this integration, the feed could be developed independently.

    This approach reduces the risk of interfering with an existing production website and makes the integration easier to maintain.

    4. API Credentials Are Part of the Integration

    XML feed development can involve more than XML formatting. When the destination platform requires REST API submission, authentication and API permissions also become part of the technical workflow.

    5. A Good Integration Can Lead to Repeat Business

    One of the strongest outcomes of this project was the client’s return for another XML feed shortly afterward.

    The second request for an Idealista feed demonstrated that successful completion of one portal integration can establish trust for additional international property-feed projects.

    Conclusion

    This project demonstrates how a custom real estate XML feed can connect an external property database with an international property portal without requiring changes to the agency’s main website.

    The key was understanding the actual data source, reviewing the destination portal’s technical requirements, obtaining the necessary API access, and building the feed around the receiving platform’s specification.

    The subsequent Idealista request from the same client further demonstrated the value of delivering a practical, portal-specific XML integration that can be extended to additional property platforms.

    Project Type: Custom Real Estate XML Feed
    Data Source: External Multi-Agency Property Database
    Integration: Custom XML + REST API
    Follow-Up: Idealista XML Feed Integration

  • Case Study 13: Building and Maintaining Custom Real Estate XML Feeds for a Multi-Website Property Business

    Client Overview

    The client operates multiple real estate websites and needed custom XML feeds to distribute property listings to different property networks and platforms.

    The initial requirement was relatively simple: create an XML feed compatible with the Houzez WordPress real estate plugin.

    What started as a single-feed project developed into a long-term technical collaboration involving multiple websites, property-feed formats, custom filtering rules, additional XML fields, feed troubleshooting, and performance improvements as the number of listings grew.

    The project began in May 2023 and continued through subsequent feed development and maintenance requests.

    The Challenge

    The client needed to connect WordPress-based real estate websites with external property networks using specific XML formats.

    The main challenges included:

    • Generating XML feeds from WordPress real estate data
    • Working with the Houzez and RealHomes property systems
    • Mapping WordPress property fields to external XML structures
    • Supporting different property types and values
    • Creating feeds for multiple property portals
    • Filtering properties based on backend options
    • Excluding sold or unwanted properties
    • Supporting additional XML fields as requirements evolved
    • Correctly handling property prices
    • Including property images and videos
    • Supporting different feed URLs using the same underlying data
    • Troubleshooting XML parsing and accessibility issues
    • Scaling the feed as the number of properties increased

    The client also wanted the solution to be reusable across multiple websites rather than creating a completely different system for every website.

    Phase 1: Houzez XML Feed Development

    The relationship started when the client contacted me looking for an XML feed for the Houzez plugin.

    The first requirement was to develop a WordPress plugin capable of generating a Nestopa XML feed from the staging website.

    The client specifically asked whether the plugin could subsequently be used on multiple websites using Houzez.

    I confirmed that the plugin could be developed to work with the Houzez environment.

    The initial feed was developed and tested, including adjustments to property-type mapping.

    For example, the client changed property values such as:

    • Condo
    • House
    • Land
    • Office
    • Shop
    • Warehouse
    • Hotel
    • Building
    • Villa

    A custom mapping was then added so that the website’s Villa property type could be mapped to the required House value in the destination feed.

    This established the foundation for the later feed work.

    Phase 2: Multiple XML Feeds for HuaHinJapan.com

    After the first successful implementation, the client asked whether the same system could be adapted for HuaHinJapan.com.

    The project expanded to multiple property-network feeds.

    The feeds included:

    • Proppit
    • Nestopa
    • Listanza

    A separate URL was also created for the Proppit feed so the same feed could be accessed using another filename for a different integration requirement.

    The completed feed URLs included separate Proppit, Nestopa and Listanza endpoints.

    This demonstrated an important advantage of the approach: one WordPress property database could feed multiple external platforms through different XML formats and endpoints.

    Handling Feed Accessibility Problems

    The XML itself was functioning correctly, but the client’s technical team later reported that the Nestopa feed could not be accessed from their server because the feed appeared to be blocking bots.

    Rather than assuming the XML structure was incorrect, the issue was investigated separately as an accessibility/security problem.

    An alternative feed location was provided for testing, and the client was advised to check whether an anti-spam plugin was interfering with external access.

    This distinction between feed-generation problems and server-access problems was important when troubleshooting the integration.

    Phase 3: Filtering Property Listings

    The requirements became more sophisticated as the client’s property portfolio grew.

    For the Nestopa feed, the client requested that properties marked as Sold should be excluded.

    The feed was subsequently updated specifically for this requirement.

    Later, the client requested a Proppit feed for another website that would include properties only when a specific backend Proppit option was selected.

    A custom WordPress plugin was developed to apply that condition when generating the XML feed.

    This transformed the feed from a simple “export everything” system into a rules-based property syndication feed.

    Phase 4: Images, Prices and Property Metadata

    One of the recurring challenges with real estate XML feeds is ensuring that all important property information is transferred correctly.

    The client received feedback that some listings were being published without images because the XML did not contain the required pictures information.

    The feed was updated to include the required picture data.

    A specific property was also identified as missing the required price information, which was investigated and corrected.

    Later, a pricing issue occurred because the original rent-price field had been removed from the website.

    The feed was adapted to use the site’s “Sale or Rent Price (Only digits)” field instead, restoring the correct price information in the XML.

    Phase 5: Adding the “DeBoost” Logic

    The client later introduced a more advanced requirement for Proppit.

    They wanted properties to be promoted by default, while allowing administrators to disable promotion for individual listings.

    The requested XML behavior was:

    • Default property → <is_boosted>TRUE</is_boosted>
    • Property marked for removal/deboost → <is_boosted>FALSE</is_boosted>

    The feed was updated to derive the value from the website’s backend option.

    The implementation was based on the WordPress field:

    inspiry_remove_proppit_boost

    The client subsequently confirmed that the implementation was working correctly.

    This was an example of converting a WordPress backend workflow into XML business logic.

    Phase 6: Expanding the Feed With Additional Fields

    As the client’s XML requirements evolved, additional property information was added.

    One example was the Project Name field, which needed to appear in the Nestopa XML under the project tag.

    Another requirement was adding the property floor number.

    The client specified that the floor field should be optional and only appear when the value was available. The implementation connected the WordPress custom field inspiry_floor_level to the XML floor tag.

    The completed implementation was subsequently connected to both Proppit feed versions.

    Phase 7: Supporting Larger Property Inventories

    The number of properties eventually increased significantly.

    At one stage, the client requested a separate version of the Proppit feed containing approximately 550 properties, rather than applying the existing Proppit2 filtering rule.

    A second version of the feed was created:

    proppit_xml_feed_v2.xml

    This allowed the client to maintain different feed purposes without disrupting the original feed.

    As the property database continued to grow, pagination eventually became necessary.

    In August 2025, the client reported a critical issue with the HuaHinJapan Nestopa feed. The solution involved introducing pagination because the number of properties had increased.

    The proposed architecture was to combine the paginated results into a final static XML file periodically, allowing the receiving system to continue downloading a single feed.

    This provided a practical way to handle a growing property inventory while preserving the existing integration model.

    Phase 8: Video and Multimedia Support

    The project also evolved beyond basic property information.

    The client later requested support for YouTube videos in the Proppit XML.

    The feed was updated with a dedicated videos structure so that video URLs could be included separately from other virtual-tour information.

    The videos tag was subsequently added to both Proppit feed versions.

    This was particularly important for property syndication because multimedia information can be lost if it is not explicitly mapped into the destination XML format.

    Ongoing Troubleshooting and Maintenance

    The project continued to require occasional maintenance after the original development.

    Examples included:

    XML parsing issue

    In May 2024, the client’s development team reported an XML parser error indicating that the receiving system was not recognizing the beginning of the XML document.

    The feed was checked, and the existing Proppit feed was confirmed to be functioning from the website side.

    Feed availability issue

    In October 2024, the HuaHinJapan Nestopa feed generated an XML parsing error:

    xmlParseEntityRef: no name

    The client requested a correction, and the feed was subsequently restored so that it could be reprocessed by the receiving system.

    Property removal issue

    In January 2025, the client reported that a property whose Proppit option had been removed was still appearing in the XML feed.

    The feed was investigated and subsequently updated.

    These requests demonstrate that XML feed development is not always a one-time task. Changes to WordPress fields, property workflows, external requirements and third-party importers can require ongoing feed maintenance.

    The Technical Approach

    The overall solution evolved around several core principles:

    WordPress Property Data → Custom Mapping Logic → XML Generation → Dedicated Feed URL → External Property Platform

    The implementation included:

    • Custom WordPress plugins
    • Property-field mapping
    • Conditional property filtering
    • Property-status filtering
    • Custom XML tags
    • Image mapping
    • Price mapping
    • Video mapping
    • Backend checkbox integration
    • Multiple feed endpoints
    • Separate feed versions
    • XML troubleshooting
    • Pagination for larger inventories
    • Static feed generation for external consumption

    Rather than forcing every external platform to consume the same generic feed, individual XML structures could be adapted to the requirements of the receiving platform.

    Results

    The project grew from a single XML feed requirement into a long-running feed-development relationship covering multiple websites and property networks.

    Key outcomes documented in the project include:

    • Custom XML feed developed for a Houzez-based website
    • Reusable approach for multiple WordPress property websites
    • Proppit XML feeds
    • Nestopa XML feeds
    • Listanza XML feed
    • Multiple feed URLs for different integration requirements
    • Property-type mapping
    • Sold-property filtering
    • Proppit checkbox filtering
    • Approximately 550-property feed version
    • Image support
    • Price corrections
    • Project-name mapping
    • Floor-number mapping
    • is_boosted / DeBoost logic
    • YouTube video support
    • XML troubleshooting and maintenance
    • Pagination strategy for increasing property inventories

    Most importantly, the client repeatedly returned with new websites and new feed requirements. The conversation records show requests in 2023, 2024 and 2025, including a new Nestopa feed for Star Property and later work on the growing HuaHinJapan feed.

    Client Feedback

    The client repeatedly expressed satisfaction with the work.

    Examples include:

    “You are the best!”

    and later:

    “Ranjit, excellent work! Very happy again.”

    The client also described the XML work as “amazing” when referring to the Proppit implementation.
    These comments are particularly meaningful because they came after the initial project had evolved into ongoing technical support and increasingly complex feed requirements.

    Key Takeaways

    This project demonstrates that a real estate XML feed is more than simply converting WordPress posts into XML.

    A production property feed may need to handle:

    Data Mapping
    Different property platforms require different field names, structures and accepted values.

    Business Rules
    Only selected properties may need to be exported, while sold or deboosted properties may need different treatment.

    Multimedia
    Images, floor plans, virtual tours and YouTube videos may require dedicated XML structures.

    Data Accuracy
    Property prices and custom fields must remain synchronized with the WordPress backend.

    Scalability
    A feed that works with a small number of properties may require pagination or other optimization as the inventory grows.

    Third-Party Compatibility
    External platforms may introduce parser, accessibility or validation requirements that need investigation separately from the WordPress implementation.

    Conclusion

    What began as a small XML-feed project became a long-term technical collaboration involving multiple real estate websites, multiple property portals and numerous custom feed requirements.

    The project is a good example of how a well-designed WordPress XML feed can evolve alongside a real estate business—from a basic property export to a flexible syndication system capable of handling filtering, custom fields, multimedia, business rules and larger property inventories.

    Need a custom XML feed for your WordPress real estate website?

    I can develop custom XML, RSS or JSON feeds based on your WordPress fields, real estate plugin, API documentation and destination portal requirements.

Powered by CookieAdmin