# Changelog of Instagram Post Likers Scraper — Who Liked Any Public Post (`steadyfetch/instagram-post-likers-scraper`) Actor

- **URL**: https://apify.com/steadyfetch/instagram-post-likers-scraper/changelog.md
- **Full Actor documentation**: https://apify.com/steadyfetch/instagram-post-likers-scraper.md

## Changelog

### 1.0.14 — 2026-10-22

- **A run that stops at your maximum cost per run now says what to set.** The run's status line and its last row name the maximum you set, how many likers it bought at this run's price, how many of the likers you asked for are left, and one figure for "Maximum cost per run" (`maxTotalChargeUsd`) that covers the whole ask at the same price, so a re-run does not have to guess. On the Apify free plan, when that figure is more than the plan includes in a month, the line says so instead of suggesting it. Each post the cap stopped names the maximum you set. Prices, charges and every other row are unchanged.

### 1.0.13 — 2026-10-22

- Rebuilt on the patched Node runtime (no code change).

### 1.0.12 — 2026-10-21

- Internal: the monthly collection limit is now read from a shared setting at run start. Results, rows and prices are unchanged.

### 1.0.11 — 2026-10-20

- **You can now call this actor as an API endpoint.** Send one Instagram post (its link, short code or 19-digit media id) as `postUrl`, with an optional `maxLikers`, by GET or POST, and the accounts that liked it come back in the same response as JSON, with no run to start and no dataset to read. The address is on the actor's Endpoints tab. Each liker returned has the same fields as a row in a run's dataset and is charged as one liker at the same price as a run; a request that returns no likers is not charged, and if a request's charge cannot be completed its likers are not sent. One request returns at most 2,000 likers (100 on the Apify free plan). The endpoint has no account memory, so it does not hand back likers you already have uncharged; a run still does.
- Nothing changes about runs: the price, which likers are charged, the input fields and the output columns are the same.

### 1.0.10 — 2026-10-18

- **The per-post numbers now say what a read really gives.** On a big post one read returns about 1,000 likers, sometimes a few hundred more; ~2,000 is the most one read can give, and there is no further page, so running the same post again returns about the same likers, not more. The store page, the input form and the output descriptions all say so now, instead of "about 1,000 to 2,000".
- **The input form names the price and the id it takes.** Its description now gives the price per 1,000 likers ($1.00 on the Apify free plan, from $0.40 on paid plans — the price itself is unchanged) and what comes back, and the number it accepts is named as the post's 19-digit Instagram media id.
- **A post asked for by its number and not found no longer shows a made-up link.** That row's `postShortcode` and `postUrl` are now empty, and `postMediaId` still carries the number you sent. Rows for links, and every other row, are unchanged.
- Nothing changes about the price, which likers are charged, or the input fields.

### 1.0.9 — 2026-10-17

- **A Meta Graph API media id is now named as one, instead of being looked up as a post.** A bare number of 17 or 18 digits that starts with 17 or 18 is the shape of an id from Meta's Graph API, not of an Instagram post id, and looking one up comes back "not found". It is now answered at once with one uncharged row that says what it looks like and asks for the post's own link (instagram.com/p/CODE/ or /reel/CODE/) — if it really is an Instagram post, its link works too.
- **A number that is not found no longer tells you to open a link in a browser.** When a post asked for by its numeric media id is not found, the row names the number you sent rather than a link built from it, and the row and the run page say it was not found as an Instagram post id, that ids from other systems (Meta Graph API, ad accounts) look similar, and that the post's own link is the sure way. Rows for links read exactly as before. Nothing changes about the price, which rows are charged, the input fields or the output columns.

### 1.0.8 — 2026-10-16

- **The run summary uses plain names.** The run's summary — the last dataset row and the OUTPUT record — now names the count of reads the run made `reads`. The counts themselves, which rows are delivered, the input fields and every other column are unchanged.

### 1.0.7 — 2026-10-11

- **Clearer wording when a run stops at its limit.** Rows for the posts a run could not finish now carry the status "limit_reached" and say "This run reached its limit", with how to fetch the remaining likers in a new run, and the run page counts them as "past this run's limit" instead of printing an internal word. Nothing changes about the price, which rows are charged, the input fields or the other output columns.

### 1.0.6 — 2026-10-08

- **The monthly data allowance behind this actor was raised, so a busy month no longer stops delivery part-way through.** Nothing you are charged changes: the allowance is ours, not yours, and a run that ever meets it still stops honestly and charges nothing for what it did not deliver.

### 1.0.5 — 2026-10-07

- **The input form's descriptions now lead with an example.** Every field's first sentence shows the kind of value it takes with one example, and the description says in plain words what an empty input `{}` does: three built-in sample rows and one uncharged note row, with nothing read from Instagram and no result fee. The price, the input fields and the output columns are unchanged.

### 1.0.4 — 2026-10-06

- **Likers are now saved to your dataset in chunks instead of one at a time, so a big post finishes much sooner.** A post's likers arrive in one read; saving and charging each of them separately took most of the run's time. The likers, their order, what each row contains and which ones are charged are exactly as before, and nothing is charged until its rows are in your dataset.
- Nothing changes about the price, which likers are charged, the input fields or the output columns.

### 1.0.3 — 2026-10-03

- **The README links a real sample dataset:** fifty likers of one public NASA post from one verified run with the per-post limit set to 50, unedited, with the run's own summary row last.
- **The README now says exactly when a post gets its status row.** A post that comes back short of your per-post limit gets one uncharged row with the likes it shows and the likers served; a post that filled the limit you set needs none, so it gets none. Nothing changes about the price, which likers are charged, the input fields or the output columns.

### 1.0.2 — 2026-10-03

- **A stop now says which limit really ended the run.** A run whose maximum cost per run left no room for even one liker used to say it "stopped at your maximum cost per run", though nothing was charged; it now says it stopped before any charge and that the maximum leaves no room for one liker. And when the actor's own limit for a very small ask stops a read, the run page and the uncharged rows now say so, instead of blaming your maximum cost per run. Nothing changes about the price, which likers are charged, the input fields or the output columns.

### 1.0.1 — 2026-10-03

- **First release.** Paste Instagram post, reel or IGTV links and get the accounts that liked each one: handle, full name, user id, profile link, picture, and the verified and private flags.
- Up to ~2,000 likers per post. On a big post one read usually returns about 1,000 to 2,000, and each post's uncharged status row gives the like count the post shows, the likers served and the likers delivered.
- One `liker` charge per liker delivered. No start fee and no per-post fee. A post that is not there, a post with hidden likes, a read that did not go through and every limit you set all ship as uncharged rows with a reason, and the run still succeeds.
- Account memory: likers your account already received from the same post in the last 90 days come back uncharged (`repeat: true`), or are skipped if you switch that off, so a scheduled re-run pays only for new likers.
- Your limits are hard limits. A setting above the actor's own bound is never refused: the run continues at the nearest bound and leaves one uncharged row saying so.
