US local classifieds as JSON, scoped to the metro you actually want

OfferUp is a US marketplace and there is no country parameter because there is no other market. A request from outside the US is answered with a 403 page titled "Geolocation Unavailable", identically from every kind of exit — that is a country gate on the marketplace, not anti-bot behaviour, and the engine types it as MARKET_UNAVAILABLE so you know there is nothing to retry and no setting that opens it. Everything else about the surface is unusually open: OfferUp's own robots.txt names the data endpoint as allowed, and a call needs no cookie, no token, no account, no login and no browser.

OfferUp assigns EVERY exit the geographic centre of the United States as a fallback location, so an un-scoped search returns Pretty Prairie and Wichita, Kansas — no matter where the call comes from. The lat and lon parameters on OfferUp's own search URL are ignored too. What works is the location sent with the query, and it was verified from one exit inside one minute: New York coordinates returned Parlin, Edison, Union Beach, Matawan and New York; Los Angeles returned South Gate, Rosemead, South Pasadena and Garden Grove; Miami returned Miami, Ind Crk Vlg and Fort Lauderdale; Seattle returned Burien, Everett, Lynnwood and Fall City. This is the practical upside as well as the trap: you sweep several metros from ONE exit, without buying an IP in each of them.

Pass a ZIP and OfferUp's own geocoder turns it into coordinates at the cost of one extra request — a live call on 98101 came back scoped to 47.6067 / -122.3354, Seattle WA, with 16 of 44 rows in Seattle itself. The response always names the coordinates actually used and reports a source of zip_code, coordinates, or offerup_default_us_centre, so a mis-scoped search shows up in the payload rather than in the towns three days later. Free-text place names are deliberately not offered: OfferUp's geocoder refuses that arm without a bias position, so it would have been a parameter that silently did nothing.

Pass the next_cursor from one response back as the cursor on the next call: 4 pages of one query gave 44 + 44 + 49 + 47 = 184 rows and 184 DISTINCT listing ids, with zero overlap against everything already seen. There is no page NUMBER — this feed is cursor-paged only — and no result total, so total_results is null rather than a guess. Two things not to assume: the page size is OfferUp's rather than yours, which is why a rows-per-call parameter is not offered at all (5, 10, 20, 50 and 100 all returned the same roughly 50-tile page upstream, so it would have been a parameter that does nothing), and the cursor belongs to the query that produced it, so changing a filter starts a fresh walk.

search is one upstream request at 23.7 to 24.7 KB, median 24.2 KB, with a median 875 ms; add a ZIP and it is two requests and about 1.7 seconds because of the geocode. product/detail is one request at 2.2 to 3.8 KB, median 3.0 KB, median 685 ms. Across 128 live engine calls in three runs there were 0 unexpected failures, p90 between 820 and 985 ms depending on the run, and 9 deliberate negative cases all returned the right error code. Both actions are flat-rated at one credit. The HTML page carries the same rows at 315 KB — thirteen times the bytes — and is deliberately not what this engine reads.

Fourteen listings were fetched twice, once through the engine and once as the page, and compared against the page's own structured-data price: 14 match, 0 mismatch, and no listing where the page carried no price. The set deliberately included a genuine 0.00 listing, kept as 0 rather than treated as missing, because a free item is a real thing on a classifieds site. Across 1,501 search rows, 24 detail payloads and a 1,409-row regression, the scan for raw HTML tags and HTML entities in any string found zero of each.

A dealer can ask OfferUp to hide the price on the feed tile, and OfferUp then sends an empty string rather than a number. Rather than shrug at the gap: the rows with no price are exactly the rows flagged CALL_FOR_PRICE — 7 of 1,062 in one run and 10 of 1,409 in the regression, and in BOTH runs the count of missing prices equalled the flag count exactly, so there are zero unexplained nulls. Every one was an auto-dealer vehicle. Those rows return price null with call_for_price true, never a misleading 0, and product/detail on the same ids returns the real numbers — 12,790, 22,290, 17,999 and 25,477 among them. OfferUp hides the figure on the tile, not on the listing.

OfferUp's schema has a reviews object on a user profile and it measured null on 12 of 12 profiles — including a furniture seller with 10,769 items sold, and one whose own display name is "5 Star Seller". So the seller rating, the review count and the rating scale are all null rather than an invented number, and nothing on the surface states a rating maximum either. What OfferUp does publish is returned instead, and it is arguably the better reputation signal: items sold, items purchased, the join date, the stated response time, and the badge strip — "95% reply rate", "Confirmed phone", "Confirmed email" — as LABELS only, never as contact details.

A feed tile has no owner field at all, so the seller is null on a search row and is filled by product/detail. The condition and the is-the-price-firm flag behave the same way: both measured 0 of 704 on search rows and both filled 24 of 24 on detail — the tile fields exist and OfferUp does not fill them, which is a source gap rather than a parse fault. And there is no result total anywhere on the feed, so total_results is null rather than a guess; the cursor is how you find out how much there is.

OfferUp's own filter drawer names condition values, and three separate spellings of the parameter were tried against them. Not one changed a single row over 44, so condition is not published as a search filter at all — a parameter that is accepted and ignored is worse than no parameter. The filters that ARE offered were each proved to bite: a 100-to-200 price band returned 44 of 44 rows inside it; radius 5 kept 41 of 44 rows in Los Angeles itself across 4 towns while radius 50 spread over 30 towns; the descending price sort led with 1,000,000 and 999,999 where ascending led with five zero-priced rows; and each category id was verified by fetching the returned listing's own category back from product/detail. One interaction is documented on the parameter rather than hidden: a category plus a keyword lets the category win where the keyword has no local supply, so a phone keyword inside the vehicles category returns cars.

Public listings only, logged out, with no account and no captcha anywhere in the path. What comes back about a seller is what the public listing page shows anyone: their public display name, their public town, their join date, their sold and bought counts and their badge labels. The phone-number fields that exist on OfferUp's schema are never requested by this engine, so they cannot appear in a response even if OfferUp starts filling them.