Apartments.com Scraper - Rentals, Rents & Contacts avatar

Apartments.com Scraper - Rentals, Rents & Contacts

Pricing

Pay per event

Go to Apify Store
Apartments.com Scraper - Rentals, Rents & Contacts

Apartments.com Scraper - Rentals, Rents & Contacts

Scrape rental listings from apartments.com. Property name, full address, beds, starting rent, amenities, photo counts and the leasing phone number, with optional coordinates and rent ranges per building.

Pricing

Pay per event

Rating

0.0

(0)

Developer

SR

SR

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

2 days ago

Last modified

Categories

Share

Apartments.com Scraper

Rental listings from apartments.com as a clean table. Give it a city and get back every property on the market there: the building name, the full address, the bed range, the starting rent, the amenities, how many photos the listing has, and the leasing office's phone number.

It handles two ways of asking. Locations takes apartments.com's own slug, like new-york-ny or austin-tx, and walks the result pages for you. It also takes a full search URL, so if you have already narrowed a search in the browser to one bedroom under $2,000 with parking, paste that URL and the actor respects every filter in it. Specific properties takes property page links instead, which is the mode for re-checking the same buildings on a schedule.

Rent is reported the way the site reports it

This matters more than it sounds. Most listings show a rent like $5,074+, which means "from", because the building has several floor plans at different prices. Flattening that to 5074 turns a starting price into a price, and nobody notices until a rent comparison is quietly wrong.

So every row carries three fields instead of one:

  • rent_text is exactly what the site displays, plus sign and all
  • rent_from is that number, for sorting and filtering
  • rent_is_from is true when the displayed figure is a starting price

Turn on Follow each listing and you also get rent_min and rent_max, the real range across that building's units, plus its coordinates and the names of the floor plans on offer. That costs one extra request per listing, so a hundred-listing run takes noticeably longer, but it is the difference between "from $5,074" and "$5,074 to $6,483".

What a row looks like

  • listing_id, url, name — the property
  • address, street_address, country_code — where it is
  • beds — the bed range as displayed, Studio through 4 Beds
  • rent_text, rent_from, rent_is_from
  • amenities — what the card advertises, such as pets allowed, pool, in-unit laundry
  • has_specials — whether a move-in offer is being advertised
  • phone — the leasing number
  • photo_count — how many photos the listing carries
  • is_featured — whether apartments.com is promoting the listing
  • search, search_page, position — where in the run it came from

With Follow each listing on, each row also gains latitude, longitude, rent_min, rent_max, unit_models, unit_count, and two flags saying whether that property publishes a fees section and a nearby-schools section.

Some fields are legitimately empty. A card with no advertised amenities has none, and a small handful of promoted placards carry no price at all. Those come back null rather than being filled in with a guess.

Run sizes and paging

Result pages hold forty listings each and a busy city has well over a hundred pages, so two inputs keep a run bounded. Maximum listings is the overall cap across every location. Maximum pages per location is the safety rail that stops one enormous city from consuming the whole run.

Because listings arrive forty at a time, asking for 50 fetches two pages and trims. Asking for 45 costs exactly the same as asking for 80.

A hundred listings without following detail pages takes a few seconds. The same run with Follow each listing on takes a few minutes, because it is a hundred more page loads. Default memory of 1 GB is comfortable either way.

When something cannot be read

A location or page that fails becomes an entry in the errors record rather than a missing row:

CodeMeaning
bad_inputNo location or property URL was supplied
no_resultsThe location was read and genuinely has no listings
fetch_failedA result page could not be read after several attempts
detail_failedA property page could not be read

no_results and fetch_failed are deliberately different. An empty city and a page that would not load look identical if you only count rows, and telling them apart is the difference between "nothing to rent there" and "we do not know".

A note on reliability

Route access to this site is narrow, and it can change without warning. If a run suddenly returns fetch_failed across the board where it worked last week, that is what has happened; it is not a bad location or a transient error. Re-run once, and if it persists, say so and it will be looked at rather than patched around.

For the UK rental and sale market, use Rightmove Scraper. For US listings for sale rather than rent, use Zillow Scraper or Redfin Scraper.