# Changelog of Instagram Profile Posts Scraper — Instagram User Posts, Reels (`steadyfetch/instagram-profile-posts`) Actor - **URL**: https://apify.com/steadyfetch/instagram-profile-posts/changelog.md - **Full Actor documentation**: https://apify.com/steadyfetch/instagram-profile-posts.md ## Changelog ### 1.0.111 — 2026-09-19 - **The whole "Maximum cost per run" you set is now spent on posts; before this build the run held back about a twelfth of it.** Your cap pays for posts and nothing else — the compute, the proxy and the data behind the run are ours, not yours — but the run was still reserving roughly 8% of your cap against those costs before it planned a single post. So a cap worth ten posts bought nine, and the tenth was money you had authorised and could not spend. That reserve is gone. A run at its cap still ends the same honest way it always did: it stops itself, tells you what it cut and why, and charges you for nothing it did not deliver. No price, input field, output column or charged event changed. ### 1.0.110 — 2026-09-19 - **A scheduled date-window check now stops waiting out Instagram when there is a second source that can answer it.** A run that asks one profile "anything inside this window?" used to spend most of its time asleep: Instagram refuses a connection, the run pauses and tries a fresh one, pauses again — around fifty seconds of pausing in a typical run, nine pauses, and on this kind of check almost none of them changes the answer. The run then reaches for the other source it already has and gets its answer in one request. Those pauses are now bounded: while a second source is available and your request is a date-window check, the run may pause for about eleven seconds in total and then goes straight to the source that answers. It keeps every connection it used to try — only the waiting between them is cut — so nothing is delivered later or left out, and the run finishes in roughly half the time, which also means fewer of these checks are cut short by your own "Max run seconds". A full archive walk, a run asking for posts you already have, and any run with no second source available behave exactly as before. Nothing changes about what is delivered, the price, the input fields or the output columns. - **A profile row that found nothing new now tells you how to run several profiles for the same money.** If you watch profiles on a schedule, one run listing all of them finishes sooner than a run each and costs exactly the same — the post fee is charged per delivered post and the profile fee once per profile, however the profiles are split across runs. The row says so now, and only on a run that asked for a single profile. Said in the README too, under watching profiles on a schedule. ### 1.0.109 — 2026-09-19 - **A "Tagged" tab that could not be read no longer blames Instagram for it.** When a run collecting the posts that tag an account came back with nothing readable, the uncharged row said Instagram did not return readable data for that profile. Instagram was never asked: it publishes no public route for that tab, so a licensed data feed is the only source there is, and the sentence was wrong every time it printed. The row now names the source that really answered and says exactly what it always said about the rest — this is temporary, it is not a verdict about the profile, nothing was charged, please re-run. Everything else is unchanged: the same rows, the same posts, the same prices, and a profile the run could not look up at all still reads word for word as before, because that lookup really does go to Instagram. ### 1.0.108 — 2026-09-19 - **A request the extra data source refuses outright is no longer described as temporary — and the "Tagged" tab having nothing to serve still is.** Those two answers used to read the same way in your dataset: "this is temporary, nothing was charged, please re-run". One of them was wrong every time. A request that source refuses outright comes back refused the same way on every run, so asking you to re-run it offered you a run that cannot work; that row now says plainly that a re-run will not change it, and that it is still not a verdict about the account. The "Tagged" tab answering that it has no entries for an account is a different fact — that tab is filled by other people's posts, so a later run really can differ — and it keeps the temporary wording and the re-run it has always had. Nothing is charged for either answer, and nothing changes about what is delivered, the price, the input fields or the output columns. ### 1.0.107 — 2026-09-18 - **A repeat run whose date window matches nothing now stops after one page instead of re-reading the same feed every time.** Put a "Posted before" or "Posted after" window on a profile and run it on a schedule, and every run walked the same forty-odd pages from the top of the feed, found nothing inside your window, and delivered nothing — then did it again on the next run, and the one after. Nothing was charged for any of it and nothing was missed, but the run took minutes to say what it could have said in seconds. A run that reaches the bottom of what your "Max posts per profile" buys and finds nothing to deliver now remembers, for that profile and that exact set of filters, which post was newest when it looked. The next run with the same settings reads one page: if the profile's newest post has not changed, the feed below it holds the same posts your filters already rejected, so the run stops there and says so on the profile row. Publish something new, widen the window, raise "Max posts per profile", change "Post type", or ask for posts you already have to be handed back, and the full walk runs exactly as before — the shortcut only ever applies to a repeat of the identical request that has already been answered. Nothing changes about what is delivered or charged. - **A profile your own time limit cut part-way through now gets a row saying how far it got and how to continue.** Until now a run stopped by "Max run seconds" mid-profile left the posts it did not read counted on the summary and nothing else: no line told you how many pages that profile reached, which date window it was heading for, or what to do next. Each such profile now writes one uncharged row with the depth it reached, the window it was going toward, and the two ways forward — pass the summary row's `resumeCursor` back to continue from exactly where it stopped, so nothing is read or charged twice, or raise "Max run seconds" to reach further in a single run. The resume is named first on purpose: it continues work already paid for, while a bigger limit re-buys it. A run your own "Max posts" or maximum-cost setting stopped is unchanged — that is your cut, and it is already named where it belongs. Nothing changes about what is delivered or charged. - **A profile with no posts is now told apart from a handle that does not exist.** The extra data source this actor falls back to answers a request for an empty account's feed with the same "not found" as it answers for an account that was never there. That answer used to end the run saying the handle does not exist — about a profile the same run had already read, listed and priced moments earlier. It now uses what it already knows: if the profile itself says it has no posts, the run says that, plainly and permanently; otherwise it says the read was refused, which is the honest answer and does not ask you to re-run into the identical refusal. Nothing is charged either way, and every other answer from that source behaves exactly as before. ### 1.0.106 — 2026-09-18 - **The monthly allowance behind this actor's data reads is now $60, up from $25 — 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. - **A profile list longer than your time limit can reach now says so while the run is still going, and the profiles nobody got to have a row of their own.** Ask for two thousand profiles under a one-hour limit and the run reads as many as the hour holds — about a hundred on a busy day — then stops on the clock. That was always true and the posts left over were always counted, but the only place to learn it was the receipt at the end, and nothing ever named the one number you act on: how many profiles this run's own pace fits in the limit you set. Now, as soon as the run has read enough profiles for its pace to mean anything, it says in the run log how long a profile is taking it today and roughly how many "Max run seconds" will hold. And when the clock does end the list early, one uncharged row says how many profiles were read, how many were not attempted, and that passing the summary row's `resumeCursor` back continues from exactly the next one. Nothing else moves: the same profiles are read, the same posts are delivered, nothing undelivered is charged, and a list your limit does comfortably hold behaves exactly as it always has. ### 1.0.105 — 2026-09-18 - **A date window set months back no longer reads a profile's whole archive looking for it — and a run that does not reach your window now says so instead of going quiet.** Setting "Posted before" far back on a busy account made the run walk the feed from the newest post all the way down, up to four hundred pages on a large profile, hunting for the first post inside your window. Most of that reading delivered nothing and charged nothing, and on the profiles where it mattered most it could still run out of time before reaching anything. A date window is now read to the same bounded depth every other request gets — about forty pages past what your own "Max posts per profile" needs — and when the window is still further down, the run ends the walk there and writes one uncharged row saying how many pages it reached, which window it was heading for, and that the next run continues from where this one stopped. The resume point is saved at the exact page it stopped on, so passing the summary row's `resumeCursor` back picks the walk up from there with nothing read again and nothing charged twice; raising "Max posts per profile" buys a deeper scan in a single run instead. A run your own time limit cuts first still reads as a time-limit stop, in the same words as always, and a window the run does reach behaves exactly as it did before. Nothing changes about the price, the input fields, the output columns or the charged events: one charged unit is still one post delivered, the profile lookup is unchanged, and nothing undelivered is charged. ### 1.0.104 — 2026-09-18 - **The $0.003 profile lookup is live, and the pages that announced it now describe it in the present tense.** Each profile that delivers at least one post adds one profile lookup of $0.003, flat on every plan. The store card, the README and the input form had all dated it to a day still ahead; it is being charged now, so they say so plainly instead. Nothing else about the price moved: per-post prices are unchanged, a profile that delivers nothing — private, removed, unreachable, or nothing new on a watched list — still pays no lookup, nothing is charged for starting a run, and the $0.05 minimum on Maximum cost per run is the same. Two sentences about the limits were corrected alongside it, because a second charged event made them false as written: a run stopped by a limit now says that nothing undelivered was charged rather than that only delivered posts were, and a whole-run cap of 1 is now described as exactly one delivered row, charged once for that post and once for the profile it came from — the sentence a buyer checks against their own invoice. ### 1.0.103 — 2026-09-16 - **The run log now says what every read of the post feed cost, so a slow run tells you where its time went.** Until now the log spoke only when a page of posts was delivered and when a profile finished. A read that stalls or comes back refused delivers nothing and finishes nothing, so it said nothing at all — a run that spent its whole limit inside two requests and a run that read forty pages quickly left you the same silence. Every read now leaves one line naming which connection was asked (Instagram, a fresh connection when the walk had to escalate, or the extra data source this actor falls back to), how long that read took, and how much of your run's own limit was left when it came back. Nothing changes about what is collected, delivered or charged; the lines carry counts and timings only. ### 1.0.102 — 2026-09-16 - **A run no longer stops reading with most of a minute of your own time limit unspent.** Before each read the run set aside a whole request's worth of time plus what it keeps back to write your rows, receipt and resume point — fifty seconds in all, whatever "Max run seconds" you set. So a run with 47 seconds still on the clock stopped and booked the posts it had not reached as cut short by the time limit, on a profile whose pages were coming back in about a second each; on the shortest runs the same rule was true before the first page was even asked for. A read is now measured against the time your run actually has, and what is kept back for writing is scaled to the limit you set — so the last seconds of a run go on reading instead of being held for a request that was never going to take that long, and the fresh connection a stalled feed needs is bought where it fits. Runs with time to spare behave exactly as before, a stop that really is your time limit still says so and still names "Max run seconds", and nothing changes about what is delivered or charged. ### 1.0.101 — 2026-09-16 - **A blank "Tagged" tab is now asked a second time, and two blank answers get a real answer instead of "please re-run".** When the tagged tab came back with nothing on the first page, the run could not tell an empty tab from a read that did not work, so it asked you to run it again — and the re-run came back just as blank. The first blank page is now read once more; if that one is blank too, the row says plainly that this account has no posts by other accounts tagging it, and does not ask you to re-run. If the second read brings posts back, you simply get them. If it fails for any other reason, the run still says the tab could not be read and asks you to try again, exactly as before. Nothing is charged either way. - **The extra data source this actor falls back to now runs on your clock too, and a run your own time limit cut no longer blames it.** That source had a time limit of its own, measured from when its read started, so a page fetched with half a minute of your run left could still run past "Max run seconds" — and when your limit cut it, the row said the source had rate-limited the run and asked you to re-run in a few minutes. Those reads are now given only the time your run actually has, and when your own limit is what ended the walk the row says so and names "Max run seconds" as the setting to raise. A real rate limit on that source still reads exactly as it did. ### 1.0.100 — 2026-09-15 - **"Max run seconds" now ends the run when it says so, not when the last connection happens to finish.** A run set to 180 seconds could keep going for another 40 or more: each connection to Instagram had a time limit of its own, measured from the moment that connection started rather than against your limit, so one begun with twenty seconds left was still allowed its full length — and a connection that stalled past its own limit had nothing left to end it at all. Every read is now given only the time your run actually has, keeping back just enough to write the rows, the receipt and the resume point, and it is cut off at exactly that. Short runs are unaffected: the amount kept back is scaled to the limit you set, so a 30-second run still reads. Nothing changes about what is delivered or charged, and a run with time to spare reads exactly as it did before. ### 1.0.99 — 2026-09-15 - **A run your own "Max run seconds" stopped used to say Instagram had cut it short.** When your time limit ran down to less than one connection's worth, the run correctly stopped asking Instagram for more — but the receipt blamed Instagram and asked you to re-run, which sent you straight back into the same limit for the same result. Those runs now say what really happened: the posts still to read are counted under your own time limit, the summary says the run stopped before the timeout and names "Max run seconds" as the setting to raise, and the resume point is saved exactly as before, so a longer run continues from where this one stopped with nothing read or charged twice. A walk Instagram really did cut short still says so, in the same words as always. Posts already fetched are still delivered and charged exactly as before, and nothing extra is bought in those last seconds. ### 1.0.98 — 2026-09-14 - **On a busy run the run page could cut its own sentence in half — and the half it cut was the accounting, the limit the run stopped at, and the warning that the same posts would be charged again next time.** Apify truncates a run's status message at 500 characters and replaces the rest with "...", and on this actor everything that matters sits at the END of that sentence. A run that hit several things at once — posts delivered, profiles that returned nothing, profiles Instagram would not serve, a walk cut short, posts your own filters excluded, duplicate sightings folded into one charge, posts your account already had, an input we could not read, and a cost limit on top — composed up to 644 characters, so the tail vanished with no sign that anything was missing. The line now gives way on purpose instead. Under that much pressure the per-profile and per-post counts fold into a single pointer at the full figures, which are in the run's OUTPUT and on the rows either way, and everything about your money stays whole and always fits: what was charged, what was not, the limit you set and the field to pass back to resume where the run stopped. Nothing about what is delivered or charged changes, and any run whose sentence already fitted reads exactly as it did before, to the character. Two smaller fixes ride along: a run that stopped some profiles before reading them could drop that count entirely, with nothing left pointing at it, and a run that refused to start because it could not read "New posts only" or your watchlist used to say in one breath that nothing was charged and that you may have been charged twice — it now says only the true half, and a long watchlist name of your own can no longer push that sentence past the cut. ### 1.0.97 — 2026-09-14 - **New: collect the posts that TAG a profile, not only the posts it publishes.** Set **What to collect** to "Posts that tag the profile" (`resultsType: "tagged"`) and the run returns Instagram's **Tagged** tab for each handle you gave it — what other accounts posted about them — instead of their own grid. Everything else is exactly what you already use: the same handles, the same **Max posts per profile**, the same post-type and date filters, the same repeat memory that never charges you twice for a post you already have, the same resume point for a long run, and the **same charged unit at the same price** — one charged unit is one post delivered, whichever tab it came from. Nothing about your existing runs changes: leave the setting alone (or send `null`) and this actor collects the profile's own posts exactly as before. On the new tab every row's `ownerUsername` is the account that actually published the post, `profileHandle` is still the handle you asked for, and `postSource` reads `tagged`, so a mixed pipeline can always tell them apart. Two things it will not pretend to know: nothing Instagram publishes counts how many posts tag a profile, and the tab can be curated — so when a tab comes back unreadable this actor says so, uncharged, and asks you to re-run, rather than telling you a tab is empty when it cannot prove it. ### 1.0.95 — 2026-09-14 - **A run that named a watchlist could stop dead in the middle of a delivery — posts already in your results, the charges for them never posted, and no explanation anywhere.** A watchlist is a key-value store in your own Apify account, and this actor writes to it right after each page of posts is delivered and before that page is charged. If the API token the run was started with could read that store but not write it — which is what an Apify token restricted with "Restrict what Actors can access using the scope of this Actor" does without key-value store **Write** and **Create** — the refused write ended the run there and then. The run now finishes normally instead: every post you asked for is delivered and charged exactly once, and the refusal is reported the way a refused account-memory write already is — on the run page, in one uncharged note row carrying the whole explanation, and in the run log beside Apify's own message — so you know those posts are not on your list and would be charged again next run unless the token is given key-value store Write and Create permission (or Actor runs is set to Full access). Runs started from the console or with a full-access token are unchanged, as is every price, input and delivered column. ### 1.0.94 — 2026-09-14 - **The other half of the same problem: a token that could READ the memory but not WRITE it looked perfect and charged you all over again next run.** The record of what this actor has delivered to your account is a key-value store in your own account, and an API token restricted with "Restrict what Actors can access using the scope of this Actor" can carry key-value store **Read** without **Write** — or Write without **Create**, on an account that has never run this actor. Such a run opened the record, skipped every post you already had correctly, and then silently failed to add the posts it delivered, so the next run had no record of them and charged for the whole delivery a second time. Nothing said so: the writes were best effort and the run ended clean. From this build the run notices at its first refused write and names it in three places — on the run page ("repeat memory not updated… the posts delivered now will be charged again next run"), in one uncharged note row carrying the whole explanation and the permission to grant, and in the run log beside Apify's own message. Nothing else about the run changes: it still delivers and charges normally, because the posts are real and new, and a passing write failure that is not a permissions refusal is still just counted, exactly as before. - **The run page no longer runs out of room and cuts the invoice off mid-sentence.** Apify truncates a run's status line at 500 characters. On a busy run — several profiles with different outcomes, your own cost or time limit reached, a resume point saved — this actor's line ran past that, and what fell off the end was the part that mattered: the cap that stopped the run, the charge statements and the support ask. It now gives way in a fixed order instead. What is charged, what is not, and which of your own limits bound the run never give at all; the "open an issue" ask goes first, then the explanations around the counts, and every count stays. The full text always ships in the run's OUTPUT, on the rows and in the run log. Measured on the widest run this actor can produce: 697 characters before, 500 after. - **A run started with a scoped API token could be charged twice for the same post, and nothing told you why — it now says so, and says exactly what to grant.** The check that skips a post your account already has lives in a key-value store in your own Apify account. An API token limited with "Restrict what Actors can access using the scope of this Actor" cannot open that store unless it carries key-value store **Read, Write and Create** permission, so runs started from the API with such a token silently lost the check and charged again for posts an earlier run had already delivered — while the run page said only that the repeat check was "unavailable". From this build the run names the cause and the fix in three places: on the run page, in one uncharged note row placed first in your results (so an agent reading rows never misses it), and in the run log beside Apify's own message. A watchlist the same token cannot open now says the same thing instead of asking you to re-run, which on that token would fail identically, and **New posts only** refuses with the permissions to grant rather than "re-run in a minute". Nothing changes for a run started from the console or with a full-access token, no price, input or delivered column changes, and every other reason the check can be unavailable keeps the wording it had. - **A backup-source answer this actor cannot read yet no longer asks you to re-run it.** When Instagram walls a profile mid-walk this actor finishes the read through a licensed data source. If that source answers in a shape this build does not read — which happens when it renames a field — the row used to be reported as a temporary outage and told you to re-run: a re-run buys the identical unreadable answer, so it spent your platform time for nothing. The row now says what actually happened, that it is on us rather than on Instagram or on the profile, and that running it again gets the same answer; the run also stops waiting out a pause for it, because there is nothing to wait for. Nothing charged or delivered changes — that answer was never charged and still is not, and every other outcome (a rate limit, a wall, a private or missing account, your own limits) reads exactly as before. ### 1.0.93 — 2026-09-14 - **"New posts only" now compares against your account's memory without a watchlist name, exactly as the setting says it does.** The switch has always described itself as comparing each profile's most recent posts — as many as "Max posts per profile" — against what you already have, with or without a watchlist name. Without one it was only half doing that: a post you already had was skipped and never charged, but it did not hold its place in your result limit, so the run paged on down the feed until it had found that many posts you did not have — older posts, below the recent ones you asked about — and delivered and charged for those. Now a post you already have holds its place whichever record the run compares against, so the run reads the profile's most recent posts and stops there. On a scheduled re-run with nothing new that means nothing delivered and nothing charged, in the pages it takes to read that window rather than the whole feed. Everything else is unchanged: a post you do not have is still delivered and charged once, a new post is still found first because it is published to the top of the feed, a run that names a watchlist reads exactly as before, and with "New posts only" OFF a post you already have still costs your limit nothing, so that run keeps filling it with posts you lack. One thing to know if you set both switches: with "New posts only" and "Include posts you already have" on and no watchlist named, a post you already have is now skipped rather than handed back — which is what naming a watchlist has always done. - **A scheduled "new posts only" re-run no longer re-reads the same pages to tell you there is nothing new.** When a run under those settings spends your whole result limit on posts that are already in your account — nothing delivered, nothing charged — it now records how far down the feed it got. The next run under the same settings, the same list and a result limit no larger stops at the first page whose posts you already have instead of buying the rest of them again, so it answers in a fraction of the time. Nothing delivered or charged changes: a post you already have was never charged and still is not, a post you do not have is still delivered in full and is still found first — a new post is published to the top of the feed, which every run reads before anything else — and the profile row says how much of the feed was read to answer you. A run that delivered something, a larger result limit, a different list, post type or date window, and a walk that Instagram or your own limits cut short all read exactly as before, and the shortcut expires by itself a week after it was recorded. ### 1.0.92 — 2026-09-14 - **A scheduled re-run no longer reads a whole profile feed to discover that you already have all of it.** When the last run under the same settings read a profile's feed to its end, this run stops at the first page whose posts are all already in your account — the posts below it are the ones it just confirmed you have. Nothing delivered or charged changes: a post you already have was never charged and still is not, a post you do not have is still delivered in full, and the profile row now says how much of the feed was read to answer you. The first page that still holds something new, a different post type or date window, a walk that stopped at your result limit, and a profile whose feed has not been read to its end all read exactly as before, and the shortcut expires by itself a week after the feed was last read to its end. ### 1.0.91 — 2026-09-13 - **Writing `profile`, `username` or `url` instead of `profiles` now returns posts instead of an error row.** An agent or a person who guesses the singular of a field name used to get a run that collected nothing and one uncharged row naming a field they had never set. Those names — `profile`, `username`, `usernames`, `url`, `startUrl` — are now read as the profiles or links they hold, one value or a list, deduplicated against anything already in "Instagram profiles", with one uncharged row saying which name was read and which field this actor reads so the next run needs no guess. A value that is not an Instagram profile still gets its own honest uncharged row, and pressing Start with nothing set still runs the sample. Nothing charged, priced or delivered changes. - **The store description now names the profile lookup that starts on 16 September 2026.** The card quoted the per-post price and nothing else, while this page and the input form have said for weeks that from 16 September each profile that delivers posts adds one $0.003 lookup. A buyer reading only the card would have met that line on their invoice first. The card now carries it, dated, beside the per-post price. No price or event moved and nothing starts earlier than notified: per-post prices are unchanged, the lookup is charged only from that date and only on a profile that delivered, and a post we cannot deliver is still never charged. ### 1.0.90 — 2026-09-13 - **The input schema now speaks to an AI agent as well as to a person.** An agent that finds this actor through Apify's MCP server never opens this page — it reads the input schema. So the schema's own description now opens with the call that works, says what one post costs and what a profile's 30 newest posts come to, keeps the notice that each profile delivering posts adds one profile lookup from 16 September 2026, lists what is never charged, and names the run option that caps the bill. The Instagram profiles field leads with the value shape and an example, then what is never charged, then where comments and reel transcripts belong, with the console sample instruction last. No price, no charged event, no input field and no delivered column changes. ### 1.0.89 — 2026-09-12 - **A profile the run stops walking is now continued on the licensed data feed, instead of being handed back as "cut short by Instagram".** When Instagram refuses page after page, this run has two ways to stop trying: it can be refused three times over, or it can simply decide the wall is not worth any more of your time limit. Only the first of those ever handed the walk over to the licensed feed — so a run that stopped for the second reason ended right there, delivered the pages it already had, reported the rest as a walk Instagram had cut short, and asked you to run it again, while minutes of your own time limit sat unused and the fallback feed that could have finished the profile was never asked. Both endings now hand the walk over, from the exact page it reached, so the same run finishes the profile. Nothing about money moves: no price, charged event, input field or output column changed, only delivered posts are charged, and a profile that genuinely could not be finished is still uncharged. - **A run that still has work left no longer describes itself as completed.** The summary row could say "Completed" while holding a live resume point, posts it had not collected and time it had not spent — three facts in one row that contradicted the first word of it. That row now says plainly that the rest was not collected on this run, carries a `retryable` flag you can read without parsing a sentence, and points at the resume point it is holding. A run that really did answer your ask reads exactly as it did before. - **A walled profile is also given about twice as long to recover before it gives you a partial answer**, sized as before by how many posts you are still owed, the container you picked and your own run clock — so more runs finish rather than ending early with a "please re-run". ### 1.0.88 — 2026-09-12 - **When the licensed data feed slows this run down, the run now waits it out for as long as your ask is worth, instead of giving up after a few seconds.** The fallback feed had a fixed handful of seconds of patience: past it a run ended the profile, delivered whatever it already held, and reported the rest as a walk Instagram had cut short — on runs that still had minutes of their time limit left. The patience is now sized by how many posts you are still owed, the container you picked and your own run clock, so a busy few minutes on that feed costs you a pause rather than the rest of your posts. Two things the row used to get wrong are fixed with it: a profile cut short this way now says it was the licensed feed that slowed the run down and not Instagram, and it tells you to re-run in a few minutes from the resume point on your summary row. A run that really was cut short by Instagram reads exactly as it did. Nothing about money moved: no price, event, input field or output column changed, only delivered posts are charged, and a profile cut short is still uncharged. ### 1.0.87 — 2026-09-12 - **An aborted or migrated run now leaves its receipt from the first moment of the run, instead of only after start-up finishes.** The record that says how a run ended was only put in place once the run had finished starting up — reading your input, opening its stores, working out what a previous attempt had already delivered and charged. A run stopped inside that window ended with nothing written about it at all, which mattered most on a re-started run, where the thing not written about was the earlier attempt's work. It is now in place from the run's first moment. Nothing else moved: no input field, output column, event or price changed, and a run that reaches its work behaves exactly as before. ### 1.0.86 — 2026-09-12 - **A run that falls back to the licensed data feed no longer crawls through it.** The fallback opened its pages at one per second — the slowest rate that feed serves anyone — so a profile that needed twelve pages spent twelve seconds of your run clock simply waiting between requests, and a run near its time limit could end on a partial answer because of it. The run now asks the feed what it is actually allowed and collects at that rate, which on our account is about fifteen times faster. More of your run clock goes to posts. Nothing about what you are charged moves: the price, the charged event, the input fields and the output columns are unchanged, only delivered posts are charged, and the correction to our own private cost record is ours, not yours. ### 1.0.85 — 2026-09-12 - **A brief rate limit on the licensed feed no longer costs you the rest of the profile.** When a run falls back to the licensed data feed and that feed answers "slow down" — or is briefly unavailable — the run used to give up on the whole profile within a few seconds: you got the pages collected up to that point, the rest of your posts were reported as a walk Instagram had cut short, and the row asked you to re-run. From this build the run waits the refusal out, up to twice per profile, and asks for the same page again; a feed that clears continues the walk to your result limit, and only a feed that still refuses afterwards ends the profile. The waiting is bounded by your run clock — no wait is taken that the remaining time cannot fit — and stops immediately at your maximum cost per run. - **A profile that really was cut short is unchanged:** the posts already collected are still delivered, the receipt still carries the resume point, and that row is still uncharged. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.84 — 2026-09-12 - **A link in your rows can never carry a network address, whatever form it arrives in.** Every link this actor delivers already went through our own URL hygiene before reaching your dataset, and that pass had a gap: where an upstream body writes its links with HTML-escaped separators (`&` in place of `&`), the address parameter was not recognised by name and could survive into a row. It is now removed however the link is written — escaped, plain or legacy separators, upper or lower case, and inside a link that wraps another link. Nothing else in a link moves: the expiry, the signature and every routing parameter are delivered exactly as they were served, so the links keep working exactly as before. No column, no input, no price and no charge changes. - **A profile whose feed refuses from the first page is now served from the licensed feed instead of a partial answer.** When Instagram handed us the profile but then refused its post feed from the very first page, the run spent minutes retrying that feed on fresh connections and ended with whatever the profile page itself carried — often nothing new, if you already had those posts — and a "please re-run" partial. From this build a feed that refuses three times in a row without ever serving a page, on a profile that answered, is collected through a licensed data feed instead: same posts, same result limit, same per-post price, no new fee and no second charge. Posts you already have are still handed back uncharged, a profile with no posts is still answered as such, and nothing about a run Instagram serves normally changes. - **A run that stops at your cost cap now says so, instead of blaming Instagram.** When the run reached your "Maximum cost per run" exactly on the last post of a page, it used to fetch one more page it could never deliver to you — and if Instagram refused that page, the profile row said Instagram had stopped serving the profile part-way through and asked you to re-run. Your own cap was what stopped it. From this build the cap is checked **before** each page is fetched: the run stops there, the receipt says it stopped at your maximum cost per run and names the setting that raises it, and the posts it did not collect are counted against that cap rather than reported as a profile Instagram cut short. - **The resume point is unchanged**, so raising the cap and re-running continues exactly where the run stopped, with nothing re-collected or charged twice. - **A limit set higher than this actor's own no longer refuses the run.** "Max posts per profile" above 5,000, "Max posts for the whole run" above 100,000, or a run clock outside 30 seconds to 1 hour, used to be rejected by the platform before the run started — no run, no rows, and nothing to tell you why, which is what a saved task or an agent arriving with another scraper's numbers hit. From this build the run starts, continues at the nearest limit, and leaves one uncharged row naming what you asked for and what bound it. Nothing about the limits themselves moved, and your prices, charges and columns are unchanged. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.83 — 2026-09-11 - **Instagram links or handles pasted into `startUrls` (or `urls`) are now sorted and served.** Most Instagram actors on the store call their target list `startUrls`, so an input built for one of them used to arrive here as a field this actor did not recognise: one uncharged row, no posts, nothing charged. From this build those entries go straight into the same list as **Instagram profiles** — profile links and bare handles alike, either as plain links or as the `[{"url": "..."}]` shape — at the same result limit, the same per-post price and the same dedupe, so a handle in both lists is collected once and asked for once. - **A post or reel link now names the actor that takes it.** This actor collects a profile's posts and has no path for a single post, so a post or reel link still gets an uncharged row — but the row now points at our reel transcript actor and the field to paste it into there, instead of leaving you with nothing to do next. - **A `language` field sent with your input is accepted and ignored rather than stopping the run.** This actor returns posts, not transcripts; there is no language setting to honour, and a field carried across from a transcript actor should not cost you a run. - **Anything else this actor does not recognise is answered exactly as before**, and `profiles` is unchanged in every way: same name, same behaviour, same rows. - Nothing else moved: no price, event, output column or charge changed, and only delivered posts are charged. ### 1.0.82 — 2026-09-11 - **A maintenance build: nothing about your runs changes.** The credential this actor uses for its licensed data feed was rotated, and a new build is the only way the platform takes the new one. Same price, same charged event, same input fields, same output columns, and only delivered posts are charged. There is no reason to re-run anything. ### 1.0.81 — 2026-09-11 - **Nothing about your runs changes in this build** — same price, same charged event, same input fields, same output columns, and, as always, only delivered posts are charged. There is no reason to re-run anything. - **It corrects one number in this actor's own private cost record, which only we read.** When a run has to fall back to a licensed data feed, it first makes one small account read that the feed does not bill us for. The actor was writing that read down as a paid one, so our own running cost for this actor read one read per run too high. Nothing you see, receive or pay was ever affected by it: the record is ours, not yours. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.80 — 2026-09-11 - **A profile Instagram will not serve is now retried through a licensed data feed, at the same price.** When Instagram refuses to hand us a profile on any connection, or stops serving a profile's post feed part-way through, this run no longer ends with an uncharged "please re-run" row and a partial answer: the same posts are collected from a licensed data feed instead and delivered to you exactly as Instagram's own would be — same columns, same result limit, same per-post price, no new fee and no second charge. Posts you already have are still handed back uncharged, and nothing about a run Instagram answers normally changes in any way. - **A profile that turns out to be private or deleted now says so instead of asking you to re-run it.** Where the feed can answer definitively about a handle Instagram was only walling, you get the honest final answer — private, or no such account — rather than an invitation to spend another run finding out. That row is uncharged, as every non-delivery on this actor is. - **If the feed cannot answer either, you get exactly what you get today**: the same uncharged row saying what happened, the same resume point on the summary row, and nothing charged for it. - Nothing else moved: no price, event, input field or output column changed, and only delivered posts are charged. ### 1.0.79 — 2026-09-11 - **The README opens with the one-click MCP pin instead of burying it at the bottom.** The pin link, the actor id, the one input field you have to set with a real example, and how to cap what a run may spend now sit in the first screen, so an agent reading this page finds them. The store description leads with what the actor is, and every price and charging sentence in it is word for word what it was. - **A maintenance build otherwise: nothing about your runs changes.** The private run-report this actor writes for our own support — counts only, never anything you typed — gained two entries: what one charged event cost on the run, and, when a run stops on the maximum posts you set for the whole run, whether that maximum really filled. Only we read that record. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.78 — 2026-09-10 - **A run whose post feed Instagram has stopped serving now stops waiting on it, instead of pausing over and over for an answer that is not coming.** When Instagram serves a profile's first page and then refuses the rest, the run pauses between connection attempts — and on runs measured this week not one of those pauses was followed by a page: one run spent 319 of its 624 seconds waiting, another 300 of 392, and none of them recovered a single page. From this build the run stops waiting on a feed once three pauses in a row have brought nothing back, as long as that feed had already served at least one page. What you get is exactly what you got before — the posts it did read, the profile row saying the answer is partial, and the summary row's `resumeCursor` to continue from — minus the minutes of waiting. A pause that DOES bring back a page starts the count again, so a feed that is merely slow is never stopped; a profile that has served nothing at all keeps the full ladder of fresh connections, which is where waiting still pays. - **The run log says so once per profile**, naming how many posts you got and pointing at the resume point, and the summary row counts the feeds that were stopped. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.77 — 2026-09-10 - **A run Apify moved to another server mid-way now reports what the first half of it did.** When a run is moved, the container that takes over skips the profiles the first one already answered — no second fetch, no second row, no second charge, which is right and is unchanged. Its own account of the run, though, was written from scratch, so a run whose first half delivered nothing ended up reporting that it had asked for nothing and found nothing — while the rows in your dataset said, correctly, that some posts were excluded by your filter and the rest were already in your account. Each answered row now carries the count it stood for, so the run reports the same numbers whichever half of it finishes. Nothing you see changes: same rows, same wording, same charges, same resume point. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.76 — 2026-09-10 - **Two Instagram links this actor used to refuse now work.** A profile link on `instagr.am` — Instagram's own short domain, the one its share sheet and older apps hand out — was answered "this actor takes Instagram profiles" and collected nothing. So was a handle pasted straight out of a spreadsheet or a JSON file with the quotation marks still around it (`"nasa"`). Both were correctly-typed profiles, both cost the whole run, and both are accepted from this build, under exactly the same rules as before: a post link is still a post link, a "Copy link" share URL is still a share URL, and an app page is still an app page. - **A run where two of the profiles you listed share the same post now reports that honestly.** When a post appears on two of your profiles — a co-authored post, or the same creator named twice — it is delivered and charged once, which is unchanged and is how it should be. The run's own summary, though, then quietly forgot the second profile's share, so a request for ten posts could report five asked for and five delivered. The counts now cover everything you asked for, and say which posts your second profile had already been given. - **A run Apify moved to another server mid-way now reports the profiles the first half had already answered**, instead of finishing with an empty account of itself. Nothing about your rows, your charges or your resume point changes — only what the run says it did. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.75 — 2026-09-10 - **A run that finished every profile you sent no longer tells you to resume something.** When your own "Max posts for the whole run", your maximum cost or your time limit ended a run that had already answered every profile, the summary row still closed with "re-run with the profiles listed in resumeCursor to continue" — while the same row's `resumeCursor` field was empty, because there was nothing left to continue. The run page had never said it; only the row did, so the two halves of the same receipt disagreed. The sentence is now written only when the row really carries a resume point. A run that IS unfinished is unchanged: it still names the cursor and still resumes without re-reading or re-charging anything. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.74 — 2026-09-09 - **Two runs of the same watchlist started at the same time no longer erase each other's sightings.** Watchlists and the account memory are now merged on every write, so an item one run delivered stays remembered, and a later re-run hands it back instead of charging it again. - **The wait is priced against the ask, not picked.** The three patience ceilings (8 minutes per walled profile, 10 minutes of refused feed time on a walk the feed has served, 5 minutes on one it has not) were wall-clock numbers with no price on them, while waiting is billed as memory x time and you pick the memory anywhere from 256 to 4096 MB. A walled path may now spend only what the rows it could still recover are worth at your own tier price, after Apify's 20% — never below one whole measured attempt, and never at all while the run has delivered nothing. - **A walled-profile row that has stopped promising a re-run now says so**, in a field as well as in its sentence, and says what a re-run would cost: the connections, the minutes, and whether re-running is still the fix. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.73 — 2026-09-09 - **A run whose post feed is being refused now stops asking and hands you your rows, instead of spending your whole time limit on it.** When Instagram refuses the deeper post feed it refuses it from every connection for a while, so the run answers by taking fresh ones — and that patience had no end other than the "Max run seconds" you set. Three runs last week each spent about twenty-eight minutes taking fresh connections for a feed that answered none of them, and only said so at the end. The run now counts the time it has spent on refused requests and stops there: ten minutes once the feed has served it at least one page, five while it has served none. The posts it did read, the profile's own summary and the resume point all land with most of your time limit still unspent. The count is of refusals only, so a run that is getting pages is never stopped by it, and a page arriving mid-storm does not restart the clock. - **The row now says who stopped.** A profile whose feed stayed walled already said which surface it was and across how many connections; it now adds that we stopped there rather than spend the rest of your time limit on a feed that was refusing every connection. Pass the summary row's resumeCursor back and the next run continues from exactly that position. - **A run that answered every profile you sent no longer asks whether something went wrong.** When Instagram has no public profile at a handle, or the account is private, or it is a real public profile with no posts, that is the answer — the row says so and nothing is charged for it. The summary at the top of the run was still ending with "Something off? Open an issue", even on a run that delivered twenty posts from your other profiles. It now asks that only when something really is unresolved: a profile Instagram would not serve, a walk it cut short, a setting we could not honour, or a limit of ours that ended the run. - **A profile that will not load at all is no longer retried past the share of the run it was given.** The run allows one unreadable profile a bounded slice of your time limit and then moves on. That limit was being applied only to the pauses between attempts and not to the attempts themselves, so one profile could take twenty-two minutes of a thirty-minute run. It now means what it says. - **The run log no longer says a fresh connection hit the same block when it actually got an answer.** When the first read of a profile is blocked the run tries a fresh connection, and the log reported what that connection did by looking at what the FIRST one did — so a fresh connection that came back with a real answer about the account (private, or no such profile) was still reported as having hit the same block. Each of those three outcomes is now reported as what it was. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.72 — 2026-09-08 - **Those progress lines really do move now.** The last build added a line every thirty seconds carrying how long the run had been going, so you could see it working rather than merely alive. It reported that time in whole minutes while printing every thirty seconds — so two lines running often read exactly the same, and on the very case the change was made for (Instagram refusing reads, nothing delivered for minutes) every second line was still a word-for-word repeat of the one above it. The elapsed time is now reported finely enough that no two lines can come out the same. - **The run page now shows the same line as the log.** Until now all of this was in the Log tab and nowhere else. The line now also appears beside the run itself on the run page, updating as the run works, so you can tell a working run from a stuck one without opening the log at all. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.71 — 2026-09-08 - **The run now tells you what it is doing while it does it.** Reading a large profile could go many minutes without printing a single line, because every progress line landed only after the whole walk had finished — so a run that was working normally and a run that had hung looked exactly the same, and there was no way to tell them apart except by waiting. The run now names each profile as it starts on it, reports how many posts have been delivered and read after every page, and prints a line at least every thirty seconds while it is working. Silence now means something is wrong, rather than meaning nothing at all. - **It now warns you, from its own measured pace, when your ask cannot fit your time limit.** The warning that says a full archive will not fit compared your ask against a fixed speed measured once, weeks ago; Instagram is far slower than that today, so on a real archive it never printed and a run needing about two hours ran against a thirty-minute limit without a word. The run now measures how long a post is actually taking it — on your account, today, on the connections it is getting — and says as soon as the rest will not fit: how far this run will reach, how much longer the ask needs, and that raising "Max run seconds" or handing the summary row's resumeCursor back will finish it. - **Each of those lines moves.** While Instagram is refusing a read the run can be busy for minutes without delivering anything, and a line that reads the same every thirty seconds says the run is alive without saying it is working — which is the question you are actually asking. Every line now carries how long the run has been going and what it is doing right now, so you can see it moving rather than repeating. - Nothing else moved: no price, event, input field, output column or charge changed, and only delivered posts are charged. ### 1.0.67 — 2026-09-08 - **A run that delivered nothing now says WHY at the top, and names the setting that caused it.** When every post on every profile the run could read was excluded by your own "Post type" or date filter, the summary reported a bare zero — "0 posts delivered from 5 requested profiles" — and named no cause, although each profile's own row said exactly what had happened. The run summary now carries the same reasons the rows carry, biggest first, and names the filter that excluded the posts, so a run emptied by a setting reads as a setting to loosen rather than as an actor that found nothing. The same is true on a run that delivered some posts: the reasons ride alongside the count. - **The resume point now carries every profile the run did not answer, not only the ones it never started.** A run could tell you two profiles were temporarily unavailable and to re-run them, and in the same breath hand you a resume point that did not include them — so passing that resume point back continued with fewer profiles than you asked for, and said nothing about it. Every profile the run did not finish is in the resume point now: never started, left open by a limit, cut short, or unreadable on this run. - **The summary no longer asks you to re-run a profile it has already told you a re-run may not fix.** When Instagram refuses a profile across minutes of fresh connections, that profile's own row stops promising a re-run and says the account may be one Instagram serves only to logged-in visitors. The summary at the top of the run used to say "please re-run" anyway. It now reports what the rows report. - Nothing else moved: no price, event, output column or charge changed, and only delivered posts are charged. ### 1.0.66 — 2026-09-06 - **A block of links pasted into one row is now read as the list you meant, whatever separates them.** "Instagram profiles" takes one profile per row. A whole block of profile links pasted into a single row was read as one profile — the first one, with the rest swallowed into its address — so a paste of ten creators collected one and never said the other nine had been dropped. A pasted block is now split back into its individual links whether they are separated by spaces, line breaks, tabs, commas, semicolons, pipes or nothing at all, so a column copied straight out of a spreadsheet works. Each one is then read, deduplicated and charged on its own, exactly as if you had pasted them one per row. - **A link that carries another link inside it is still one link.** An address holding a second address in its query or its path is left whole, not broken in two, and a single link pasted on its own is never rewritten. - **Text pasted around a link no longer breaks it.** A number, a bullet or a note sitting beside a link is ignored and the link itself is used. A row holding no link at all is still answered as one row, not one row per word. - Nothing else moved: no price, event, output column or charge changed, and only delivered results are charged. ### 1.0.65 — 2026-09-06 - **The run's own record now counts the posts your limits left undone.** When your whole-run result cap filled, your maximum cost per run was reached, or the run timeout landed, the posts still ahead of it were simply absent from the report this run writes back to us: a run that asked for five posts and delivered two closed its books with three posts named by nothing at all. Each of those posts is now counted under the limit that stopped it, so a run that quietly stops short is visible to us without you having to report it. - **Nothing you can see changed.** Your rows, your columns, your summary row and your bill are exactly as they were — only delivered posts are charged, and a post that was not delivered is not charged. ### 1.0.64 — 2026-09-06 - **The posts a profile's own answer already carried are delivered when your time limit ends the run, instead of being dropped.** This is the common shape: Instagram answers for the profile — that answer carries the twelve newest posts — and then blocks the deeper post feed. The run keeps taking fresh connections for the rest of your limit, and when your limit ran out first it ended with nothing, holding twelve posts it had already read and paid for. They ship now. Your result and cost limits still bind exactly as before, and no further connection is bought. - **Nothing about charging changed.** Only delivered posts are charged, a post that could not be delivered is not charged, and a run started with nothing set behaves exactly as before. ### 1.0.63 — 2026-09-06 - **A short time limit no longer throws away the posts the run has already read.** When the first read of a profile is blocked, the run recovers by trying fresh connections and then the profile's own public page — and on a short limit that recovery can take most of the time you gave it. The posts it recovered were then dropped, because the run had reached its own time limit while finding them: on a thirty-second run the profile page served the twelve newest posts and none of them were delivered. They are delivered now. The time the run holds back at the end exists exactly to write your rows, so running out of time stops it looking for MORE posts, never handing over the ones it is already holding. - **A profile that is private, deleted or renamed is told to you as such, even when the first read was blocked.** The public page is the surface that can see this, and when it answered "private" after a blocked first read the run reported the block instead — "temporary, please re-run" about an account no re-run can ever open. The definitive answer now wins: the row says private (or no such profile), it is marked as not worth re-running, and nothing is charged for it. - **A short time limit now spends more of itself reading and less of itself reserved.** The run keeps time back at the end for your rows and the summary; that reserve was a flat twenty seconds, which on the shortest limit the form allows was two thirds of the whole run. It is now a quarter of your own limit — never less than the reporting really needs, and unchanged at twenty seconds for every limit of eighty seconds or more. A thirty-second run now has twenty-two working seconds instead of ten, which is the difference between one connection and the full recovery. - **When a run really does end on your time limit, the row names it.** A profile the run could not read on a limit too short to hold a recovery now says so, with the number you set and the number to raise it to, instead of asking you to re-run with no way to know what to change. - **The summary's "time left" figure is your own limit's, not the hour behind it.** A run stopped by a thirty-second limit used to report fifty-nine minutes of budget left. - **Nothing about charging changed.** Only delivered posts are charged, a post that could not be delivered is not charged, your result and cost limits bind exactly as before, and a run started with nothing set behaves exactly as before. ### 1.0.62 — 2026-09-06 - **A run whose deeper post feed stays blocked now delivers the posts it already read about a minute in, instead of at the end.** When Instagram answers for the profile but then blocks the deeper post feed, the profile's own answer already carries its twelve newest posts. Until now those posts waited until every fresh connection your time limit allowed had been spent — measured on a fifteen-minute run: the profile answered twelve seconds in and the first row arrived twelve minutes and forty-six seconds in. The run now delivers and charges them as soon as the block outlasts the connections that normally clear it, and then goes on working through the rest of your limit on the deeper feed with exactly the same patience. - **A block that a fresh connection clears in seconds still gives you the fuller rows.** Most blocks lift on the next connection, and the deeper feed's rows carry things the profile's own answer cannot: the video link, the play count, the paid-partnership flag, the poster's name and verified badge. Those runs are untouched — the posts already read are held back exactly as long as Instagram is likely to serve the better version, and no longer. - **When they do ship from the profile's own answer, the row says so and nothing is invented.** Those rows are marked as read from the profile itself, a column that surface does not carry is left empty rather than filled with a guess, and the profile row says the profile was read while the post feed stayed blocked, with how many connections were tried over how many minutes. - **A post the feed serves later is never delivered or charged twice, and never costs you a slot.** Both surfaces name the same post the same way, and the "posts read" figure counts a post once whichever surface it came from. - **A run whose limit is already filled by those posts now stops instead of spending the rest of your time limit.** If the posts delivered cover everything you asked for, there is nothing left for another connection to buy, so the run ends there. - **A run continued from a resume point still adds instead of re-reading.** Posts an earlier run delivered are not delivered again and are not charged again. - **Nothing about charging changed.** Only delivered posts are charged, a post that could not be delivered is not charged, and a run started with nothing set behaves exactly as before. ### 1.0.61 — 2026-09-06 - **The posts already read are delivered at once, and the deeper feed keeps being tried for the rest inside your time budget.** When Instagram will not serve its profile route and the run reads the profile from its public page instead, that page carries the profile's twelve newest posts. Those posts used to wait until the deeper post feed had spent every fresh connection your time limit allowed — up to the whole of a thirty-minute run on a blocked feed — and only then were they delivered. They are now delivered, and charged, the moment they are read, and the run goes on working through the rest of your limit on the deeper feed with exactly the same patience. - **A post the feed then serves again is never delivered or charged twice, and never costs you a slot.** Both surfaces name the same post the same way. Posts already delivered from the profile page are not counted against the room left for the rest of your limit, and the "posts read" figure on the profile row counts a post once, whichever surface it came from. - **A profile whose whole archive fits on its own page is reported as finished, not "cut short".** If the profile has published no more than that page shows, the run answers your ask instead of asking you to re-run for posts that do not exist. - **A run continued from a resume point still adds instead of re-reading.** Posts an earlier run delivered from the page are not delivered again and are not charged again. - **Nothing about charging changed.** Only delivered posts are charged, a post that could not be delivered is not charged, and a run started with nothing set behaves exactly as before. ### 1.0.60 — 2026-09-05 - **A profile whose POST FEED is blocked now keeps trying fresh connections for as long as your run's time limit allows.** Instagram blocks its post feed per connection, and a fresh one usually serves the very same profile seconds later — so this actor has always answered a blocked feed by continuing from the exact same position on a new connection. It just stopped after five of them, which on a blocked feed is about two minutes: a run given thirty minutes returned "cut short" with twenty-eight of them unused, while the same profile was being delivered on another run started in the same second. The five are now a floor, not the limit. The walk keeps taking fresh connections while the run still has room for one more and for writing your rows at the end, and while the posts you asked for can still pay for it. A feed that answers straight away is exactly as fast as it always was, and nothing is charged for a connection that was refused. - **A run continued from a resume point is patient in the same way.** Continuing a cut-short profile used to run into the same wall in under two minutes and return nothing, twice over, so "please re-run to collect the rest" led back to the same place. A continuation now spends its own time limit the same way a first run does. - **A cut-short row now says WHICH part was blocked.** The profile itself was read; it was the post feed that Instagram would not serve. The row says so, with how many connections were tried and over how many minutes, so a blocked feed is never read as a verdict about your handle. - **The retry ladder always keeps back enough time to write your rows and the summary.** A retry could previously start with twenty seconds left — a whole request inside the half-minute the run holds back for reporting. Every retry, and every cooldown before one, now leaves that half-minute plus a full request behind it. - **A run with several profiles still leaves the later ones their share of the clock**: one blocked profile may spend at most half the time left when others are queued behind it, and all of it when it is the only one you asked for. - **Nothing about charging changed.** Only delivered posts are charged, a post that could not be delivered is not charged, and a run started with nothing set behaves exactly as before. ### 1.0.59 — 2026-09-05 - **Every post this actor could not deliver is now named.** The run's own record of what was asked for and what came back is kept in POSTS, the same unit as your rows: a profile Instagram cut short reports the exact posts it did not deliver, a profile it would not open at all reports that profile's whole share of your ask, and a profile that answered definitively — deleted, private, or genuinely empty — reports one. Until now those shortfalls were recorded per PROFILE beside a post-count ask, so a run that delivered 8 posts of 20 could record only "2 profiles cut short" and twelve posts were named by nothing. - **A profile with fewer posts than your per-profile limit now asks for what it has.** Ask for 10 posts each from a profile that has published 3, and the run records an ask of 3 answered by 3 — not 10 with 7 missing. Your limit is still a ceiling, exactly as before, and the dataset is unchanged. - **Posts your own settings removed are recorded as yours.** Posts a profile published that your date window or post-type filter excluded, and posts "New posts only" had already delivered to this account on an earlier run, are now counted as answers to your ask rather than gaps in it — they are uncharged, as they always were. - **A run Apify moves to another server now says so as its stopping reason.** The hand-over already appeared on the run page; it is now also the reason the run records, so a run that continues elsewhere is never recorded as one that ran out of work. Posts already delivered are still never collected or charged twice. - **Nothing about charging changed.** Only delivered posts are charged, a post that could not be delivered is not charged, and a run that stops at your limit still stops exactly there. ### 1.0.58 — 2026-09-05 - **A run that waits now always keeps room to finish and report.** When Instagram walls every connection to a profile, the run can pause and walk the ladder again on fresh connections — but the check that decided whether a pause was affordable kept back only half a minute for what came after it, while one fresh connection lane is three requests and their cooldowns, up to two minutes. On a short run the pause could be allowed and the walk after it then ran into the time the run keeps back for writing your rows and the summary. The check now keeps back a whole fresh lane, measured from this ladder's own request timeout and cooldowns, so a pause is only taken when the run can actually use it. - **A run you start with nothing set now gets ten minutes instead of nine.** The sample's own limit had been sized against the half-minute placeholder; it is now long enough to hold one walled walk, one pause of up to three minutes and a real fresh lane after it, with time kept back for your rows and the summary. A sample Instagram answers straight away is exactly as fast as it always was — the limit is a ceiling, never a wait. - **Charges are unchanged.** Waiting is uncharged, a walled profile is uncharged, and only delivered posts are charged. ### 1.0.57 — 2026-09-05 - **A run started with no input at all now has room to wait out a block.** Press Start on the untouched form and this actor reads the 5 newest posts of one real profile, charged like any run. Instagram sometimes turns every connection away for a few minutes at a time, and one round of attempts could use up the whole of the sample's own four-minute limit — so the pause-and-try-again this actor gained in the last build could never happen on the most common first run of all: it reported "blocked, please re-run" while the block was still lifting. The sample's time limit is now nine minutes, sized to hold one full round of attempts across both connection pools and both surfaces, one pause, one more round, and enough time left over to stop cleanly and report. A sample Instagram answers still finishes in seconds; only a blocked one uses the extra time, and nothing is charged unless posts are delivered. - **How much of its remaining time one blocked profile may spend waiting now follows the size of what you asked for.** A run with more profiles still to read keeps exactly the limit it had — no single profile may spend more than half the time left, so a wide block still leaves the later profiles their share of the run. A run with a single profile may spend what is left on its one pause, because nothing else is waiting for that time. Every other bound is unchanged: a hard ceiling on waiting per run, never into the time kept back for reporting, and never when the run could not afford another round. - **The no-input sample now always reads Instagram for real.** It used to be answered from this account's own history of past runs, so a second Start handed the first one's posts back uncharged and nothing was actually fetched. The sample now ignores that history in both directions: it reads every time and does not add its own posts to the history. Two things are unchanged — a run with your own profiles in it still skips or hands back what this account already has, and so does a no-input run where you asked for the history by name ("New posts only", "Include posts you already have", or a watchlist name). ### 1.0.56 — 2026-09-05 - **A profile Instagram blocks on every connection is now given more of your run's time before it gives up.** When Instagram refuses a profile on every connection — both its data service and its public profile page — the run used to try for about three minutes and then return "please re-run", advice that would only repeat the same three minutes. It now waits a short spell and tries again on fresh connections, for as long as the run's time and your ask allow. These blocks usually clear within a few minutes, so a profile that was readable all along is delivered instead of coming back empty. Uncharged either way. - **A profile that stays blocked no longer reads as a quick "please re-run".** After several minutes of fresh connections that were all refused — on both surfaces — the row says the profile could not be read and may be one Instagram shows only to logged-in visitors, rather than pointing you back into the same block. A profile that was only briefly unavailable still says a re-run may clear it, and now says how many connections it tried and over how long. - **A private, deleted or empty profile still gets its definitive answer at once**, and a short run still returns its honest row inside the time limit you set. The run's own record now separates a temporarily-blocked profile from a permanent one, so a passing block and a real verdict read differently. Nothing about what is charged changed. ### 1.0.55 — 2026-09-04 - **A profile that Instagram walls on every connection is now retried on fresh connections before the run gives up.** When Instagram's profile service refuses both the data route and the profile page, this actor falls back to the page — and that page can be walled for one connection while a fresh one serves it seconds later. The run used to try the page exactly once and, if that one attempt was walled, return nothing while most of your run time sat unused. It now retries the same page on fresh connections, up to a small bound, so a profile that was readable all along is delivered instead of coming back empty. Uncharged either way. - **The retry ladder stops at your run's time limit.** On a short run (a low "Max run seconds"), the connection retries used to run past the limit you set. Every retry now checks the time left and stops cleanly inside it, so a short run no longer overruns. - **A profile served from its page delivers at once on a short run.** When the profile page answers and its own newest posts cover what you asked for, they ship immediately instead of waiting on the deeper post feed's retries — so a small ask on a short run comes back with rows. - **A profile that still could not be read says how hard the run tried.** A temporarily-unavailable row now names how many connections were tried for that profile before it gave up, so "please re-run" is never a verdict after a single attempt. - **The run's own record now counts what you asked for in posts, not profiles.** `requested` in the run's OUTPUT is the number of posts the run could deliver (profiles × your per-profile limit, capped by the whole-run limit), the same unit as what was delivered. It previously reported the profile count, so the two numbers could not be compared. ### 1.0.54 — 2026-09-04 - **A run that Instagram cut short now saves the place to continue from, on every path.** When Instagram refuses the deeper post feed altogether, this actor falls back to the posts published on the profile page itself — the newest 12. That answer used to be stored as a dead end: the run said "please re-run to collect the rest" but saved no resume point, so a re-run started from the top, found the same 12 posts already in your account, skipped them uncharged, and returned nothing. Every cut-short profile now carries its exact position in the run's `resumeCursor`, so a re-run adds posts instead of re-reading them. - **A post you already have no longer shrinks the ask.** By default a post already delivered to your account is skipped uncharged, as before — and the run now keeps reading until it has filled **Max posts per profile** with posts you do not have, instead of counting the skipped ones against your limit. With **New posts only** on, nothing changes: there a post you already have still holds its place in the window the run reads, which is what keeps a daily monitoring run on the newest posts rather than walking into the archive. - **A run only promises a re-run when there is something to re-run with.** The status line and the profile row used to say "re-run for the rest" whatever had been stored. When a run has no resume point the row now says the rest could not be read on this run, and the remedy is stated once, by the clause that owns it, instead of twice. - **The "posted after" explanation now checks the dates before it fires.** A profile that returned nothing while some posts were excluded printed *"Nothing matched your posted-after date: the newest post this run read is from …"* even when that newest post was well inside the window you asked for. It fires only when every post read really is older than your date. When the true reason is that your account already has the posts read, the row says that instead. - Shorter wording on three status-line clauses, so the resume point, the counts and the way to reach us all survive the length the run page shows. ### 1.0.53 — 2026-09-04 - **Narrowing one setting no longer costs you the sample run.** Press **Start** with nothing set and this actor collects the 5 newest posts of bbcnews so you see real rows. Change one thing first — a post type, a date, a result limit, a watchlist name — leave **Instagram profiles** empty, and you used to get a single row asking for handles instead of any output at all: the buyer who touched nothing was served better than the buyer who narrowed a dropdown. Now your settings are kept and the same sample runs under them, charged like any run. Everything you did not set takes the sample's own value, and one extra uncharged row names which settings were yours and how to run your own handles. - **A limit you set can only shrink that sample, never grow it.** "Max posts per profile", "Max posts for the whole run" and "Max run seconds" are ceilings: ask for at most 5,000 posts and you get the sample's own 5; ask for at most 3 and you get 3. A sample can never turn into a bill you did not ask for. - **Two things still answer with guidance instead of rows**, unchanged: a field name this actor does not recognise (a typo gets its name back, never rows that read as if it had worked), and a target you did set but left blank — a blank **Dataset ID** or an empty resume cursor is your list, and answering it with a sample would read as if your list had worked. - A row on such a run no longer opens by saying nothing was set — it says which half was missing. - A setting this actor cannot read is still refused before anything is fetched, exactly as before: an unrecognised post type, an unreadable date or a watchlist name that is not one gets its own uncharged row naming the field, and no sample runs. ### 1.0.51 — 2026-09-04 - **The run page no longer cuts the end off a long status line.** On a run that delivered posts, refused one handle, handed back repeats, found videos and stopped at your result limit, the line ran past the length the run page shows and the last sentence was cut mid-word. The video cross-sell now shrinks to its count when the line would not otherwise fit, so the cap guidance, the resume point and the way to reach us always survive. The chain instruction is in the README and on every video row. ### 1.0.50 — 2026-09-04 - **A "Post type" this actor cannot read no longer swallows your whole profile list.** Send eight handles with a post type it does not offer and you used to get a dataset holding a single guidance row — nothing said what happened to the eight profiles. Nothing is fetched and nothing is charged, exactly as before, but every handle you sent now comes back with its own uncharged row saying it was not looked up and naming the field that stopped it. - **Every input the run refuses now names the input field it is about** — `profiles`, `mediaType`, `postedAfter`, `postedBefore`, `resumeCursor`, `watchlistId`, `newPostsOnly` or `datasetId` — on the row itself and in the run's own record, so a run that delivered nothing can say which field to fix rather than "some input was wrong". - **The run's record now reports the profiles you asked for**, counted before anything was refused. A run whose every profile a setting stopped used to report nothing at all as the ask, which hid it from our own failed-run check. - **The status line separates two facts that used to share a clause**: inputs the run could not read, and profiles a setting stopped. - Wording: past entries that described a row or a run as "free", or as costing nothing, now use the register the rest of this changelog uses — every run spends platform time you pay for, so only "uncharged" is true. No facts, numbers or build headings changed. ### 1.0.49 — 2026-09-04 - **A post type written the ordinary way now works in "Post type".** `videos`, `reels`, `photos`, `album`, `sidecar` and `Videos and reels only` — the console's own name for the option — used to count as unrecognised values, and an unrecognised post type stops the whole run before a single profile is opened: one guidance row, and nothing for any handle you sent. They all land on the type they name now. A value naming none of the four types is still refused rather than answered with every post type and charged for it. ### 1.0.48 — 2026-09-04 - **A post already delivered to your account is never charged a second time.** Every run now remembers the posts it delivered for your account, in a key-value store called `ig-posts-watch-account` in your own Apify account, under both of a post's identities. Re-run the same profiles, at any depth, and those posts are skipped before they take a row slot — not delivered again, not charged, not counted against your limits — and the status line says how many. Delete that store to forget everything; entries older than 90 days count as new again. - **New option: "Include posts you already have" (`includeSeen`).** Off by default. Turn it on and posts your account already has come back in every run's dataset anyway, marked `repeat: true` with `firstSeenAt` and `firstSeenRunId` naming the run that first delivered them — and still not charged. Use it when you want one complete dataset per run rather than only what changed. - **"New posts only" no longer needs a watchlist name.** Without one it compares against your account's memory. It still stops the run before any spend when neither can be read, rather than risk charging you for posts you may already have. - **A memory that cannot be read never stops a run.** The run delivers and charges as usual and the status line says the repeat check was unavailable, so you know a repeat may have been charged that once. - **The default sample now reads a profile that answers reliably** (`bbcnews`, measured over consecutive cold runs), and it hands back posts you already have, so pressing Start twice still shows real rows and the second press costs nothing. ### 1.0.47 — 2026-09-04 - **Rows pasted into the "Dataset ID" field are read as your rows.** The run now recognises pasted rows there, collects the profiles they name exactly like rows pasted into "Dataset items", and adds one uncharged note saying where they belong next time. Anything else that is not a dataset ID or dataset name — a link, a value with spaces, a very long value — is answered with one uncharged row naming what it looked like, before anything is sent anywhere. - **A Dataset ID the platform itself cannot answer for is settled in seconds, not minutes.** When the platform's own dataset lookup fails on its side, the run used to wait through the platform client's long retry schedule — close to seven minutes on one lookup — and could then run out of its own time. The lookup now gets two quick tries plus one short pause, and the run moves on to its honest uncharged row. Nothing about what is charged changed. ### 1.0.45 — 2026-09-04 - **A chained Dataset ID that is not a dataset ID at all now says so** instead of reading as a temporary problem to retry, and a run that stops on a fault of ours now tells us what kind of fault it was, so it is looked at without anyone needing to share the run. Nothing about what is collected or charged changed. ### 1.0.44 — 2026-09-04 - **Small asks reach the profile-page read when Instagram's profile service errors or walls** — a run that has delivered nothing yet may now buy the one read that answers (the profile page) even when the ask is a handful of posts, so a single-profile run or the default sample no longer comes back empty while Instagram's own profile service answers an error. A profile that still cannot be read stays uncharged and says why. - **A walled connection no longer eats the whole run** — the retry ladder stops at the run's own time limit instead of sleeping past it, so the fresh connections and the profile-page read still get their turn inside a short run. - **A profile served by its page delivers at once** — when Instagram's profile service would not answer and the profile page did, the page's own newest posts ship immediately if they cover the ask (`postSource: "profile-page"`), instead of waiting on the post feed's retries; a bigger ask still walks the feed for the rest. - **The default sample gets four minutes instead of two and a half**, so a walled first connection can still hand over to a fresh one and to the profile page inside the sample's own window. ### 1.0.42 — 2026-09-04 - **A run that stops before it starts now reports its outcome too** — a run refused for its memory setting now reaches us the same way every other run does: counts and reason codes only, never your input or your rows. ### 1.0.41 — 2026-09-04 - **Every run now reports its own outcome to us** — counts and reason codes only, never your input or your rows — so a run that goes wrong reaches us even when nobody shares it. - **The watchlist clause of the status line no longer splits itself with a semicolon.** ### 1.0.40 — 2026-09-04 - **Run status lines fit the run page again; sample-run wording shortened.** - **Rows that carry no result fee are now described as uncharged, not free** — running any actor still uses platform time. ### 1.0.39 — 2026-09-04 - **A run that ends with a problem now says where to reach us.** A miss, an input error, an early stop or a failed run closes by pointing at the Issues tab and naming the reply time; a run that delivered everything, including one that filled the row cap you set, is left alone. - **One support promise across this page** — issues are answered in a couple of hours, always within a day. ### 1.0.38 — 2026-09-04 **A run that resumes after a platform restart now recognises every row it already delivered, so nothing is delivered or charged twice.** Apify occasionally moves a running actor to another server. When that happens, the run re-reads its own dataset to remember what it already delivered. Until now it trusted the dataset's row count, which can lag for a moment after a restart; a lagging count could make the run start over and charge again for rows you already had, or stop reading before the end. The run now checks for real rows instead of trusting the count, and reads to the end whatever the count says. Rows, prices, charges and the status line on a normal run are exactly as before. ### 1.0.37 — 2026-09-04 **A Dataset ID that does not exist is now answered as a wrong ID, and a chained dataset bigger than 5,000 rows says so instead of quietly stopping there.** - A typo in **Dataset ID** used to be read as the *name* of a new dataset: an empty one was created under it, and the run then reported that the rows you chained carried no Instagram profile — your data blamed for a wrong ID. It now returns one uncharged row naming the ID you sent and how to fix it, and nothing is created. - A chained dataset holding more than 5,000 rows is still read to that limit, but the run now ships one uncharged row saying how many rows the dataset holds and how many were read. Rows past the limit used to be dropped in silence. - A dataset that exists but this run was not given access to now says exactly that, separately from a wrong ID. A dataset you refer to by name still resolves. - Prices, events and what gets charged are unchanged. ### 1.0.36 — 2026-09-03 **A "Post type" the actor does not recognise now stops the run instead of quietly collecting every post type.** - An unrecognised value in the **Post type** dropdown returns one uncharged guidance row naming the value you sent and the options that work (`any`, `image`, `video`, `carousel`), and no posts are collected — it used to fall back to "any" and charge you for every post type. Nothing else about the run changes: leaving the field empty, or sending `null`, still means every post type, silently. ### 1.0.35 — 2026-09-03 **Listing text only — nothing changes in your rows, prices, charges or status line.** - The input-form and dataset screenshots now load from Apify storage instead of an outside host, so they render on the listing itself. - Every link that pointed outside Apify has been removed from the listing text. ### 1.0.34 — 2026-09-02 **A small ask is never asked to overpay for a hard profile, the run status counts every profile that delivered, and the profile lookup announced for 16 September is wired in ahead of its date.** - When Instagram walls a profile, the run tries further connections only while what you asked for can cover them. If it cannot — a very small result limit at a plan's lowest per-post price — the profile row says so and names the fix (ask for more posts per profile). Nothing is charged for a profile that stops there. - The run's status line now says "from N profiles" for every profile that delivered posts, including one your own result limit closed before its receipt — it used to say "from 0 profiles" on a run that had delivered ten posts. - **From 16 September 2026, each profile that delivers at least one post adds one profile lookup of $0.003** (flat, every plan). Per-post prices are unchanged; a profile that delivers nothing pays no lookup. This build carries the charge but it does not apply until that date; the pricing tab shows the exact time. - The listing's suite blocks name the change. ### 1.0.32 — 2026-09-02 **A profile Instagram's API will not serve now comes from the public profile page itself — its 12 newest posts — instead of a "please re-run" row.** - When the profile read fails on every connection the run tries (a wall, or Instagram's own error for a class of large accounts), the run now reads the public profile page as a last resort. If the post feed is refused too, it delivers the newest posts the page itself shows — up to 12 — charged per post exactly as always. Those rows say where they came from (`postSource: "profile-page"`); on that surface likes, comments, play counts and video links are not available and stay empty, and dates are day-precise. - A run that gets the full feed keeps getting the full rows; the page is only ever the fallback. - The retries after a failed first read now alternate between two kinds of connection instead of one, so a bad minute on one kind no longer decides the run. - A wall that survives every surface still ships the honest uncharged row. Nothing about prices, events or charging changed. ### 1.0.31 — 2026-09-02 **A rate-limited read now retries on a stronger connection before giving up — for the profile and for its post feed; an empty result under a date filter says how old the newest post is.** - When Instagram walls the first read of a profile, or answers it with an unreadable page, the run no longer stops there with a "please re-run" row: it retries the same profile on a fresh connection, twice at most, before it would ever report the wall. - The same now holds for the post feed of an ordinary (first-page) request, which used to give up on a wall and fall back to whatever the profile page carried — sometimes nothing. It, too, retries on a fresh connection, twice at most, before that fallback. - Rows delivered afterwards are charged exactly as always — a wall that survives every retry still ships the honest uncharged row. - When a "posted after" date excludes every post a run read, the profile row now names the date of the newest post it saw, so a correct zero no longer looks like a silent failure. - Nothing about prices, events or charging changed. ### 1.0.29 — 2026-09-02 **See what you are buying before you run it: real console screenshots in the listing.** - The listing now shows the input form exactly as it appears in the console, and the dataset table of a real run — the five newest posts of a public profile, with type, caption, likes, comments, plays and duration. You can see the fields you fill in and the columns you get back before starting anything. - Every link to another steadyfetch actor now carries that actor's current store name. ### 1.0.28 — 2026-09-02 **Watchlists: re-run the same profiles on a schedule and pay only for new posts.** - **Name a watchlist and the run remembers every post it delivers under that name** — in a key-value store in your own Apify account (`ig-posts-watch-`), which you can open or clear at any time. Every post row now carries `isNew` (was this post already on the list?) and `firstSeenAt` (when the list first saw it — this run's timestamp for a new post, the original sighting for an old one). Without a watchlist both read `null` and nothing else changes. - **Turn on "New posts only" and posts already on your list are skipped before they take a row** — not delivered again, not charged, and not counted against your limits, so a profile you check daily costs you only what it actually posted since. The run's status line and its `OUTPUT` record say how many were new and how many were skipped. - **Only a post that was actually delivered goes on the list.** A profile Instagram would not serve this minute leaves nothing behind, so the next run tries it again. A crash can never invent a sighting: the list is written after the posts are in your dataset and before they are charged. - "New posts only" without a watchlist name does not run: the actor cannot tell a new post from one you already paid for, so it ships one uncharged row saying what to add instead of charging you for everything. A watchlist it cannot open stops the run the same way, before any spend. - The default sample (Start with nothing set) is unchanged and never opens a list. ### 1.0.26 — 2026-09-02 **Start with nothing set and get real posts instead of sample rows.** Clicking Start with no profiles used to return a frozen set of sample rows. It now runs a small real sample — the 5 newest posts of one public profile (nasa) — charged like any run, so the first thing you see is live rows in the exact schema: captions, engagement, media links, tagged accounts. The status line and the profile row say it was the sample and how to run your own handles. If Instagram does not serve the profile at that moment, you still get one uncharged row explaining it plus the run's summary row, never an empty result. ### 1.0.24 — 2026-08-31 Every optional field now accepts `null`, meaning "use the default" — so a template that sends one request body per run is no longer refused before it starts. - **A `null` on an optional field is now a valid run.** Tools that build the request from a template — n8n, agent frameworks, the MCP server — render one body per run and put `null` in every field you left unset. Until this build Apify rejected those runs before the actor even started, with a message about the field's type, so the run never reached us and nothing you could set in the actor helped. `Max posts per profile`, `Max posts for the whole run`, `Max run seconds`, `Post type`, `Posted after`, `Posted before`, `Dataset ID`, `Dataset items` and `Resume cursor` all accept `null` now, and every one of them treats it as "use the default": a null limit is the default limit, a null date is no date filter, a null post type is every post type, a null resume cursor is a fresh start. None of them produce an input-guidance row. - **`Post type` is still the same dropdown**, with the same four choices and the same `Any` default. It simply no longer refuses a run outright when the field is sent empty; a value it does not recogn