Rightmove & OnTheMarket UK Property Listings + Sold Prices

An independent tool. Not affiliated with or endorsed by Rightmove, Zoopla or OnTheMarket; their names are trademarks of their owners.

Rightmove and OnTheMarket UK property listings on one schema: one JSON row per listing, for sale or to rent, with optional detail fields and planning constraints, plus a separate sold-prices mode with HM Land Registry sale history for England and Wales. Nearby planning applications are currently unavailable (see "Planning applications"). OnTheMarket is opt-in and has limits (see "OnTheMarket"). Zoopla is not available at the moment: a run that asks for it skips it with a note and is not charged for it.

Portal	Status	Notes
Rightmove	Available (the default)	For sale and to rent, from places by name or outcode or from pasted search pages.
OnTheMarket	Available, opt-in (portals)	Filters are applied by the Actor after fetching; some inputs are skipped with a note (see "OnTheMarket").
Zoopla	Not available at the moment	Skipped with a note in RUN_SUMMARY; no listing or add-on charge.
Sold prices	Available (mode: "sold-prices")	HM Land Registry sale history, England and Wales.

Monitoring: only new and changed listings

Set monitorId (search mode) and schedule the same search. The Actor keeps a record of the listings it has seen, in a key-value store named uk-property-monitor in your own Apify account, and returns only listings that are new or have changed since the last run with the same id. The listing, detail and add-on prices apply only to the rows returned; listings that have not changed are not returned, have no listing charge, and have no detail page fetched. A monitoring run that read listings is charged the run start once ($0.005 on the free plan) even when nothing changed, so a quiet daily monitor of one search costs about $0.15 a month. A run that is blocked, or finds no listings at all, is not charged.

{
  "locations": ["Leeds"],
  "monitorId": "leeds-daily",
  "maxItems": 300
}

• Rows. Each row has changeType (ADDED or CHANGED). A CHANGED row also has changedFields (for example ["price"]) and previous (the old values of those fields). The fields compared are price, price qualifier, bedrooms, bathrooms, property type, address and agent, plus status and the description where the search results show them (on Rightmove and OnTheMarket they currently show neither, so a listing marked sold subject to contract is not reported as changed).
• First run. A new monitorId has nothing to compare with, so every listing comes back as ADDED and is charged as normal. Later runs return only the differences.
• maxItems counts listings looked at, not rows returned, so set it to cover the whole search (up to 1,000).
• Removed listings are not reported. A listing that is no longer on the portal simply stops appearing.
• If the record cannot be read, the run stops before returning or charging anything; try again. If the record is in a form this version does not understand, the run says so, and a new monitorId starts again from scratch (every listing is then ADDED). The record holds up to 5,000 listings; listings not seen for 90 days, and the oldest beyond 5,000, are dropped and come back as ADDED if they reappear.
• Run one monitor at a time. Two runs with the same monitorId at the same moment overwrite each other's record, and some listings are then reported again.
• RUN_SUMMARY.monitor gives the counts: added, changed and unchanged.

What this Actor does differently

• One schema for every portal. A Rightmove row and an OnTheMarket row (and a Zoopla row, when Zoopla is available) have the same field names, so you can join and compare them without mapping. Sold prices and the planning flags use the same style.
• You are charged for rows you receive. A run that is blocked, or finds nothing, has no listing, add-on or run-start charge (a monitoring run that read listings pays its run start; see Monitoring). Each row is charged by event (a listing, plus a detail page or add-on if you ask for one), and the pricing table below says exactly which.
• Filters are the ones you set. If a portal cannot take a filter, the Actor says so in RUN_SUMMARY (filterNotes) and tells you what it did instead; it does not apply a price or bedroom limit you did not ask for.
• Blocks are reported, not hidden. A blocked run says so in its status and in RUN_SUMMARY; it never returns placeholder rows.

First run

The Console form opens with Leeds in Locations and maxItems 10, so pressing Start runs the example below. The API defaults are unchanged: with no location a run searches London, and maxItems is 40.

Paste this input into the Console, or send it through the API, to get ten Leeds listings from Rightmove:

{
  "locations": ["Leeds"],
  "maxItems": 10
}

On the free plan that costs about $0.0175 (10 listings at $0.00125 plus the $0.005 run start). Each row has the price, address, bedrooms, property type, agent as a business, and the listing URL. Add "portals": ["rightmove", "onthemarket"] to search both, or "includePlanningConstraints": true for the planning flags.

Cost: a default run (40 London listings from Rightmove) costs about $0.055 on the free plan: $0.00125 a listing plus $0.005 to start; paid plans pay less. A run that returns nothing, for example a blocked one, has no listing, add-on or run-start charge, except a monitoring run that read listings (see Monitoring).

Mode	What it does	A question it answers	You give it
search (default)	Listings from place names or pasted search URLs, with price, bedroom and type filters	"What is for sale in Leeds under £400,000?"	locations (or searchUrls), portals, filters
listing	One row per listing URL, always with detail fields (EPC, tenure, council tax band, price history where the portal shows them); detail pages are charged too	"What are the tenure and council tax band of this listing?"	listingUrls
sold-prices	HM Land Registry sale history for an area, at postcode level, England and Wales (Rightmove only)	"What did homes in LS6 sell for in the last 5 years?"	locations (a place or outcode), soldWithinYears

The same run can add planning constraints: "Is this listing in a conservation area?" (includePlanningConstraints, England only).

An example row in the Rightmove shape (shortened to its core fields; values are illustrative):

