Property Feeds for Estate Agent Websites: How Rightmove, Zoopla and Your CRM Actually Connect

Most estate agents ask the question backwards. They ask whether a new website can pull their properties from Rightmove. It can't, and it shouldn't. Rightmove is somewhere you send listings, not somewhere you take them from.

Your properties live in your CRM. Reapit, Alto, Jupix, Street, Dezrez, whatever you run the agency on. That system is the single place a negotiator types an asking price, marks a property Sold STC and uploads the floorplan. Rightmove, Zoopla and OnTheMarket are downstream of it. Your own website should be downstream of it too, from exactly the same source, updating on the same day, with nobody re-typing anything.

Get that one idea right and the rest of the project becomes straightforward. Get it wrong and you end up with a website that quietly drifts out of date until someone notices a let property still advertised at three months old.

TL;DR

• The UK portals are a destination, not a data source. Rightmove's Automated Datafeed is built for pushing your listings in, not pulling other people's out.
• Zoopla's public listings API was withdrawn years ago. The ZPG real-time feed is a partner integration for sending listings to Zoopla and PrimeLocation.
• OnTheMarket runs its own real-time datafeed for CRM vendors, again for publishing listings to the portal.
• Your website should sync from your CRM: Reapit Foundations, the Alto/Vebra XML client feed, Jupix, or the Street property feed API.
• Do not call the CRM API on every page load. Sync into your own database on a schedule and serve pages from that. Reapit says this explicitly in its own documentation.
• A feed gives you structured data, not a good website. Search, maps, schema, page speed, area guides and enquiry routing are still your job.
• IDX and MLS are American. They do not exist in the UK. Ignore any agency quoting you for them.
• Before you sign anything, confirm who owns the API credentials, what the vendor charges for feed access, and how long approval takes.

The portals are an output, not a source

This is where most of the confusion comes from, so it is worth being precise about what each portal actually offers.

Rightmove. Rightmove publishes an Automated Datafeed specification for members and their software providers. The real-time feed is built around three tested calls: send a property, remove a property, and get a branch property list. Credentials are issued by the Rightmove data feed team, and for new members a branch only goes live after Rightmove's own customer service sign-off. Notice the direction of travel. The only read call hands back a list of your own branch's properties, which is a reconciliation tool for a CRM vendor checking what it has already sent. It is not a website feed. Rightmove does now run an early-adopter API portal, but the read operations there cover commercial listings only, and residential agents are pointed back at the datafeed. For residential sales and lettings there is still no public API for reading listings, sold prices or valuations from Rightmove.

Zoopla. Zoopla's old public listings API is no longer available. What exists now is the ZPG real-time feed, a partner integration authenticated with a key pair, used to create and update listings on Zoopla and PrimeLocation. Same direction again: in, not out.

OnTheMarket. OnTheMarket operates its own real-time datafeed for CRM and software vendors uploading on behalf of member agents. It follows the same broad shape as Rightmove's real-time feed, with its own authentication and some OnTheMarket-specific fields, which is why most CRM vendors support both.

So when someone tells you their website "pulls from Rightmove", one of three things is true: they mean it pushes to Rightmove and they have muddled the wording, they are using a scraper, or they are using a third-party middleware service that sits between your CRM and the portals and happens to expose the data to your site as well. The first is fine. The second is a problem waiting to happen. The third is legitimate but worth understanding before you depend on it.

Your CRM is the source of truth

Once you accept that, the architecture is obvious. One system holds the property data, Reapit or Alto or Jupix or Street, and four channels subscribe to it:

• Rightmove
• Zoopla
• OnTheMarket
• your own website

Your website becomes a fourth publishing channel, and the one you actually own. That matters commercially. Every enquiry that lands on a portal is an enquiry you pay for and share with competing estate agents on the same results page. Every enquiry that lands on your own property page is yours outright, attributable, and feeding back into the same CRM.

The logic is identical whether you are a sales-only agency, a letting agent running a managed portfolio, or both under one roof. The only thing that changes is which fields you care about. Here is what each of the four CRMs most commonly used by UK agents actually exposes.

Reapit: the Foundations API

Reapit is the CRM you are most likely to meet in a mid-size or corporate agency, and it has the most mature developer story of the four.

Reapit Foundations is a REST platform with a developer portal, self-service enrolment, interactive documentation and managed API keys. For a website you are mainly interested in two endpoints: /properties for the listings and /propertyImages for the media. Both support filtering by status, pagination capped at 100 records per call, and a modifiedFrom parameter so you can ask only for what has changed since the last sync.

Two things in Reapit's own website development guidance are worth quoting to any developer bidding for your project. First, Reapit explicitly advises against fetching properties on every page render and calls it an inefficient way to build a website. Second, Reapit's API is billed on consumption, so a badly built integration costs you money every time a visitor loads a search results page. The recommended pattern is a full initial seed into your own database, an hourly job that fetches only changed records, and a daily housekeeping pass to catch anything that fell through.

