# Changelog of Craigslist Scraper & Tracker - Cars, Housing, Price Drops & MCP (`akhil_rajesh/craigslist-scraper`) Actor

- **URL**: https://apify.com/akhil_rajesh/craigslist-scraper/changelog.md
- **Full Actor documentation**: https://apify.com/akhil_rajesh/craigslist-scraper.md

## Changelog

### 2026-11-10

- The README links a new Actor: Indeed Jobs MCP Server & API.

### 2026-11-06

- The README links a new Actor: Pinterest Trends Scraper & API.

### 2026-11-04

- The README links a new Actor: Google Trends Scraper & API.

### 2026-11-03

- The Apify SDK is updated from 4.0.2 to 4.2.0 (apify-client 3.4.0 and crawlee 1.11.0 stay). Runs return the same data. A run still stops exactly at your maximum cost per run and says so: SDK 4.2.0 would let one more result through past a spent limit, and this Actor keeps the earlier behaviour, so nothing past your limit is stored or charged.
- With SDK 4.2.0, a status update that doesn't reach Apify is logged instead of stopping the run.

### 2026-11-02

#### 0.1.10 - Changes kept and posted however a run ends; private webhook addresses refused in every spelling

- Only changes: however a run ends (finished, aborted, stopped by a bug or a dataset failure, Craigslist down, the
  timeout), the changes it stored now go into each search's history, including those an earlier attempt of the same
  run delivered before Apify restarted it. Before, a bug or a dataset failure left them out, and so did a restarted
  run that was aborted, or met Craigslist down, before it saved that search again. An abort that came while listing
  pages were loading left out the up to 10 listings stored with them, after the abort's own save. The next run of the
  schedule then reported those listings again (a listing gone, a price drop), and charged them again.
- Only changes: a run aborted just as it saved a search's history could have that save overwritten by the smaller one
  the abort makes, which holds only the listings already delivered. What only the run's own save held was then lost:
  the listings it read but didn't return (on a first run with a low Max results, most of the baseline), which listings
  had gone missing, and whether the search was read whole. The next run could report and charge some of those
  listings as new, and report a listing gone a run late. The two saves now take turns: the abort's save waits for the
  one in progress and adds to it, so both are kept.
- Alerts are posted on every end that saved changes. An aborted run posts them in the seconds an abort leaves (one try
  per message), and a run stopped by a bug or a dataset failure posts them before it ends as failed, and its status
  message says so. Before, those changes were never posted, as the next run knew them already. Each message is still
  recorded once it is posted, so a restarted run doesn't post it twice.
- Alerts: a search whose history didn't answer no longer posts "alerts are set up", as if it were a first run. Its
  listings are returned without a change, as before, and nothing is posted for it.
- Alerts: a webhook URL that names a private address in a short or numeric spelling (`https://127.1/`,
  `https://0x7f.1/`, `https://2130706433/`) is now refused before anything is read, as `https://127.0.0.1/` already
  was. Public addresses written as numbers (`https://8.8.8.8/`) still work.
- Library versions are fixed: apify-client 3.4.0 and crawlee 1.11.0 next to the Apify SDK 4.0.2, so a rebuild can't bring in versions the tests haven't run on.
- The README links two new Actors: YouTube Channel Scraper and Contact Details Scraper.
