REAXML is the XML format realestate.com.au uses to receive property listings. An agency’s CRM writes each listing in that format and sends it to REA Group, which publishes it on realestate.com.au and realcommercial.com.au. The CRM can also send the same listings to the agency’s own website, either as a feed of files or through an API.
Everything here comes from the published documentation of REA Group, Domain, Rex, VaultRE and Agentbox, and each claim links to the page it came from. My own advice for a small agency is in a separate section near the end.
The short version
The agency keeps its listings in the CRM. The CRM is the approved uploader that sends each listing to each portal. For the agency's own website there are two routes: the CRM pushes a feed to the site, often REAXML, or the site pulls listings from the CRM's API. Getting listings back out of realestate.com.au is only possible through REA's partner platform, for CRMs and for service providers the agency has authorised.
What is REAXML?
REAXML is REA Group’s XML format for property listings. REA’s Listing Upload API overview says listings are received in REAXML, then queued, validated and published on realestate.com.au, realcommercial.com.au and REA’s apps. The structure is defined in a document type definition, propertyList.dtd, published at reaxml.realestate.com.au. REA’s REAXML elements page adds the business rules for each element.
Each listing is one of five kinds: residential sale, rental, land, rural or commercial. A file describes the whole listing every time. REA’s functional specifications say a new listing needs every element related to it, and so does an update to an existing one. For a website, that means each update replaces the stored listing rather than patching it.
These are the elements that decide what an agency website shows.
| Element | What it carries | What the website does with it |
|---|---|---|
| agentID | REA's identifier for the agency account, six characters | Tells you which agency or office the listing belongs to |
| uniqueID | The listing's ID from the CRM, 50 characters or fewer. REA matches every later update to the listing by agentID and uniqueID | The key for the listing in the website's database |
| Status | current, sold, offmarket or deleted for a sale. current, leased, offmarket or deleted for a rental | Decides whether the listing shows as available, shows as sold or leased, or comes off the site |
| price and priceView | price is a number with a display attribute that says whether it can be shown. priceView is up to 50 characters of text that shows in place of the price | Shows the price wording the agency sent, and never prints a number marked as hidden |
| soldDetails | The sold date and sold price, required when the status is sold. The sold price has its own display attribute | Shows a sold price only when it is marked for display |
| img | A web address for each photo, up to 35 a listing, in JPEG, PNG or GIF | Downloads and stores each photo |
| listingAgent | Name and contact details for the listing agent, up to two on a residential listing | Shows the agent on the listing page |
| underOffer | yes or no. REA says it can only be used while a contract of sale is not yet signed by both parties | An under offer label. Once both parties sign, the listing is sold |
Source: REA Partner Platform, functional specifications and REAXML elements.
Two statuses need a closer look. REA describes offmarket as a property sold or leased by another agency, a listing the agency no longer has the agreement for, or one that should come off the site for a while. Deleted means the upload was made in error. Withdrawn appears in the element list only as an auction result, for a property withdrawn from auction.
How a listing gets from the CRM to the portals
An agency doesn’t upload listings to realestate.com.au itself. Its CRM does, as an approved XML uploader. REA’s help article on becoming an XML uploader says a new uploader needs at least 5 agencies with REA subscriptions ready to start, a signed Partner Platform Agreement, and support available to its agents during business hours. The same article says REA does not upload data to other portals, so each portal needs its own feed from the CRM.
- The agent enters the listing in the CRMPhotos, copy, price wording and the agent's details go in once. In Rex, publication settings choose which portals, and whether the agency's own website, a listing goes to.
- The CRM checks itRex's article on portals says it validates each listing against the requirements of the portals it is going to, and only uploads listings that pass.
- The CRM sends it to each portalREA's Listing Upload API takes one REAXML listing per request over HTTPS and returns an upload ID. Rex says it uploads to supported portals immediately after any change to a listing.
- The portal reports backREA's upload report lists warnings and errors against the REAXML field that caused them. Rex logs every upload so the agency can review it.
- The CRM updates the agency websiteThrough one of the two routes in the next section, if the CRM supports one.
The portals don’t all take the same format. Rex lists REAXML, REIV, REIWA, Domain and realestate.co.nz among the native XML standards it uploads in. Domain’s guide to migrating from XML describes its older route as an XML feed sent by FTP, and its current route as JSON sent to its Listings Management API. Domain’s production checklist asks for listings to be posted in real time, not batched.
How listings get onto the agency’s own website
There are two routes, and which one is open depends on the CRM.
Route 1
The CRM pushes a feed to the website
- The CRM treats the website like another portal and sends it each new or changed listing.
- Rex says it supports custom uploads to other endpoints, including your own website, in a native portal format such as REAXML.
- Agentbox's websites page says its sites take a portal push from the agency's preferred CRM.
- The website needs somewhere to receive the files, such as an FTP folder, and code that reads them.
Route 2
The website pulls from the CRM's API
- The website asks the CRM for listings on a schedule, or when the CRM sends a webhook to say something changed.
- The developer may need the CRM's approval, and needs the agency's permission for its account.
- The data may come as JSON rather than REAXML. VaultRE's API uses JSON.
- The CRM can limit how often the website asks, so the website keeps its own copy of the listings.
VaultRE is a clear example of route 2. Its getting started page says a web developer must be registered as an approved integrator before they can use the API. The agency then grants access from its own account, under Office Integrations and then Third-Party Access, by creating a token for that developer. The agency can delete the token at any time. VaultRE’s technical guide sets the rest:
- Each API key is limited to 10 requests a second and 10,000 requests a day.
- For a website showing listings, VaultRE recommends syncing the data periodically and caching it, rather than calling the API on every page load.
- Anyone using its API, webhooks or XML feeds must download the photos and host them. VaultRE says hotlinking its images will result in the feed being disabled until it is fixed.
- VaultRE can send webhooks to tell a website that data has changed.
Pulling listings back out of realestate.com.au is a different matter. REA’s Listing Upload API doesn’t support retrieving listings. Its Listing Export API returns current, sold and off-market listings in REAXML, but REA says it is for the XML providers or CRMs agencies use, and for third-party service providers an agency has authorised. Either way it runs through REA’s partner platform, so for an agency website the CRM is the practical source.
What a web developer needs from the agency and the CRM
Before any code is written, these are the answers a developer needs. Most come from the CRM, and the agency has to ask for some of them itself.
Questions to settle first
- Which CRM the agency uses, and whether it offers a website feed, an API, or both
- The agency's written go-ahead, and any access token or form the CRM requires
- The format: REAXML, another portal format, or JSON from an API
- How it arrives: FTP folder details, an HTTPS endpoint, or API keys and webhooks
- Which listing kinds to show: sale, rental, land, rural, commercial
- How sold, leased, off-market and deleted listings are sent
- Whether price and sold price display settings come through
- How photos are supplied, and the rules on downloading them
- Whether agent profiles come through the feed
- A test listing the agency can change, sell and delete
- Whether switching on a website feed costs the agency extra
- Who to contact at the CRM when the feed stops
The test listing is the one I would not skip. Every status change in the table above should be tried on it before launch, so the website is seen to handle a sale, a lease and a deletion, not only a new listing.
What goes wrong with listing feeds
Each problem below comes back to something in the vendors’ documentation.
| Problem | Why it happens | What fixes it |
|---|---|---|
| The same listing appears twice | The listing got a new ID, often after a change of CRM. REA maps updates by agentID and uniqueID and says an existing uniqueID must be imported into the new system and sent back with every update. Domain says to keep existing ProviderAdID values after migrating, or risk duplicates | Key each listing on the CRM's unique ID, never on the address or headline. Carry the old IDs across when the CRM changes |
| Sold or leased properties still show as available | The website adds and updates listings but ignores the status. A sold, leased, offmarket or deleted listing keeps its old page | Map every status. Sold and leased can move to a results page. Offmarket and deleted come off the site |
| A withdrawn property is still listed | REAXML has no withdrawn status for a listing. A property the agency no longer has the agreement for comes through as offmarket, and one uploaded in error as deleted | Treat offmarket and deleted as removals, and test both on the test listing |
| A hidden price appears on the website | The template prints the price number and ignores the display attribute or the priceView text | Show priceView when it is sent. Show the number only when display allows it. Apply the same rule to the sold price |
| Photos break or the feed is switched off | The website links to the CRM's image server instead of storing copies. VaultRE disables feeds that hotlink its images | Download each photo, resize it for the site and store it. Fetch it again only when the CRM shows it has changed. VaultRE says its modification time tells you |
| Photos look wrong on the portal | REA says CMYK images are downloaded but rendered incorrectly, and slow image storage can time out | An agency or photographer issue rather than a website one: supply RGB photos from fast hosting |
| The feed stops without anyone noticing | An FTP connection fails, or an API key runs out of requests for the day. Rex's article on forcing an upload covers a portal having trouble with its FTP | Log every import. Send an alert when no update has arrived for a set time |
Source: REA’s getting started guide, functional specifications and REAXML elements; Domain’s migrating from XML; VaultRE’s technical guide.
REA’s getting started guide also says it is against its Acceptable Use Policy to duplicate or remove existing listings and put up new replacements. That rule is about the portal, but the same habit on an agency website leaves old pages and broken links behind.
A listing that stays up after a sale isn’t only a technical fault. It is still advertising a property the agency may no longer be selling. The WA rules on that are in WA real estate advertising rules.
The choice: the CRM’s own website or an independent site
Some CRMs sell websites alongside the CRM. Rex sells Rex Sites, and its help article on what Rex Websites does and doesn’t do is plain about the scope. Agentbox’s websites page says Agentbox Websites is now Reapit Websites.
The CRM's own website
Rex Sites, as Rex describes it
- A templated website platform for real estate agencies.
- Listing integration with Rex CRM or other external CRMs.
- Hosting, maintenance and platform improvements included.
- Customisation within the boundaries of the chosen template.
- Not a custom design or development service, and Rex does not write copy or source images.
An independent site
Built by a developer the agency chooses
- Pages and layout are not limited to a template.
- Listings still come from the CRM, by feed or API, so the CRM has to offer one.
- The developer may need the CRM's approval, as VaultRE requires for its API.
- Hosting, updates and the feed are the developer's job, or the agency's.
Neither column is better for every agency. The CRM’s website removes the feed as a separate job. The independent site gives the agency control over everything except the listing data.
My advice for a small agency
This section is my opinion as a web designer, not something the vendors’ documents say.
- Start by asking the CRM what it supportsAsk in writing whether it offers a website feed, an API, or both, in what format, and at what cost. The answer decides what an independent site would cost to run, and sometimes whether it is possible at all.
- Take the CRM's website if a template does the jobIf the agency needs listings, agent profiles, an appraisal form and a contact page, and is happy with a template, the CRM's own website is the shorter path. One supplier owns the feed and the site.
- Go independent when the site has to do moreSuburb pages, a developer's project site, buyers agent service pages or a design the template can't hold are the cases where an independent site earns its extra moving part.
- Keep the CRM as the only place listings are enteredNobody should type a listing into the website by hand. Then the website, the portals and the CRM can't disagree about a price or a status.
- Keep the domain in the agency's nameWhichever route you choose, register the domain to the agency, and ask what happens to the site and its content if you later change CRM.
- Treat every listing page as an advertisementA listing page on the agency's site is an advertisement. The price wording and the agency details on it follow the same rules as a portal ad, so they come from the CRM rather than the template.
Sources
Listings are received in REAXML; the DTD; supported listing types; the API does not retrieve listings; it is for XML providers or CRMs.
Listing Upload API: getting started
Testing for new uploaders; importing existing uniqueIDs; the Acceptable Use Policy on duplicate listings; image links.
agentID and uniqueID; full listing required for new listings and updates; image formats, CMYK and hosting.
Status values; price, display and priceView; soldDetails; img limit; listingAgent; underOffer; auction results.
One listing per HTTPS request, the upload ID and the upload report.
Exports listings in REAXML for CRMs and authorised third-party service providers; current, off-market and sold listings.
The 5-agency minimum, the Partner Platform Agreement, support hours, and that REA does not upload to other portals.
Migrating from XML and Moving to Production
The older XML feed by FTP, the JSON API, keeping ProviderAdID values to avoid duplicates, and real-time posting.
Introduction to Portals and Force Upload a Listing to a Portal
Native XML standards, custom uploads to your own website, validation before upload, and FTP connection errors.
Getting Started and Technical Guide
Approved integrators, agency access tokens, rate limits, caching, webhooks and the rule against hotlinking images.
Real estate websites and Rex Websites: What We Do (and Don't Do)
Rex Sites as a templated, hosted website platform with CRM listing integration; what it does not include.
Agentbox Websites is now Reapit Websites; portal push from the agency's preferred CRM.
Where Kovus stands
A listings feed on a Kovus site starts where this guide does: the CRM’s own documentation, the questions above answered in writing, and a test listing put through every status before launch. The feed is quoted per job once the CRM’s answers are in, and the agency approves the listing pages before they go live. Website builds cost A$500 to A$1,000, with premium builds from A$1,000.
What a real estate site needs beyond the feed is on the real estate websites page.
Frequently asked questions
What is REAXML?
REAXML is the XML format REA Group uses to receive property listings for realestate.com.au and realcommercial.com.au. An agency's CRM writes each listing in that format and sends it to REA. Its structure is set out in a document type definition, propertyList.dtd, and REA's partner documentation adds the rules for each element, such as the listing status, the price and the photos.
Can I pull my listings from realestate.com.au onto my own website?
Not as a simple feed. REA's Listing Upload API only receives listings and does not support retrieving them. REA's Listing Export API does return listings in REAXML, but its documentation says it is for the XML providers or CRMs that agencies use, and for third-party service providers an agency has authorised, through REA's partner platform. For an agency website, the usual source is the CRM, not the portal.
How do REAXML listings get onto an agency website?
There are two routes. The CRM can push a feed to the website the same way it pushes to a portal. Rex, for example, says it supports custom uploads to other endpoints, including your own website, in a portal format such as REAXML. Or the website can pull listings from the CRM's API, where the CRM offers one. VaultRE, for example, publishes an API that a registered integrator can use with an access token the agency creates.
Does VaultRE have an API for agency websites?
Yes. VaultRE's documentation says a web developer must first be registered as an approved integrator, which gives them an API key. The agency then creates an access token for that developer under Office Integrations and Third-Party Access, and can delete it at any time. Each API key is limited to 10 requests a second and 10,000 a day, and VaultRE recommends syncing listings and caching them rather than calling the API on every page load.
Why are sold listings still showing on my agency website?
Usually because the website isn't acting on the status the CRM sends. In REAXML a sale listing is current, sold, offmarket or deleted, and a rental is current, leased, offmarket or deleted. A website that only adds and updates listings, and never acts on sold, offmarket or deleted, keeps showing them as available.
Why does the same listing appear twice?
A listing is matched on its unique ID. REA maps every update to a listing by the agency's agentID and the CRM's uniqueID, and Domain warns that failing to keep its ProviderAdID values after a migration may result in duplicates. If a CRM change gives an existing listing a new ID, or a website keys its listings on something else such as the address, the same property can appear twice.
Should a small agency use its CRM's website or an independent site?
It depends on what the site has to do. A CRM's own website, such as Rex Sites, is a templated platform with the listing feed and hosting included, and Rex says it is not a custom design service and does not write copy or source images. An independent site needs a feed or API from the CRM, and is worth it when the agency wants pages a template can't provide. Either way, keep the domain in the agency's name.