Is There an Apartments.com API? How to Get Rental Data

The search starts hopefully. There is a host at api.apartments.com, it resolves, and for about four seconds you believe you have found a developer portal nobody blogged about. Then you actually request it and get back 403 Forbidden. So you try the polite thing and ask for robots.txt instead. Also 403. The edge in front of Apartments.com will not even tell an unrecognized client what it is allowed to crawl.

That is the whole situation in one exchange. Here is the honest answer to whether an Apartments.com API exists, the two official doors that genuinely do exist (neither one gives you listings), the legal detail that every scraper tutorial skips, and the part you can actually run today.

The short answer

No. Apartments.com has no public listings API. There is no developer portal, no signup, no sandbox, no documented endpoints. Apartments.com is owned by CoStar Group, and CoStar's entire business is selling access to real estate data. A free listings firehose would compete with the thing CoStar sells.

What does exist is a pair of official integrations that both run inbound: they let you send listings to Apartments.com. Neither one lets you read the marketplace. We'll cover both, because knowing they exist saves you a week of emailing the wrong department.

Why Apartments.com doesn't hand out API keys

Apartments.com is not a listings site that happens to carry rentals. For multifamily in the US, it largely is the market. By its own account the Apartments.com Network reaches over 43 million monthly renters, carries more than 85,000 advertising properties, and sits on CoStar research covering more than 34 million apartment units nationwide.

Those 85,000 advertising properties are the answer. Owners and managers pay Apartments.com for placement in front of renters. Placement only has value if it is scarce. An open API that let anyone pull every listing, rank it themselves, and build a competing search experience would take a paid advertising product and turn it into a commodity feed. No portal does that voluntarily, and the ones that tried mostly stopped. It's the same structural reason StreetEasy has no public API, just with a bigger advertiser base behind it.

So the API you want is not late, or in beta, or gated behind a form. It is not being built.

The two official doors that do exist

1. Syndication feeds (listings in, nothing out)

If you run a property management system and want your clients' units to appear on Apartments.com, there is a real, supported path: you get onboarded as a feed partner. The published instructions for the major PMS platforms all converge on the same address. In the AppFolio walkthrough, for example, you mark units for posting, then email [email protected] with your property's integration ID, and Apartments.com states the connection takes 24 to 48 hours to complete.

This is genuinely useful if you are a supply-side product. It is completely useless if you want to read the market, because data flows one way. You can publish your own listings. You cannot see anyone else's.

2. Customer APIs behind an account rep

Apartments.com references customer-facing APIs for existing advertisers, with access arranged through your service representative rather than a public signup. That is a fair model for a paying client who wants lead delivery wired into their CRM. It is not a data source: it is scoped to the account's own properties and leads, and there is no self-serve route in. If you don't already have a rep, you don't have a door.

Worth naming plainly, since search results muddy this: every product on the open web calling itself an "Apartments.com API" is a third-party service reading the public site. Some are good. None are official, and none of them are endorsed by CoStar.

The part the scraper tutorials leave out

Search "apartments.com api" and you get a dozen guides that teach CSS selectors and a proxy rotation strategy. Almost none of them mention who owns the site, and that omission matters more here than on any other portal.

Start with the terms. The Apartments.com Terms of Service prohibit using "any robot, spider or other automatic device, or a manual process, to access, monitor or copy web pages or the Materials contained in the Site." Note that it covers the manual process too. That language is broad on purpose.

Then look at how CoStar behaves when it thinks its content has been copied. By its own account of its litigation, on July 30, 2025 it filed a copyright infringement suit against Zillow in federal court in New York over almost 47,000 photographs, a case it calls “one of the largest image infringement lawsuits in history” and says could expose Zillow to more than $1 billion in damages. Trade reporting in March 2026 put the amended complaint at roughly 53,000 images, centered on multifamily rental listings, with the photographs originating from Apartments.com.

A second case shows the same posture against a smaller target. CoStar sued the commercial marketplace CREXi in 2020, and on June 25, 2025 the court found that CREXi had copied listings from CoStar's LoopNet site and, in CoStar's summary of the ruling, covered its tracks “by screenshotting CoStar Group-copyrighted photographs and cropping out CoStar Group's watermark.” A damages trial follows.

Read those two together and the risk profile becomes obvious. CoStar is suing the largest real estate portal in the country over rental photos that came from Apartments.com. If that is the treatment Zillow gets, a solo developer republishing the same images is not occupying some safer category. The listing text is one question; the photography is a different and much sharper one, because photos are registered, individually ownable works with statutory damages attached.

None of this makes reading a public web page a crime. It does mean the honest risk on Apartments.com is not "I might get IP-banned." It is "I might be republishing someone's registered photographs at scale." We go through the general landscape in is website scraping legal? and explain how we handle sourcing in is RealtyAPI legal?

Your four real options in 2026

