WordPress Custom Fields → XML/JSON Mapping → Portal-Ready Property Feeds
The Challenge
A real estate business operating in Thailand needed to distribute property listings from its WordPress website to multiple property portals.
The website contained a large and continually changing inventory of properties for sale and rent. The challenge was not simply to generate an XML file. Each destination portal had its own feed structure, required fields, validation rules, filters, and data expectations.
The project initially involved creating a feed for Nestopa, followed by additional feeds for Proppit and PropertyHub.
The requirements evolved as the portal integrations were tested in real-world conditions, making reliable field mapping and data handling particularly important.
The Starting Point
The first requirement was relatively straightforward: generate a Nestopa XML feed from the property’s WordPress website.
A custom WordPress plugin was developed to transform property data into the XML structure required by the portal.
The initial implementation was delivered as a dedicated feed plugin, with the source code included and the feed made available through a public XML endpoint.
The project then expanded.
The client required another feed for Proppit, initially restricted to sale properties, with additional contact fields including:
- Phone
- LINE
The Proppit feed was generated directly from the WordPress property data and made available through a public XML endpoint.
From Simple XML Generation to Data Transformation
As more portals were introduced, it became clear that each integration needed its own mapping logic.
The WordPress website contained the source property information, while the portals expected their own specific structures.
The basic architecture therefore became:
WordPress property data
↓
Custom field extraction
↓
Data filtering and transformation
↓
Portal-specific field mapping
↓
XML/JSON generation
↓
Portal validation and import
This approach allowed the same WordPress property database to support multiple destinations without requiring the website’s core property structure to be redesigned for every portal.
Handling Property Filters
One important requirement was controlling exactly which properties should appear in a feed.
For example, the Proppit feed needed to distinguish between properties for sale and properties for rent.
At one stage, the client had approximately:
- 620 properties for sale
- 115 properties for rent
The requirement was to include the sale properties while excluding rentals from that particular feed. The feed was checked against the website’s property counts to confirm that the expected listings were being exported.
Later, the requirements became more sophisticated.
The client requested a feed containing both sale and rental properties, with rental properties filtered according to a minimum value of 25,000 THB.
A separate requirement also specified that, when the website contained more than 1,000 properties, the feed should continuously select the 1,000 newest properties rather than attempting to export the entire database.
This illustrates an important part of real estate feed development:
A portal feed is not necessarily a copy of the website. It is a controlled data export based on the destination’s business rules.
Mapping WordPress Data to Portal Fields
Real estate websites often store information in custom fields rather than standard WordPress post fields.
The feed therefore needed to identify the appropriate property fields and transform them into the format expected by each portal.
The work included mapping information such as:
- Property reference
- Property type
- Sale/rental status
- Price
- Property details
- Land size
- Contact information
- Project information
- Project ID
- Images
- Other portal-specific attributes
This field-by-field mapping is where much of the practical complexity of a real estate feed lies.
A feed can be technically valid XML or JSON and still be rejected by a portal if a value does not conform to the portal’s expected format.
Solving Portal-Specific Validation Errors
The Proppit integration demonstrated this clearly.
After the feed was delivered, the portal reported an error involving an Amenity value that did not match its required format. The feed was rechecked and updated, and a cache-busting query parameter was used when necessary so that the latest feed version could be retrieved instead of an older cached response.
This type of troubleshooting is an important part of production feed development.
The process was not simply:
Generate XML → Done
Instead, it became:
Generate → Validate → Submit → Review portal errors → Correct mapping → Re-test → Confirm
PropertyHub: A More Complex Integration
The PropertyHub integration introduced a substantially different requirement.
The portal supplied a JSON feed schema and documentation, along with a spreadsheet containing project information.
The feed needed to provide project information in addition to the normal property data.
The challenge was that projects were not properties.
The client’s WordPress website already contained a property management workflow, while the PropertyHub integration required project names and project IDs to be associated with properties for export.
This created a data-mapping problem between:
Property → Project Name → Project ID → PropertyHub Feed
Building Project Mapping
The project list was provided separately from the property data.
The solution was to map the project information so that the feed could retrieve the appropriate project name and corresponding project ID when generating the PropertyHub JSON feed.
The client eventually configured project information in the backend as a selectable value associated with properties.
The feed could then use that information when constructing the outgoing PropertyHub data.
The requirement was particularly important because PropertyHub expected both the project name and numerical project ID, while Proppit did not require the same project information.
This meant the same WordPress property data had to support two different portal requirements without unnecessarily exposing project information elsewhere on the website.
Avoiding Changes to the Front-End Property Structure
One of the lessons from this stage was that supporting an external portal should not accidentally alter how the website works for visitors.
An initial project-list mapping approach caused project records to appear in an inappropriate location on the website. The client reported that thousands of project records had appeared and had to be removed.
The requirement was clarified:
Projects were reference data for the feed and backend workflow, not additional front-end property listings.
The project mapping was subsequently handled in a way that allowed the property information and project information to remain separate while still providing the required values to the outgoing feed.
This became an important architectural consideration:
External feed requirements should be integrated into WordPress without disrupting the site’s existing content model or front-end experience.
Handling Project Names and IDs
Another challenge was that some project names already contained numbers.
For example, a project might contain a number as part of its actual name, while PropertyHub required a separate numerical project ID.
This created ambiguity when attempting to derive the ID from the project-name field.
The project therefore required a consistent naming and parsing strategy.
The client and developer tested different formats and discussed using a delimiter such as:
Project Name – 9999
rather than:
Project Name 9999
The final approach focused on making the feed parser resilient to spaces and formatting variations rather than requiring a large manual change to the website’s existing data.
This is a good example of why real estate integrations often require more than straightforward XML templating.
Debugging Data That Looks Correct
One of the most challenging stages occurred after the PropertyHub feed was technically working.
Some properties containing project names and IDs were successfully accepted, while others were not.
The client provided examples where the backend data appeared correct, but the corresponding information was not being accepted by the portal.
At one point, only 1,064 properties had been delivered successfully, despite substantially more properties being available.
The investigation therefore moved beyond XML/JSON syntax.
The feed itself could be valid while individual property records still contained values that the destination system could not process.
The debugging process involved examining:
- Project names
- Project IDs
- Missing IDs
- Formatting
- Spaces
- Line breaks
- Hidden characters
- Property-level data
- Portal validation results
This distinction is critical when developing automated feeds:
Feed validity and data validity are two different things.
Working With Portal Validation Reports
The PropertyHub integration included validation reports supplied by the portal.
These reports made it possible to identify which property records were failing and investigate the underlying values.
For example, one reported issue involved properties whose project name existed but whose project ID was missing.
The solution was to ensure that the required project ID information was available in the property’s backend data before it was exported.
This created a repeatable troubleshooting cycle:
- Generate the feed.
- Submit it to the portal.
- Review rejected records.
- Identify the problematic WordPress data.
- Improve the mapping or parsing logic.
- Correct source data where necessary.
- Generate the feed again.
- Re-submit and verify.
Keeping Multiple Portals in Sync
The project eventually involved several different destination formats:
Nestopa
A custom XML structure for the portal’s property requirements.
Proppit
A separate XML structure with contact information and property filtering.
PropertyHub
A JSON-based feed requiring project names and project IDs.
Each destination had different rules.
The WordPress website remained the central source of property information, while the feed layer transformed that information for each portal.
This provided a much more scalable model than manually preparing separate property files for every destination.
Ongoing Maintenance
The project also demonstrated that feed development does not necessarily end when the first feed is generated.
The client later requested relatively small operational changes, such as changing the contact email address used in the Proppit feed.
Other requests involved:
- Changing domains
- Creating feeds for new domains using the same property data
- Adjusting sale/rental filters
- Updating contact information
- Investigating missing properties
- Fixing portal validation errors
- Updating project mappings
- Rechecking feed output after website changes
For example, when the property website moved to a new domain while using the same underlying property inventory, the feed needed to be adapted to the new domain rather than treated as an entirely unrelated property database.
The Result
The project evolved from a basic WordPress XML feed into a multi-portal property data integration system.
The final workflow allowed the real estate website to act as the central source while generating portal-specific output according to each destination’s requirements.
Key capabilities included:
- WordPress property data extraction
- Custom field mapping
- XML feed generation
- JSON feed generation
- Sale/rental filtering
- Minimum-price filtering
- Latest-property selection
- Contact-field mapping
- Project-name mapping
- Project-ID mapping
- Portal-specific formatting
- Validation-error troubleshooting
- Property-level data debugging
- Domain/feed updates
- Ongoing feed maintenance
Key Takeaway
Real estate feed development is more than generating an XML or JSON document.
The real challenge is creating a reliable bridge between a WordPress property database and the specific data model expected by each external portal.
In this project, the feed layer had to deal with changing requirements, multiple destinations, custom fields, project relationships, filtering rules, validation errors, and inconsistent source data.
The result was a practical, portal-ready integration that could transform the website’s property information into the formats required by different property platforms.
WordPress remains the source of truth.
The feed handles the transformation.
Each portal receives the structure and data it expects.
That is the core principle behind a reliable custom real estate feed.
Leave a Reply