{
  "portal": "rightmove",
  "listingId": "93988728",
  "url": "https://www.rightmove.co.uk/properties/93988728",
  "listingType": "for-sale",
  "price": { "value": 2495000, "currency": "GBP", "qualifier": null, "period": null },
  "address": "Parklands Drive, London, N3",
  "outcode": "N3",
  "latitude": 51.590223,
  "longitude": -0.207787,
  "propertyType": "Detached",
  "beds": 6,
  "baths": 5,
  "agent": { "name": "Goldschmidt & Howland", "branch": "Temple Fortune - Sales" },
  "publishedAt": "2026-10-06T15:34:47Z",
  "scrapedAt": "2026-10-06T16:02:11Z"
}

What you get

• For-sale and to-rent listings from Rightmove, sourced from search results or direct listing pages, on one schema — see "Portal differences" below for what varies by site. OnTheMarket (for sale, to rent and new homes) is opt-in; see "OnTheMarket" below. Zoopla is not available at the moment.
• Optional detail fields — EPC rating, floor area, tenure, council tax band, UPRN, price history, description, features, floor plans — fetched from each listing's detail page. Not every field is populated on every portal; see "Portal differences".
• Optional planning constraints for each listing's coordinates, sourced from the UK government's planning data service (England only). Works the same on every portal.
• Optional nearby planning applications for each listing — reference, description, decision state and a link to the council's page — from a copy of PlanIt's UK planning data. The copy is not being refreshed at the moment, so this add-on answers unavailable (not charged) until it is. See "Planning applications" below.
• Sold prices (Rightmove only) — HM Land Registry sale history for an area, one row per sold property at postcode level (no street address, listing link or Rightmove id) — see "Sold prices (Rightmove)" below.

Group	Fields
Core (every row)	portal, listingId, url, listingType, status, price (value, currency, qualifier, period), address, outcode, latitude/longitude, coordinatesSource, propertyType, beds, baths, receptions, newHome, chainFree, retirement, sharedOwnership, agent (name, branch, phone, url), publishedAt (the date the portal first showed the listing, where it says), priceReduced, reductionReason, reducedOn (where the portal says the price was reduced; null means the portal did not say, not that the price was never reduced), lastUpdatedAt (Rightmove only; null on OnTheMarket, and on Zoopla when it is available), scrapedAt
Detail (with includeDetails, or listing mode)	postcode, floorAreaSqft, tenure, leaseholdYears, councilTaxBand, epcRating, uprn, priceHistory, description, features, images, floorPlans
Derived: floor area in square metres	floorAreaSqm: floorAreaSqft divided by 10.7639, to 1 decimal place; null when floorAreaSqft is null or 0
Derived: price per square foot	pricePerSqft: price.value divided by floorAreaSqft, in whole pounds, on for-sale and new-homes rows only. A row with no price qualifier, or with guide price, asking price, offers over, offers in excess of, offers in region of or fixed price, gets a value; null for rentals, shared ownership, any other qualifier, or a missing or zero price or floorAreaSqft. Only as accurate as the floor area the portal shows
Planning constraints (add-on)	planning.constraints (conservationArea, listedBuilding, floodRiskZone, greenBelt, article4, treePreservationZone), planning.coverage, planning.checkedAt
Planning applications (add-on)	planning.applications (each with reference, authority, address, description, state, type, receivedAt, decidedAt, distanceMetres, url, sourceUpdatedAt), planning.coverage.applicationsCoverageFrom, planning.coverage.applicationsTruncated, planning.coverage.applicationsNote (what the applications data is and is not)

Image and floor-plan links (images, floorPlans) are hosted by the portals or their content delivery networks; the images belong to the portals and agents, not to us.

When to use it, and when not to

Use it to:

• Get a list of homes for sale or to rent for a place or from search pages you supply, on one schema across Rightmove and OnTheMarket (Zoopla is not available at the moment).
• Fetch the full detail of listing pages you already have (mode: "listing"): EPC rating, tenure, council tax band, floor area and more, where the portal shows them.
• Recent sales for an area from Rightmove's sold-price pages (sold-prices mode), one row per property at postcode level.
• Add planning constraints (England) to each listing's location.

Do not use it for:

• Commercial listings (they are skipped), or a crawl of a whole site: a run returns at most 1,000 rows.
• Street-level sold prices: sold-price rows have no street address, listing link or Rightmove id.
• Planning applications right now: they come from a copy of PlanIt's data that is not being refreshed at the moment, so the add-on answers unavailable and is not charged.
• Vendor or landlord details: none are collected. The agent object holds what the portal shows for the marketing branch: the agency's brand or company name, the branch name, the branch's business phone number and the branch's page on the portal. Some agencies trade under a person's name, and listing descriptions are the agent's own text.
• Current availability: a listing can be sold or let after your run. Each row carries scrapedAt.

Use cases

• Track asking prices and new listings in an area on a schedule (see "Recipes").
• Compare the same area across Rightmove and OnTheMarket in one schema (and Zoopla, when it is available).
• Collect EPC rating, tenure, council tax band and floor area for a list of listing URLs.
• Check conservation area, flood risk zone, green belt, Article 4 and listed-building constraints for a list of homes in England.
• Compare asking prices with recent sold prices in the same area (sold-prices mode).

Input

There are three ways to run the Actor.

1. Paste a search URL. Filter and search on the Rightmove website, then paste the address-bar URL — the Actor routes each one to its own portal by host. For OnTheMarket, paste an unfiltered area search (see "OnTheMarket"):

{
  "mode": "search",
  "searchUrls": [
    "https://www.rightmove.co.uk/property-for-sale/find.html?locationIdentifier=REGION%5E87490"
  ]
}

Accepted Rightmove search URLs: /property-for-sale/find.html?… and /property-to-rent/find.html?…, plus the plain area pages such as /property-for-sale/London.html. Rightmove listing URLs are /properties/<id>.

Accepted OnTheMarket search URLs: /for-sale/property/<place>/, /to-rent/property/<place>/ and /new-homes/property/<place>/, unfiltered. OnTheMarket listing URLs are /details/<id>/.