Option	Pricing	Setup effort	Where it hurts
Official listings API	Doesn't exist	n/a	No portal, no signup. The syndication feed and the customer APIs are both inbound or account-scoped.
DIY scraper (headless browser + proxies)	"Free," plus proxies and your time	Days to build, forever to maintain	The site renders listings client-side and the edge blocks unrecognized clients outright, so you need a real browser and residential egress before you parse a single rent figure.
Scraper marketplace actors	From about $3.50 per 1,000 results; some are $30/month plus usage	Hours	Fragile in a way you can verify before you buy: one of the top-ranked Apartments.com actors currently carries a notice on its own page saying it no longer works because of the site's security protections.
Hosted REST endpoints (RealtyAPI)	Free tier of 250 requests/month; paid plans from $20/month for 20,000 requests	Minutes	US rentals only, following Apartments.com's own coverage. Current listings, not historical price series.

That third row deserves a second look, because it is the clearest illustration of the maintenance problem anyone could ask for. A paid, well-reviewed actor sitting near the top of the search results for this exact query has a banner on it saying the target site's defenses broke it. That is not a knock on the author. It is what happens when your product is a bet that someone else's HTML holds still.

If you want the general version of this trade-off, we wrote it up in web scraping vs. using an API. The short version: scraping wins when volume is tiny and nobody is depending on the result. It loses the moment a customer notices the data is stale.

Here is the DIY route demonstrated end to end, complete with a title that promises it still works in 2026, which is the genre's most honest recurring tell:

What RealtyAPI's Apartments.com endpoints cover

RealtyAPI runs hosted Apartments.com endpoints as part of its real estate data platform. You call a normal REST endpoint with an API key, and the browser automation, proxies, and anti-bot plumbing stop being your problem. There are 29 endpoints across five groups:

Group	Endpoints	What it gives you
Search rentals	/autocomplete, /search/bylocation, /search/byzip, /search/bycoordinates, /search/bypolygon, /search/byurl, /search/byregionid	Autocomplete resolves a place name to a region id; the six search endpoints then take free text, a ZIP, coordinates, a drawn polygon, a listing URL you already have, or that region id
Property details	/details/byid, /details/byurl, /details/byaddress	The full property record, keyed by listing key, URL, or street address
Property info	13 endpoints including /details/amenities, /details/availabilities, /details/schools, /details/transits, /details/petpolicy, /details/leaseterms, /details/photos	Each sub-block on its own, so you fetch the one that changes daily without re-pulling the whole record
Computations	/details/walkscore, /details/fees, /details/rentalcosts, /details/similar, /details/reviews	All-in monthly cost, itemized fees, resident reviews and sub-ratings, and comparable nearby listings
Market data	/rental/trends	Average rent by studio / 1BR / 2BR / 3BR, nationwide or for a given state or city

The filters that make it feel like Apartments.com

A generic national listings API treats a rental like a for-sale home with a different price field, which is how you end up unable to answer "two-bed, dogs allowed, under $2,800, available before October, in a building people don't hate." /search/bylocation takes seventeen parameters; these are the ones that carry rental-specific meaning:

• petPolicy: Dog, Cat, or Dog_and_Cat
• availableFrom and availableTo: a move-in date window in YYYY-MM-DD, matched against each listing's earliest available date
• specialties: Senior, Military, Student, Corporate, Short_Term, Income_Restricted
• toolFilters: deal-finder buckets such as Rent_Special, Best_Value, Top_Deal, Luxury, Cheap
• minRating: a floor on resident rating, 1 to 5 stars
• amenities: 38 values including washer_dryer, washer_dryer_hookup, garage_parking, elevator, gym, pool, wheelchair_access, and rent_specials
• sortOrder: including Recently_Updated, which is the one you want for change detection, plus Has_3D_Tour and Has_Video
• keywords: free text matched against listing descriptions, for the things that never became a filter ("hardwood", "exposed brick")

Ranges use a compact min:/max: syntax rather than paired parameters, so an exact bedroom count is bedRange=min:2,max:2 and a studio is bedRange=min:0,max:0.

The unit-level data most rental APIs never reach

This is the section worth reading even if you never touch RealtyAPI, because it is the thing that makes multifamily data structurally different and it is what the scraper tutorials consistently stop short of.

On a for-sale portal, one listing means one home at one price. On Apartments.com, one listing is usually a building, and the building has many units, each with its own rent, its own square footage, its own floor plan, and its own available-from date. The search result gives you a rent range. The number a renter actually pays lives one level down.

Apartments.com knows this is the valuable part: its pitch to advertisers leads with exact unit pricing, real-time availability, unit-specific floor plans, and lease-term pricing. A search-results scraper captures none of that. It gets you "$1,850 to $3,200" and a building name.

/details/availabilities is the endpoint for that level: each available unit with beds, baths, square footage, asking rent, available-from date, and floor plan label. It is also the block that changes fastest, which is exactly why it exists as its own call. If you're tracking a portfolio of buildings daily, you poll one small endpoint per building instead of refetching entire property records to diff four numbers.

Around it sit the costs that decide whether a unit is actually affordable: /details/fees returns application fees, deposits, admin and amenity fees as separate line items, and /details/rentalcosts returns the all-in monthly estimate with utilities, parking, and pet rent broken out. Anyone who has built a rent comparison feature knows that base rent alone quietly lies to users. A $1,900 unit with a $300 parking requirement and $75 in monthly fees is not a $1,900 unit.

