Empire Flippers is unusual among the sites in this catalogue: the whole thing fits in fifteen requests. What takes care is not getting the data but knowing which parts of it say what.
What Empire Flippers shows an anonymous visitor
The marketplace serves its listings as JSON to any visitor, 200 per request, with no account, cookie or token. Each listing carries 81 source fields: price, multiples, average monthly profit, revenue and expenses, a 12-month P&L series, a traffic series where the seller connected analytics, niches, monetization models, sites with their SEMrush authority, and the due-diligence text Empire Flippers writes — summary, opportunities, risks, work required, reason for sale.
What it does not show is anything behind its Unlock and NDA step: the business URL, the detailed P&L, access to the seller. Reaching those needs an account and an accepted agreement, so they are out of scope by construction rather than by policy. A listing's HTML page, at 19 times the bytes of its JSON, adds nothing the JSON lacks.
The source has a few habits worth knowing before reading its output. Thirteen numeric fields, including the annual multiple and each month's profit, revenue and expenses, are served as strings; the monthly series arrive unsorted; traffic channels come as an object keyed by channel name. The Actor types the numbers, sorts the series by month and turns the channels into a table, so the row you receive is not the raw response.
Step 1 — choose the statuses
listingStatuses takes For Sale, Pending Sold and Sold. On 23 September 2026 those were 180, 23 and 2,674 listings, a partition with no overlap. For sourcing, For Sale is the market. For valuation, Sold is the history — though the price on it is the final asking price, a distinction worked through in asking price versus price realized.
One source quirk shaped this input: asking for two statuses in one comma-separated parameter returns 0 listings rather than both. The Actor requests each status separately and shares the maxItems budget fairly between them.
Step 2 — filters that narrow, and six that do not
Every filter in the input was tested against the live source with a negative control. A parameter that does not exist at all returned the full 2,877 listings; so did six that look real, among them country=US, platform, price_min and keyword. Those six are not offered, because a filter that silently returns everything produces a run that looks correct and is not.
| Filter tested | Listings returned | Rows matching |
|---|---|---|
| Asking price ≥ $100,000 | 1,426 | 100% |
| Monthly profit ≥ $5,000 | 1,040 | 100% |
| Monetization SaaS | 64 | 100% |
| Platform Shopify | 341 | 100% |
| A parameter that does not exist | 2,877 | Ignored |
Sorting works the same way: newest, price high or low and monthly profit high were verified to change the order; other spellings of a sort parameter were silently ignored and are not offered.
Step 3 — one row per business, or per month
The default outputType, listings, gives one row per business with the monthly series nested inside it. monthlyMetrics flattens them into one row per business-month — net profit, revenue, expenses, page views, users and traffic channels — which is the shape a spreadsheet or a time-series query wants.
The monthly rows inherit the listing's gaps. Over 400 business-month rows from 32 businesses, net profit, revenue and expenses were filled on 95.3%, page views and users on 30.0% and traffic channels on 18.0%. A business has about twelve months, so maxItems counts months in this mode: 100 rows is roughly eight businesses, not a hundred.
{
"listingStatuses": ["Sold"],
"monetization": "SaaS",
"maxPrice": 200000,
"sortBy": "newest",
"maxItems": 100
}What is filled, by status
Measured on the whole catalogue, the median listing filled 71 of 91 data fields — 77 for For Sale, 70 for Sold. The averages hide the useful part, which is where the two statuses differ:
| Field | For Sale (180) | Sold (2,674) |
|---|---|---|
| Asking price | 100% | 99.9% |
| Monthly P&L series | 100% | 99.7% |
| Profit trend | 100% | 53.6% |
| Risks | 97.2% | 59.3% |
| Business registration country | 100% | 15.0% |
| Monthly traffic series | 36.7% | 77.9% |
| Traffic channels | 36.7% | 2.5% |
| Verified data providers | 94.4% | 21.1% |
Model-specific fields behave as expected: MRR is filled on 34.4% of the 64 SaaS listings and on almost nothing else; Amazon SKU counts on 47.2% of For Sale listings. They arrive as null rather than being dropped, so the column set is stable. Why this site publishes rates by segment rather than one average is argued in measured fill rates, not promises.
What a run costs
$0.0045 per listing, $0.0005 per business-month row, $0.001 for a tech stack when one is found, and the platform's start event. The whole 2,877-listing catalogue comes to about $12.95; the default run returned all 180 For Sale listings for about $0.81. Error rows and duplicates are never charged, under the model described in pay-per-event pricing.
A maximum cost per run is respected rather than overshot. A platform test with a $0.50 cap and monthlyMetrics stopped cleanly at 999 rows, charged $0.4996 including the start event, and said in its status message why it stopped. A row is never delivered unless it can be charged.
includeTechStack is the only switch that adds requests — one per listing — and it found a stack on 16.7% of 30 For Sale listings sampled and none of 20 Sold ones. For Sold comparables it is cost with nothing to show for it.
robots.txt and the terms
Fetched on 10 October 2026, empireflippers.com/robots.txt has one group for all agents, disallowing /wp-admin/ and nothing else, and the API host's robots.txt was an empty file. The Actor does not filter by robots.txt, but on this site there is nothing it would exclude. The general argument is in robots.txt-compliant scraping.