2. locations with filters and portals. Give place names or postcodes; portals decides which site(s) they run on:

{
  "mode": "search",
  "locations": ["Leeds"],
  "portals": ["rightmove"],
  "listingType": "to-rent",
  "minBeds": 2,
  "maxItems": 100
}

3. listingUrls in listing mode. Fetch specific listings directly, on any portal — again routed by host.

Points to know before you run:

• portals defaults to ["rightmove"] and controls which site(s) locations and the default search run on. Add "onthemarket" to include OnTheMarket; it is not in the default run. Pasted searchUrls/listingUrls ignore portals and go to their own portal by host, as above. Zoopla is not available at the moment: a run that asks for it, by portals or by a pasted Zoopla URL, reports Zoopla as skipped in RUN_SUMMARY, has no listings or add-ons charged for it, and its share of maxItems passes to the other portals. A run that asks only for Zoopla ends as succeeded with nothing pushed, RUN_SUMMARY.status set to refused and the reason in the status message. Because that run succeeds, it will not trigger a failure alert on your side: check RUN_SUMMARY.status.
• With nothing entered, one small London search runs on each selected portal. Enter locations to search elsewhere, or narrow portals to one site.
• 1,000-listing ceiling per run, shared across portals. maxItems defaults to 40; each selected portal gets an equal share, and a portal that runs out of results passes the rest of its share to the others. 0 means "up to the ceiling". Rightmove caps out around 1,000 results per search (its own limit) and OnTheMarket at 1,020 (34 pages of 30); Zoopla, when it is available, shows at most 40 pages of about 25. These caps may stop a large run earlier than the ceiling.
• listingType: "new-homes" works with locations on OnTheMarket only. (Zoopla, not available at the moment, took it from a pasted /new-homes/ search URL.) Rightmove skips locations entirely when new-homes is selected, with the reason in RUN_SUMMARY, and new-homes with nothing to search (no locations and no search URL) searches nothing on any portal; a run that asks for nothing else ends as succeeded with RUN_SUMMARY.status set to refused and nothing pushed and no listings or add-ons charged (pasted Rightmove URLs are unaffected). Because that run succeeds, it will not trigger a failure alert on your side: check RUN_SUMMARY.status.
• In listing mode, detail pages are always fetched and charged. includeDetails is ignored there; you get the full detail-page fields on every URL you pass. Each URL returned is charged as a listing ($1.25 per 1,000) plus a detail page ($1.25 per 1,000), so $2.50 per 1,000 URLs ($0.0025 each) on the free plan, plus the $0.005 run start; paid plans pay less. For example, 100 listing URLs cost about 100 × $0.0025 + $0.005 ≈ $0.26.
• Filters (minPrice, maxPrice, minBeds, maxBeds, propertyType, radiusMiles, addedSinceDays) apply only when locations is used, on every portal. All six property types (detached, semi-detached, terraced, flat, bungalow, land) are mapped on Rightmove (and on Zoopla, when it is available). On OnTheMarket the Actor applies the price, bedroom and property-type filters itself, ignores radiusMiles with a note, and skips a location when addedSinceDays is set or propertyType is land, with a note (see "OnTheMarket"). A pasted searchUrls entry carries whatever filters you set when you copied it (OnTheMarket URLs are accepted only unfiltered). addedSinceDays uses each portal's own windows: Rightmove's 1, 3, 7 or 14 days (Zoopla, not available at the moment, uses the last 24 hours or last 7 days). On Rightmove, radiusMiles uses its own steps (0.5, 1, 3, 5 or 10 miles). Any other value is rounded down to the nearest window or step, with a note in the log and in RUN_SUMMARY (filterNotes, per portal, for scheduled runs to check), so a search is only ever narrower than asked, never wider: for example, on Rightmove 5 days is the last 3 days and 30 days is 14 days (on Zoopla, when it is available, they are the last 24 hours and 7 days). A pasted Rightmove search URL keeps its own filters. Four of them, tenureTypes, mustHave, dontShow and keywords, are passed through to Rightmove as-is, exactly as they appear in your URL, and are not verified by this Actor. Any other parameter it cannot keep is named in the log and in RUN_SUMMARY (ignoredUrlParams).

Output

One row per listing. The sample below is an example row, shortened, with the planning block taken from a different listing to show its shape. This example row was taken from Zoopla, which is not available at the moment, and is kept to show the field layout; Rightmove and OnTheMarket rows use the same schema — see "Portal differences" and "OnTheMarket" below for what's always null and where detail fields come from:

{
  "portal": "zoopla",
  "listingId": "74318505",
  "url": "https://www.zoopla.co.uk/for-sale/details/74318505/",
  "listingType": "for-sale",
  "status": "available",
  "price": { "value": 108750, "currency": "GBP", "qualifier": null, "period": null },
  "address": "Dunedin Road, London E10",
  "postcode": "E10 5NL",
  "outcode": "E10",
  "latitude": 51.557804,
  "longitude": -0.012582,
  "coordinatesSource": "listing",
  "propertyType": "flat",
  "beds": 2,
  "baths": 2,
  "floorAreaSqft": 797,
  "tenure": "leasehold",
  "leaseholdYears": 119,
  "councilTaxBand": "C",
  "epcRating": "B",
  "uprn": "10093560110",
  "priceHistory": [],
  "sharedOwnership": true,
  "agent": {
    "name": "Newlon Living",
    "branch": "Resales",
    "phone": "020 3463 1588",
    "url": "https://www.zoopla.co.uk/new-homes/developers/branch/newlon-living-resales-hale-village-105696/"
  },
  "scrapedAt": "2026-09-24T13:13:54Z",
  "planning": {
    "applications": null,
    "constraints": { "conservationArea": null, "listedBuilding": null, "floodRiskZone": "2", "greenBelt": false, "article4": false, "treePreservationZone": false },
    "coverage": {
      "applications": "not-requested",
      "constraints": "planning.data.gov.uk",
      "constraintsCoverageNote": "England only; official datasets are incomplete, so absence is not proof of no constraint; listedBuilding means a listed building or structure within 25 m, not that this property is listed"
    },
    "checkedAt": "2026-09-24T14:22:00Z"
  }
}