Quick-start: rentals in three requests

Base URL: https://apartments.realtyapi.io. Auth: your key in the x-realtyapi-key header. Every request costs one credit, and the free tier's 250 requests a month is enough to shape a real integration before you decide anything. The docs cover key setup in a couple of minutes.

1. Search a market

curl "https://apartments.realtyapi.io/search/bylocation?location=Austin,%20TX&bedRange=min:2,max:2&priceRange=max:2800&petPolicy=Dog&sortOrder=Lowest_Rent" \
  -H "x-realtyapi-key: YOUR_KEY"

Results are paginated. resultCount defaults to 50 and goes up to 500, and the response carries a nextPage boolean, so you page until it turns false. Each listing carries a listingKey, which is what every details endpoint takes.

2. Pull the property record

curl "https://apartments.realtyapi.io/details/byid?listingKey=B22w35" \
  -H "x-realtyapi-key: YOUR_KEY"

If you only have a URL, the listing key is its trailing segment: https://www.apartments.com/the-victor-by-windsor-boston-ma/B22w35/ gives you B22w35. If you have neither, /details/byurl and /details/byaddress take those directly.

3. Drop to the units

curl "https://apartments.realtyapi.io/details/availabilities?listingKey=B22w35" \
  -H "x-realtyapi-key: YOUR_KEY"

That's the whole shape: find buildings, identify one, read its units. Same listingKey works across /details/fees, /details/petpolicy, /details/leaseterms, and the rest.

A production-ish Python loop

With pagination and the error handling you actually want, since anything fronting live web data will occasionally have a bad minute upstream:

import requests

BASE = "https://apartments.realtyapi.io"
HEADERS = {"x-realtyapi-key": "YOUR_KEY"}

def get(path, **params):
    r = requests.get(BASE + path, params=params, headers=HEADERS, timeout=60)
    r.raise_for_status()
    return r.json()

def search(**filters):
    page = 1
    while True:
        data = get("/search/bylocation", page=page, resultCount=100, **filters)
        listings = data.get("listings") or data.get("results") or []
        if not listings:
            break
        for listing in listings:
            yield listing
        if not data.get("nextPage"):
            break
        page += 1

def units_for(listing_key):
    try:
        return get("/details/availabilities", listingKey=listing_key)
    except requests.HTTPError as exc:
        # One dead building shouldn't take down the whole sweep.
        print(f"skipping {listing_key}: {exc}")
        return None

for listing in search(location="Austin, TX",
                      bedRange="min:2,max:2",
                      priceRange="max:2800",
                      petPolicy="Dog"):
    key = listing.get("listingKey")
    if not key:
        continue
    units = units_for(key)
    print(key, listing.get("address"), "->", units)

From there it's your product. Snapshot /details/availabilities nightly into Postgres and you have a per-unit price history nobody sells you. Watch toolFilters=Rent_Special for concession tracking across a submarket. Join /details/rentalcosts against income to build an honest affordability tool instead of one that pretends fees don't exist. Pair it with /rental/trends for the market context, the same way we approached rental market analysis.

What you still can't get

Honesty section. These endpoints return what is on Apartments.com now. They are not a time machine: if you want a price history, you capture snapshots yourself on a schedule, and the loop above plus a cron job gets you surprisingly far. /rental/trends gives you aggregate movement by city and state, but it won't reconstruct what unit 4B rented for last spring.

Coverage follows the source, so this is US rentals. It is not a for-sale dataset, and it is not international. If your app needs national for-sale coverage or another country, you are combining sources, which is the same conclusion we reached about StreetEasy in NYC, Redfin, and Airbnb's supply-side API. There's a broader survey in the best real estate listing APIs if you're picking a stack rather than a single source.

Key takeaways

• Apartments.com has no public listings API, and the two official integrations both point inward. Syndication via [email protected] publishes your listings to them; the customer APIs are scoped to an existing advertiser's own account. Neither reads the marketplace.
• The moat is 85,000+ paying advertisers. Placement in front of 43 million monthly renters is the product. An open feed would commoditize it, so the API isn't delayed, it's declined.
• On this portal, photos are the real legal exposure. CoStar is pursuing Zillow over roughly 53,000 images that originated on Apartments.com, seeking damages it puts above $1 billion. Listing text and listing photography are not the same risk.
• Marketplace scrapers break, and they'll tell you so themselves. A top-ranked Apartments.com actor currently advertises that the site's defenses stopped it working. Check the actor's own page before you budget around one.
• Unit-level data is the whole point of multifamily. A search result gives you a building and a rent range. Per-unit rent, floor plans, move-in dates, and itemized fees are one call deeper, and that's the layer a product is actually built on.

If you're building anything against US rentals, the fastest way to find out whether this data fits is to run the three requests above against your own city and look at what comes back at the unit level. The free tier covers 250 requests a month, which is more than enough to answer that question before you spend anything.