# Changelog of Auction.com Scraper — Foreclosure, REO & Trustee Sales (`haketa/auction-com-scraper`) Actor

- **URL**: https://apify.com/haketa/auction-com-scraper/changelog.md
- **Full Actor documentation**: https://apify.com/haketa/auction-com-scraper.md

## Changelog

### 0.2.0 — 2026-11-01

- **Corrected `currentHighestBid` mapping** — it was being read from the `current_highest_bid` object as if it were a scalar, which always produced `null`. It now correctly reads `current_highest_bid.bid_amount`, so the live high bid is captured whenever Auction.com publishes it for a segment. (The search endpoint does not expose the bid amount for every in‑progress listing, so this field is `null` by source on those records — use `bidCount` to see how many bids have been placed.)
- **Added `winningBid`** — the final winning bid amount from the auction `result`, captured when available.
- **Verified a fresh run** of 500 unique California listings in ~24s: 0 duplicates, 0 value bugs, and ~100% coverage on every identity and property field (`listingId`, `url`, `address`, `street`, `city`, `state`, `county`, `zip`, `latitude`/`longitude`, `propertyType`, `bedrooms`, `bathrooms`, `squareFootage`, `lotSize`, `yearBuilt`, `assetType`, `productType`, `occupancyStatus`, `auctionStartDate`, `primaryPhoto`). Live‑auction fields (`startingBid`, `bidCount`, `reserveStatus`, `bidIncrement`, `auctionEndDate`, `segmentStatus`) populate for listings in an active or cleared auction segment; upcoming "sale pending" listings have no live segment yet, by design.
- **Refreshed the README** to the gold standard grounded in the fresh run: the Output example is now a real record, the field reference documents `winningBid`, `sellingMethod`, `segmentStatus`, `primaryPropertyId`, `externalIdentifiers` and `searchState`/`searchLabel`, and an honest coverage note explains the data‑dependent bid fields.