Notes on the data:

• Rentals carry the price and period as the portal displays them (typically pcm). On Zoopla (not available at the moment) some listings show no period at all: its own "fixed price" rentals.
• priceHistory on Zoopla (not available at the moment) is a list of change events with dates only ("price-drop", "price-rise"); Zoopla does not show the amounts, so price is always null in each entry.
• agent is the marketing branch handling the listing: the agency's business details (some agents trade under a person's name).

Portal differences

Zoopla is not available at the moment; its column below describes how it behaved and is kept for when it returns. When Zoopla is available it returns the same schema as Rightmove; a handful of fields behave differently by source (OnTheMarket's differences are in its own section below):

Field	Zoopla (not available at the moment)	Rightmove
uprn	From the detail page	Always null — not published on any Rightmove page
priceHistory	Change events, dates only	Always [] — Rightmove shows no price history
epcRating	A letter, from the detail page	Always null — Rightmove only shows the EPC as an image, never as text
status	available / under-offer / sold-stc / let-agreed, from search results	Always null — no reliable status signal on Rightmove pages
newHome	Set where Zoopla shows it	Set for Rightmove new-homes developments
Full postcode, tenure, lease years, floor area, council tax band, floor plans, images, description, key features, agent (brand, branch, business phone)	From the detail page with includeDetails	Same — all come from the Rightmove detail page with includeDetails

agent is the marketing branch: the agency's brand or company name, branch name, business phone number and page on the portal, as the portal shows them; some agencies trade under a person's name. The Actor does not add or look up personal data about agents; the strings are the portal's own.

OnTheMarket

OnTheMarket is opt-in: add "onthemarket" to portals. The default is ["rightmove"].

What works

• For-sale, to-rent and new-homes listings, on the same schema.
• Pasted search URLs: an unfiltered area search such as https://www.onthemarket.com/for-sale/property/leeds/ (also /to-rent/property/<place>/ and /new-homes/property/<place>/).
• Typed locations: a place name or an outcode such as SW18, resolved with OnTheMarket's own place lookup. When a name matches several places, the Actor uses the one whose OnTheMarket id is the plain name, if there is one (for "Leeds", leeds). If none is, that location is skipped, with a note in the log and in RUN_SUMMARY (filterNotes) listing the choices (as many as fit), so you can paste the search URL for the right place. A name that matches nothing fails that location.
• Listing URLs: https://www.onthemarket.com/details/<id>/.

Filters

• minPrice, maxPrice, minBeds, maxBeds and propertyType are applied by the Actor to the rows it fetches, not by OnTheMarket: its robots.txt disallows its own filter parameters, so the Actor never sends them.
• OnTheMarket shows at most 1,020 results (34 pages of 30) per search, and the filters apply after that cap. A narrow filter over a large area therefore returns fewer rows than on the other portals; a smaller area, such as an outcode, is less likely to reach the cap.
• These filters apply to locations only. A pasted OnTheMarket URL is always unfiltered, and they are not applied to it.
• With propertyType set, a row is kept only when OnTheMarket's own type maps to it. Types that map to none of the six (seen: "House", "House share", "Cottage") are never kept. land has no OnTheMarket type the Actor can match, so an OnTheMarket location with propertyType: land is skipped, with a note in the log and in filterNotes. With a bedroom filter set, a row with no bedroom count is dropped (a studio counts as 0).
• A filtered search stops after 3 pages in a row with no matching rows, with a note in the log and in filterNotes. It does not page on through all 34 for nothing, so a filter that matches only rows far down the results can be missed.
• RUN_SUMMARY filterNotes records that the filters were applied by the Actor, to at most 1,020 rows. When a search is read to its end, the run log also says how many of the fetched rows were kept.
• radiusMiles is not supported: it is ignored, with a note in filterNotes. addedSinceDays is not supported either, and ignoring it would search wider than you asked (and charge for every row), so an OnTheMarket location with addedSinceDays set is skipped, with a note in the log and in filterNotes, not searched wider. Other portals in the same run are unaffected.
• A pasted OnTheMarket search URL that carries OnTheMarket's own filter parameters (any query parameter other than page) is not accepted. It is reported as unrecognised (unrecognisedUrls in RUN_SUMMARY) and not fetched.

Field differences

• Always null: epcRating (OnTheMarket shows the EPC only as an image), status, uprn, chainFree, retirement, publishedAt and receptions. priceHistory is always [].
• tenure, leaseholdYears, councilTaxBand, floorAreaSqft, description, floorPlans and newHome come only with includeDetails (always fetched in listing mode); search results carry none of them. councilTaxBand is set only when the page shows a band.
• postcode comes from the listing page, only when the page confirms it is the same listing and gives a valid full postcode; otherwise it is null. outcode is taken from it, so both are null without includeDetails.
• propertyType is one of the Actor's six types where OnTheMarket's own label maps to one, and OnTheMarket's own text otherwise (for example "House" or "Cottage"). This differs from Rightmove, which passes its own text through (as does Zoopla, when it is available).

Pricing and limits. The same events and prices as the other portals. maxItems is shared across all selected portals, each getting an equal share.

Planning constraints

The add-on looks up constraints at each listing's coordinates from the UK government's planning data service, which covers England only.

• conservationArea — name(s) of any conservation area covering the point.
• listedBuilding — the nearest listed building or structure within 25 metres of the listing's coordinates, with its name, grade, and list reference. This does not mean the property itself is listed: the dataset holds listed buildings as points, not building outlines, so the nearest point within range can be anything nearby — for example, a listed lamp post rather than the house itself.
• floodRiskZone, greenBelt, article4, treePreservationZone — whether the point falls in a flood risk zone, the green belt, an Article 4 direction area, or a tree preservation zone.

The government datasets are known to be incomplete, so a missing constraint is not proof that none exists. Outside England, planning.coverage.constraints is set to "not-covered" and nothing is charged for that listing.

Planning applications

Set includePlanningApplications to add the planning applications near each listing: those within planningRadiusMetres (150 m by default, 25–500) received in the last planningYears (1 by default, up to 3). For each one you get the reference, council, address, description, decision state, type, received and decided dates, distance from the listing, and a link to the council's own page. Up to the 100 nearest are returned, nearest first; planning.coverage.applicationsTruncated says when there were more. Descriptions are the council's text: a capitalised name directly after a title such as Mr, Mrs or Dr is redacted, but other free text is not scanned, so a description can still mention a person. Applicant, agent and officer fields are never requested from PlanIt. Site addresses and the link to the council's page are included as published.

The applications come from a copy of PlanIt's UK planning data. The copy holds about the last 12 months up to its last refresh, and it is not being refreshed at the moment, so the add-on answers unavailable and is not charged. Applications received before the copy's start date are never included, whatever planningYears is set to, and nor are applications with no received date (they cannot be shown to fall inside the window): every answered row carries that date as planning.coverage.applicationsCoverageFrom, and sourceUpdatedAt on each application says when that record was last copied. When the copy is being refreshed, the newest applications arrive a few days late: it refreshes recent weeks in a rolling cycle, and the add-on counts the copy as out of date if its newest complete day is more than 5 days old, or if its last refresh or last compaction is more than 3 days old. Decisions on applications received more than two months ago can lag by up to a few weeks; sourceUpdatedAt shows when each record was last copied.

"None nearby" is charged, because it is an answer. Where the roughly 1 km grid cells around a listing hold applications from a council PlanIt collects, a listing with none within the radius costs the same as one with many. It is never charged when the copy is out of date or cannot be read, or when those grid cells hold no applications from a council that counts (county councils and other non-local planning bodies do not) (see the next paragraph): those listings show planning.coverage.applications: "unavailable" or "not-covered" and are free.

Areas PlanIt does not collect are free. The copy keeps a list of the councils PlanIt is currently collecting (a council counts when PlanIt's latest date for it is within the last 90 days). The councils of the applications held in the roughly 1 km grid cells around the listing decide, all of them, not only those within the radius; county councils and other non-local planning bodies don't count as the local council. If any of those councils is currently collected, the listing is answered (and charged) as above. If none is, the listing shows planning.coverage.applications: "not-covered", with no applications, and is not charged. It means PlanIt does not currently collect that area, not that nothing has been applied for there. When those cells hold no applications from a council that counts (for example a council PlanIt lists but has nothing for), the listing is never charged: the 10 km grid square around it is checked, and if it has no applications from a council PlanIt is currently collecting the listing is "not-covered", and otherwise "unavailable". Until the copy has finished indexing every area (and whenever the council list cannot be read, is out of date or looks wrong), an older rule applies instead, and no listing is answered "not-covered": the listing is charged only when the copy holds at least one application in the grid cells around it, even outside the radius; if it holds none, the listing shows "unavailable" and is free. Near a council boundary this check can't tell councils apart within about 1 km: if a covered neighbour's applications are in the grid cells around the listing (each about 1 km across), the listing counts as covered and is answered (and charged) even when its own council isn't one PlanIt collects.

Sold prices (Rightmove)

Set mode: "sold-prices" for HM Land Registry sale history instead of current listings — Rightmove only. One row per sold property, at postcode level: no street address, no Rightmove listing link, no Rightmove property id, and no coordinates taken from Rightmove.

This is a licensing choice, not a technical limit. The sale prices and dates are HM Land Registry's Price Paid Data, open under the Open Government Licence, but the addresses attached to them come from Royal Mail's address file via Ordnance Survey, and that licence permits the address data only for personal/non-commercial use or for display in a residential price-information service; any other use, such as handing addresses out in a dataset, needs Royal Mail's permission. So a row carries only the postcode, and its coordinates are the postcode's own centroid (open data), never the property's. A postcode averages about 15 addresses, though a few cover only one — treat a row as postcode-level data, not as anonymous.

Each row carries:

• propertyId — an id for the property (a keyed hash of Rightmove's own id, never that id itself or the listing link it would rebuild). It stays the same from run to run for as long as Rightmove keeps its own id for the property.
• postcode, outcode.
• latitude/longitude, coordinatesSource: "postcode-centroid" — the postcode's centroid from postcodes.io; both null when the postcode can't be placed (the row still ships, since its price data is present).
• propertyType (detached, semi-detached, terraced, flat, other), beds, baths.
• lastSoldPrice, lastSoldDate — the most recent sale.
• sales — every recorded sale since 1995, newest first: price, currency (always GBP), date, tenure, newBuild.
• area — the area searched, { name, type }.
• landRegistryUpdatedAt — when HM Land Registry's data was last loaded into the source.
• scrapedAt, portal: "rightmove".

Sample row (illustrative — propertyId shown is a placeholder, not a real hash):

{
  "portal": "rightmove",
  "propertyId": "3f9a1c0e7b2d4a68",
  "postcode": "LS8 4AX",
  "outcode": "LS8",
  "latitude": 53.824937,
  "longitude": -1.510024,
  "coordinatesSource": "postcode-centroid",
  "propertyType": "terraced",
  "beds": 2,
  "baths": 2,
  "lastSoldPrice": 272500,
  "lastSoldDate": "2026-07-31",
  "sales": [
    { "price": 272500, "currency": "GBP", "date": "2026-07-31", "tenure": "freehold", "newBuild": false },
    { "price": 202500, "currency": "GBP", "date": "2019-02-07", "tenure": "freehold", "newBuild": false }
  ],
  "area": { "name": "Leeds", "type": "region" },
  "landRegistryUpdatedAt": "2026-09-17",
  "scrapedAt": "2026-09-25T09:56:09Z"
}

Input. searchUrls and locations are read differently in this mode:

• searchUrls — paste a Rightmove /house-prices/<area>.html URL for a region or an outcode (for example https://www.rightmove.co.uk/house-prices/leeds.html or .../ls6.html); a street, station or postcode page is skipped, with the reason in RUN_SUMMARY. Its soldIn and propertyType filters are kept; any other parameter is dropped and named in RUN_SUMMARY (ignoredUrlParams).
• locations — a place name (resolved through Rightmove's own location search; only region-type matches are supported so far) or an outcode such as LS6. Full postcodes, stations and streets are not supported yet.
• With nothing entered, one small area runs by default: https://www.rightmove.co.uk/house-prices/ls6.html.

Filters, for typed locations only (a pasted URL carries its own):

• soldWithinYears — sales within the last N years. Rightmove's own windows are 1, 2, 3, 5, 10, 15, 20 and 30 years; any other value is rounded down to the nearest window, with a note in the log and in RUN_SUMMARY (filterNotes). Leave it empty for all years back to 1995.
• propertyType — detached, semi-detached, terraced or flat. bungalow and land have no sold-prices equivalent: a location searched with either is skipped, with the reason in RUN_SUMMARY.
• minPrice, maxPrice, minBeds, maxBeds, radiusMiles, addedSinceDays, includeDetails and the planning add-ons don't apply to sold prices; if set, they're named in RUN_SUMMARY (filterNotes) and otherwise ignored. Radius, tenure and sort order aren't offered yet.

Limits. Up to 1,000 rows per area (Rightmove's own cap: 40 pages of 25), and maxItems per run as in the other modes. Each row's sales list is newest first. Coverage is England and Wales only (HM Land Registry): an area whose sales are not HM Land Registry data is skipped before any row is read (nothing charged), and a row whose postcode is outside England and Wales is skipped and counted in RUN_SUMMARY (rowsSkipped.outsideEnglandAndWales). A record whose postcode can't be read from Rightmove's address string is skipped — not output, not charged — and counted in RUN_SUMMARY (rowsSkipped.noPostcode).

Area summary (optional, free)

Set summary (search mode) to rentalYield to get one extra record, SUMMARY, in the run's key-value store. It is built only from the listings this run returned. The listing rows are charged as usual and the summary adds no charge. Figures are by area (outcode): no row names a listing or an address. A figure is left empty under 5 listings. Where a portal gives no outcode, the summary takes it from the postcode nearest to the listing's map position (postcodes.io), so a listing near a boundary can be counted in the neighbouring outcode; the listing rows themselves are unchanged. It does not work with monitorId. These are advertised figures, not valuations and not advice.

• rentalYield. The run searches each location for sale and then to rent. For each outcode and number of bedrooms (0 to 4, and 5+) you get the median asking rent per month, the median asking price and the gross asking yield, before costs. The rows from both searches are listing rows and are charged as usual. maxItems covers both searches: the sale search gets up to half, the rent search the rest. It needs locations and listingType for-sale. It refuses minPrice, maxPrice and pasted search URLs.

Pricing

Pay per event. Platform usage is included in the price — you don't need your own proxy. The same events and prices apply to every listing row, whichever portal it came from, and the planning constraints work the same on all of them (nearby planning applications are currently unavailable). Sold-price rows (sold-prices mode) have their own event and no add-ons.

Event	Charged when	Price
run-start	Once per run, only when the first rows (listings or sold prices) reach your dataset — a run that returns nothing costs nothing. A monitoring run (monitorId) that read listings is charged it even when no listing changed	$0.005 per run
listing	Each listing row returned	$1.25 per 1,000
listing-detail	Each detail page fetched (includeDetails, or always in listing mode)	$1.25 per 1,000
planning-constraints	Each listing where the lookup succeeds for a point in England	$5.00 per 1,000
planning-applications	Each listing where the planning-applications lookup answers, including "none nearby"; not for not-covered or unavailable (see Planning applications)	$10.00 per 1,000
sold-price	Each sold-price row returned (sold-prices mode)	$3.00 per 1,000

Higher Apify plans pay less. Prices by plan, per 1,000 rows (run-start per run):

Event	Free	Bronze	Silver	Gold, Platinum, Diamond
listing	$1.25	$1.125	$1.00	$0.875
listing-detail	$1.25	$1.125	$1.00	$0.875
planning-constraints	$5.00	$4.50	$4.00	$3.50
planning-applications (currently unavailable)	$10.00	$9.00	$8.00	$7.00
sold-price	$3.00	$2.70	$2.40	$2.10
run-start, per run	$0.005	$0.0045	$0.004	$0.0035

For example, 1,000 listings cost about $1.26 on Free ($1.25 plus the run start) and about $0.88 on Gold and above. With details and planning constraints for every listing, 1,000 listings cost about $7.51 on Free and about $5.25 on Gold and above.

Worked examples (Free plan prices; higher plans pay less):

• Default run, 40 listings, no add-ons: 40 × $0.00125 + $0.005 ≈ $0.055.
• 200 listings with details and planning constraints: 200 × $0.0075 + $0.005 ≈ $1.51.
• 100 listing URLs in listing mode (detail pages always included, no add-ons): 100 × $0.0025 + $0.005 ≈ $0.26.

Use Apify's maximum charge per run setting to cap spend on any run. If the platform restarts or moves a run, the run keeps a record of what it already charged: it does not charge the run start or any row twice, and it stays within your maximum charge across the restart. If that record cannot be read after a restart, the run stops before charging anything; Apify's own maximum charge applies as well. A run you resurrect counts as a new run, so its start is charged again, but rows it already returned are not returned or charged again, and it returns at most maxItems minus the rows it already returned.

What a free $5 buys. If your Apify plan gives you $5 of monthly credit, at Free plan prices that is roughly:

• About 3,600 listings (90 default runs of 40 listings at $0.055 each).
• About 1,900 listing URLs in listing mode (19 runs of 100 URLs at $0.26 each).
• About 760 listings with planning constraints (19 runs of 40 listings at $0.255 each).
• Sold prices: about 1,600 rows (two runs of up to 1,000 rows, $3.00 per 1,000 plus $0.005 each).

Paid plans pay less. Use Apify's maximum charge per run setting to cap any single run.

Reliability

If a run is blocked, it says so plainly: the run status and the RUN_SUMMARY record in the run's key-value store report the block, and no listings or add-ons are charged for it. The Actor never emits placeholder or sentinel rows to make a run look successful. For an up-to-date, independently measured success rate, see this Actor's statistics on the Apify Store page rather than any number here.

Rightmove and OnTheMarket requests are each throttled to at most one a second per site, across all of a run's sessions. Rightmove and OnTheMarket use only Apify's datacenter proxy in every run. Residential egress is used only in runs started by the Actor owner's account, and Zoopla, which has no other egress, is not available at the moment in other runs: a run that asks for it reports Zoopla as skipped in RUN_SUMMARY and has no listings or add-ons charged for it. Platform usage is included in the price, so there's nothing for you to configure.

What you can rely on. One schema covers Rightmove and OnTheMarket (and Zoopla, when it is available), so a run across portals needs no per-portal handling. Scheduled check runs are intended to go against each portal about daily, and a run in which every search or listing for a portal fails (for example because the parser can no longer read its pages) is reported as failed with the reason in RUN_SUMMARY and has no listings or add-ons charged; a search that simply has no results is a normal empty result. Pricing is per listing: the run-start fee is charged only once the first rows arrive, each add-on is charged only for the listings where it returns an answer, and Apify's maximum charge per run caps what a run can spend. The limits are explicit: up to 50 search URLs or locations, up to 1,000 listing URLs, at most 1,000 rows per run (maxItems, shared across portals), and each portal's own search results end at about 1,000 (OnTheMarket 1,020). On top of listings, the same run can add planning constraints from the government's planning data service (England only; the data may be incomplete) and nearby planning applications (currently unavailable); a separate sold-prices mode returns HM Land Registry sale history.

Data-quality figures for this Actor's data (identifier coverage, sold-price matching, completeness samples and the results of our own scheduled check runs) are published on the publisher's website, which is linked from this Actor's Apify profile. The success figures on this Store page are Apify's own.

Limits and known gaps

• Some detail fields are only shown for some listings. In particular, on Zoopla (not available at the moment), EPC rating, council tax band, floor area and UPRN are often missing on new-homes listings, and new-homes detail pages carry no full postcode.
• Price-on-application listings have not yet been seen in practice; support for them is unconfirmed.
• When Zoopla is available, its status reflects what search results show, which in practice is available or under-offer. Rightmove rows always carry status: null; see "Portal differences".
• Commercial listings on Rightmove are skipped.
• OnTheMarket shows at most 1,020 results per search, and the Actor's filters apply after that cap; see "OnTheMarket" above.
• Sold prices (Rightmove) are postcode-level only — no street address, listing link or Rightmove id; see "Sold prices (Rightmove)" above. Full-postcode, station and street inputs aren't supported for sold prices yet.

Data and legal

This Actor is not affiliated with or endorsed by Rightmove, Zoopla or OnTheMarket. The Actor requests only logged-out, publicly reachable pages: search results and listing pages for the searches, locations and listing URLs you supply (with no input, one default London search per portal), the portals' own location look-ups, and in sold-prices mode Rightmove's sold-price area pages. If you turn on planning constraints, it also calls the government's planning data service; in sold-prices mode it calls postcodes.io for postcode centroids; and with summary set to rentalYield it sends postcodes.io the map position (rounded) of each listing that has no outcode, to find the nearest postcode's outcode, and nothing else about the listing. Every run is capped at 1,000 rows, so there is no whole-site crawl mode.

If a portal answers with a bot challenge, the Actor retries with a new session, which means new cookies and a different exit IP. For Rightmove and OnTheMarket it uses Apify's datacenter proxy, with one retry on a new session when the answer is a challenge. Residential egress is used only in runs started by the Actor owner's account; there, Zoopla (not available at the moment in other runs) is not retried on a challenge, and the Actor stops for Zoopla at the first one. A plain 429 or 5xx answer is retried up to three times with a delay, honouring Retry-After for up to 60 seconds, and on Rightmove a retry after a 429 or 503 uses a new session (on OnTheMarket, after a 429); then the request is reported as failed. If a challenge or block persists after those retries, the Actor stops for that portal and reports it as blocked or failed in RUN_SUMMARY. It does not try to solve a challenge.

The Actor does not read robots.txt at run time. For Rightmove and OnTheMarket, the address of every request is checked before it is sent against a stored copy of the site's robots.txt (taken on 25 Sep 2026 for Rightmove and 27 Sep 2026 for OnTheMarket), and a request the copy disallows is not sent; a later change on the site is not seen until the copy is updated, and OnTheMarket's own filter parameters are never sent for that reason. For Zoopla (not available at the moment), the Actor sends only the request forms captured from the site's own pages, and its requests are not checked against robots.txt. robots.txt is not permission and it is not a site's terms: the websites' terms of use apply, and you remain responsible for complying with them. The Actor writes only to the run's own dataset and RUN_SUMMARY record in your account; when the planning-applications add-on is live, it reads a copy held in our key-value store and only reads it.

On personal data: agent details are the marketing branch's business details (branch name, office phone, URL). Listing descriptions are the agent's own text and can occasionally mention a member of staff. No vendor or landlord details are collected. Applicant, agent and officer fields are never requested from PlanIt; application descriptions are the council's own text with capitalised names directly after a title (Mr, Mrs, Dr and so on) redacted and other free text not scanned, so they may still mention a person; site addresses and the link to the council's page are included as published.

Planning constraints contain public sector information licensed under the Open Government Licence v3.0 (the UK government's planning data service). Planning applications courtesy of PlanIt (planit.org.uk).

Sold prices (Rightmove) contain HM Land Registry data © Crown copyright and database right 2026. This data is licensed under the Open Government Licence v3.0. Postcode centroids: contains OS data © Crown copyright and database right 2026. Contains Royal Mail data © Royal Mail copyright and database right 2026. Source: Office for National Statistics licensed under the Open Government Licence v.3.0. The same notice applies to the outcodes the area summary takes from the nearest postcode.

You are responsible for your own use of the data and for complying with applicable terms and law.

Recipes

Run it on a schedule. In the Apify Console, save your input as a task, then add a schedule to the task with a cron time, for example 0 7 * * * for 07:00 every day. A new schedule starts disabled, so enable it. For a daily list of what was added, use locations with addedSinceDays: 1 (not available for OnTheMarket).

Get only new and changed listings every day. In the Apify Console, save a task with your search (for example locations set to Leeds and minBeds set to 2) and a monitorId such as leeds-2-bed-daily. Add a schedule to the task with a daily cron time, for example 0 7 * * *, and enable it. The first run returns every listing as ADDED. Each later run returns only listings that are new (ADDED) or changed (CHANGED), and only those rows are charged. Keep the search the same and use the monitorId on one schedule only (see Monitoring).

Ask an AI assistant to do it. If your AI assistant can run Apify Actors, give it the search and the monitorId in plain words. For example: "Run the UK property listings Actor in search mode with locations Leeds, listingType for-sale, propertyType flat, minBeds 2, maxBeds 2, maxItems 300 and monitorId leeds-2-bed-flats. List the rows with changeType ADDED as new listings, and for CHANGED rows say which fields changed." The first run returns every matching listing as new. Ask again the next day and it returns only what is new or changed since the last run with that monitorId.

Get a webhook when a run finishes. In the task's Integrations tab, add a run-succeeded webhook (ACTOR.RUN.SUCCEEDED) and give it your own HTTPS address. The default payload includes userId, createdAt, eventType, eventData and resource; the dataset id is resource.defaultDatasetId, which your code can then read with the Apify API.

Run daily and compare. Without a monitorId, the Actor does not remember earlier runs. Schedule a daily task, keep each day's dataset, and compare two days in your own code or spreadsheet by portal and listingId: ids only in today's dataset are new, ids only in yesterday's are gone from the results, and a different price.value is a price change.

FAQ

Do I need my own proxies? No. Apify Proxy is used as needed and included in the event pricing.

Which portal is used? Whichever site(s) you list in portals (default: Rightmove; add onthemarket to include it) — it applies to locations and the default search. Pasted searchUrls and listingUrls always go to their own portal, detected from the host.

Why are some Rightmove fields empty? Rightmove doesn't publish everything Zoopla shows (Zoopla is not available at the moment): uprn and priceHistory are always null/[] on Rightmove rows, and epcRating is always null because Rightmove only shows the EPC as an image, never as text. status is always null too. See "Portal differences" above.

Why did a run charge no listings or add-ons? It returned no rows (for example, it was blocked). run-start is only charged once the first rows reach your dataset, so an empty run has no listing, add-on or run-start charge. The one exception is a monitoring run that read listings but found no change: it pays the run start only.

Can I monitor new listings daily? Yes. Set a monitorId and schedule the same search daily: each run returns only new and changed listings (see "Monitoring"). Without a monitorId, schedule the Actor from the Apify Console with locations and addedSinceDays: 1 (a daily run) or 7 (a weekly one); each scheduled run only charges for what it finds. Other values are rounded down to each portal's nearest window (see Input). OnTheMarket cannot apply addedSinceDays, so with it set an OnTheMarket location is skipped, with a note, instead of being searched wider; the other portals in the run are unaffected.

Why are some OnTheMarket fields empty? epcRating, status, uprn, chainFree, retirement, publishedAt and receptions are always null on OnTheMarket rows, and priceHistory is []; tenure, lease years, council tax band, floor area and postcode need includeDetails. See "OnTheMarket" above.

What does listedBuilding mean? The nearest listed building or structure within 25 metres of the listing — not that the listing itself is listed. See "Planning constraints" above.

Changelog

See the Changelog tab for release notes.

Ratings and reviews

Ratings and reviews on the Store page help other buyers judge whether this Actor fits their use, whatever your experience.

Publisher

From Yappman Data, a trading name of Abley-Yapp Consulting Limited. Contact: info@yappman.com.

Other Actors from the same publisher on the Apify Store: UK Grocery Prices: Tesco, Sainsbury's, Asda, Aldi; Aldi Australia Price Scraper: Shelf Prices & Special Buys; Hotel Prices from Google Hotels: Vendor Rates, History; UK Contracts Finder and Find a Tender Scraper: Gov Contracts; LEI Lookup: Legal Entity Identifier Search by Name or Status; UK Importers and Exporters: HMRC Trade Data.