If a developer tells you they will "just call the Reapit API when someone searches", they have not read the documentation.

Reapit's own documentation, on why you sync rather than proxy.

Alto and Vebra: the XML client feed

Alto, which describes itself as the UK's most widely used agency CRM, still carries its Vebra heritage in the plumbing. Alto, Jupix, Expert Agent, CFP and Yourkeys now sit together under Alto Software Group, spun out of Houseful (the Zoopla parent) as a standalone software business in early 2025.

The integration route is the client feed export, a versioned XML web service rather than a modern JSON REST API. In practice a developer needs three things from you: a datafeed ID, an API username and an API password. The API credentials are separate from the ones you use to log into Alto, and your Alto account manager has to issue them. Authentication is HTTP Basic against a datafeed-specific endpoint, which returns a session token that expires after roughly an hour, and the service returns XML for branches and the properties within them.

None of that is difficult for a competent developer, but it is older technology than Reapit or Street. Expect the data model to be flatter, expect fewer fields than you were hoping for, and expect to spend an afternoon deciding how Alto's property types and statuses should map to the filters you want on your search page.

Jupix: same family, different plumbing

Jupix is still one of the most widely used CRMs among independent agents, particularly with letting agents. It now sits alongside Alto under Alto Software Group, which has been migrating Jupix users onto Alto since 2022, and it ships direct Rightmove and Zoopla integrations out of the box.

For websites, "Jupix format" is a recognised feed standard in its own right. Most third-party property importers list Jupix alongside Alto, Vebra and the legacy Rightmove BLM flat file as supported input formats, which tells you something useful: if your developer has built a Jupix integration before, they have almost certainly built the others too, because the same importer handles all of them.

The practical question with Jupix is delivery. Some agencies are on a scheduled file drop, others on a web service. Ask which one you are on before anyone quotes you, because a nightly file export and a near-live web service are very different experiences for a buyer refreshing your new instructions page.

Street: a read-only feed built for websites

Street.co.uk is the newest of the four and, from a developer's point of view, the easiest to work with. It publishes a public developer portal with OpenAPI contracts you can read before you have any credentials at all, which is rare in this industry.

Two products matter. The Street Open API is a full REST API covering companies, branches, viewings, valuations, applicants, vendors, tenants and landlords, with webhooks so your systems are notified of events instead of polling for them. The Property Feed API is the narrower one: a read-only feed designed specifically to power an agency's own website, with sales search, lettings search, a single property record, area lookups and a property features list.

That is exactly the shape you want for a website. Street describes the Open API as free and open, and a sandbox on Street's staging environment is available on request, so a developer can build and test the whole property section before your live data is involved. If you are choosing a CRM and a website at the same time and integration effort is a real factor in the decision, this is the one that will cost you the least developer time.

Street publishes its API contracts openly, which is rare among UK agency CRMs.

Sync the feed, do not proxy it

Whichever CRM you are on, the correct architecture is the same, and it is the single biggest technical decision in the project.

Wrong: a visitor searches for two-bed flats in Clapham, your website calls the CRM API live, waits for a response, and renders the page. Every search is a round trip to a third-party system you do not control. It is slow, it breaks when the vendor has an outage, it is invisible to Google if the results only appear after JavaScript runs, and on a consumption-billed API it costs you money per visitor.

Right: a scheduled job pulls changes from the CRM into your own database, downloads and re-encodes the images onto your own hosting, and your website serves every page from local data. Search is instant. The site stays up if the CRM does not. Google gets a real HTML page at a real URL for every property. Your API usage is a predictable handful of calls an hour rather than a function of your traffic.

The only thing you give up is true real-time accuracy, and the gap is typically an hour. For a property portal that is irrelevant. Nobody makes a decision on a £650,000 house based on a price change that landed forty minutes ago.

What a property feed will not give you

This is where projects go wrong after the technical bit has gone right. A feed delivers structured data. It does not deliver a good website. Budget for the following, because none of it arrives in the XML:

• Search that matches how people actually look. Price brackets, bedrooms, property type, radius from a postcode, draw-on-map, keyword filters for "garden" or "chain free". Your CRM stores fields. Turning them into a usable search is design work.
• Media that loads fast. Agency photography comes off the CRM as large JPEGs. Serve them raw and your Core Web Vitals will be poor on exactly the pages you most want to rank. Images need resizing, converting and lazy loading at sync time.
• Sensible status handling. Under Offer, Sold STC, Let Agreed, Withdrawn, Reserved. Decide which statuses appear on the site, which disappear, and what happens to the URL when a property sells. Deleting the page throws away every link and every bit of ranking it earned.
• Material information. Council tax band, tenure, EPC rating, ground rent, service charge. Portals have tightened up what they require here. If the fields are in your CRM, put them on your own property pages too. If they are not, the feed cannot invent them.
• Lettings as a first-class citizen. Rent frequency, deposit, available-from date, furnishing, tenant fees. A lot of website templates treat lettings as sales with a different price label, and every letting agent who has used one can tell within ten seconds.
• Enquiry routing back into the CRM. An enquiry form that emails the office is a missed opportunity. It should create an applicant record against the right branch and the right property, so the enquiry is worked rather than read.
• Branch mapping. Multi-office agencies need every listing attributed to the correct branch, with branch pages, branch filters and branch-level contact details that actually route correctly.

Why a synced feed beats an embedded portal widget

There is a cheaper option, and it is worth understanding why it costs you more in the long run. Several providers offer an embeddable search widget: a block of JavaScript that drops a property list into your page, hosted on somebody else's domain.

It is quick, and it is an SEO dead end. The listings typically live behind an iframe or a client-side render, so there is often no indexable URL for an individual property on your domain. No URL means no page to rank, no schema markup, no internal linking, nothing to share and nothing that survives if you leave the provider. You have rented a property search rather than built one.

A synced feed gives every property a real page at a real URL on your own domain, which you can mark up with structured data, link to from area guides, and keep as a redirect target once the property sells. Over three years that difference compounds. It is the same argument as choosing a custom estate agency website over a website builder: the cheap route is genuinely cheaper right up until the point where you want to own the asset.

A note on IDX and MLS

If you have been reading web design advice online, you have probably seen agencies offering "IDX integration" or "MLS feeds". Both are American. IDX is the Internet Data Exchange arrangement that lets a US brokerage display other brokerages' listings, and an MLS is the regional multiple listing service that holds the shared data.

Neither exists in the UK. There is no national shared listing database, and there is no reciprocal display agreement between agencies. The nearest equivalents are the portals, and as covered above, they are publishing destinations rather than sources you can draw from.

This matters when you are shortlisting a web agency. If a UK proposal quotes you for IDX or MLS integration, it has been written from an American template. Ask any agency you shortlist which UK CRMs they have read the documentation for, and what their sync architecture looks like. The answer to the second question matters more than the first.

What to ask before you sign anything

Ask your CRM provider:

• Do you provide an API or data feed for a third-party website, and is there a charge for it?
• Who issues the credentials, how long does approval take, and do they belong to us or to the developer?
• Is it a live web service or a scheduled file export, and how often does it update?
• Which fields does it include? Specifically: EPC, floorplans, video tours, council tax band, tenure and lettings fields.
• Is there a sandbox or test branch we can point a development site at?

Ask your web developer:

• Which of these CRMs have you integrated before? Name the CRMs and what the integration involved.
• Will the site sync into its own database, or call the API on page load? (There is one right answer.)
• What is the URL structure for a property, and what happens to that URL when the property sells or lets?
• Are images processed at sync time, and what happens to page speed on a 40-result search page?
• Do enquiries write back into the CRM, and against which record?
• If we change CRM in three years, how much of this has to be rebuilt?

That last question separates the serious developers from the rest. A well-built integration keeps the CRM-specific code in one importer and everything else, the search, the templates, the URLs, untouched. Swapping Alto for Street should mean rewriting the importer, not rebuilding the site.

How long a feed integration takes

Honestly: the code is rarely the bottleneck. Getting credentials out of the CRM vendor is.

The development work on a straightforward one-branch feed is a handful of days once the data is flowing. Vendor approval and credential issuing can take anything from a few days to a few weeks depending on the provider and how busy your account manager is, and it is the item most likely to slip a launch date. Start it on day one of the project, not the week before go-live.

Cost varies with the CRM and the complexity. A single-branch Street integration is a different proposition from a twelve-branch Reapit build with consumption-billed API calls, custom status logic and write-back of enquiries. Some vendors charge for feed access and some do not, so confirm it before you budget rather than after. For a wider view of what a project like this costs in the UK, we have broken the numbers down in our guide to website design costs.

Make your website the best place to find your properties

The portals are not going anywhere, and you should keep feeding them. But every year you spend sending your best instructions to a marketplace where your competitors advertise on the same page is a year you are not building anything of your own.

A property feed is the unglamorous plumbing that makes the alternative possible. Once your listings appear on your own site automatically, accurately and fast, the rest of the work, the area guides, the valuation funnel, the local SEO, the brand, actually has somewhere to send people.

If you are an estate agent or letting agent planning a new site and you want to know exactly what your CRM will and will not give you, that is the first conversation worth having about an estate agency website. Tell us which system you run on and we will tell you straight what your site can pull from it. Get in touch and we will take it from there.