# Changelog of Kijiji Scraper & Tracker - Cars, Rentals, Price Drops & MCP (`akhil_rajesh/kijiji-scraper`) Actor

- **URL**: https://apify.com/akhil_rajesh/kijiji-scraper/changelog.md
- **Full Actor documentation**: https://apify.com/akhil_rajesh/kijiji-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.15 - Changes stored as an abort comes are kept

- Only changes: a run aborted while a listing page was loading (the last one its Listing pages budget allowed) went on to store the changes read with it after the abort had saved the history, and those listings were left out of it. The next run of the schedule reported them again, and charged them again. The run now saves the history again as it ends, so they are kept.

#### 0.1.14 - 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, Kijiji 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, an abort, a bug or a dataset failure could leave them out, and so
  could a restarted run that didn't get to read a search again; the next run of the schedule then reported those
  listings again, and charged them again.
- Only changes: a search's history is saved one save at a time. A run that Apify had restarted part way through, and
  that was then aborted just as it saved a search's history, could save that history without the changes it delivered
  before the restart; the abort's save now waits for the one in progress and adds to it.
- 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. 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 "Kijiji 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 refused: the run stops before reading anything and says the URL must be
  a public address, as it already did for `https://127.0.0.1/`. Public addresses written as numbers 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.