Pricing

from $0.60 / 1,000 posts

Try for free

Go to Apify Store

Instagram Profile Posts Scraper — Instagram User Posts, Reels

Try for free

Instagram user posts: posts and reels from any public Instagram profile — captions, hashtags, engagement, media links — by handle or URL, no login. From $0.60 per 1,000 posts. Plus $0.003 per profile that delivers posts. Set 30, get 30. Nothing undelivered is charged.

Pricing

from $0.60 / 1,000 posts

Rating

0.0

(0)

Developer

Steadyfetch Team

Actor stats

Bookmarked

Total users

Monthly active users

2 days ago

Last modified

Changelog

1.0.163 — 2026-10-08

A run can now take up to two hours when you set it so. Before, every run stopped at one hour whatever "Max run seconds" said, so the biggest archives were cut short. Set "Max run seconds" up to 7200 and the run uses that time; above 7200 it runs at 7200 with one uncharged row saying so. What you are charged per post is unchanged.
The monthly data allowance behind this actor was raised, so a busy month no longer stops delivery part-way through. Nothing you are charged changes: the allowance is ours, not yours, and a run that ever meets it still stops honestly and charges nothing for what it did not deliver.

1.0.162 — 2026-10-06

Links to sibling actors now show those actors' current names.

1.0.161 — 2026-10-05

A story highlight link no longer collects the wrong account. A highlight link (instagram.com/stories/highlights/…) carries a number, not the name of the account that posted it, but it was read as the account called "highlights", so the run collected and charged that account's posts. Now it gets one uncharged row saying to paste the handle or profile link of the account you meant. A story link (instagram.com/stories//…) still collects the account it names, and every handle and profile link is read and charged exactly as before.
A few more Instagram app-page links are refused instead of looked up as accounts (for example instagram.com/download/ or instagram.com/tags/), each with one uncharged row naming the fix. A handle typed on its own is never refused for its spelling.
Nothing changes about the price, which rows are charged, the input fields or the output columns.

1.0.160 — 2026-10-05

A date the actor cannot read now stops the run before anything is charged, instead of running without the filter. If "Posted after" or "Posted before" could not be read, the run used to say so in a row and then collect every post anyway, so posts outside the window you meant were delivered and charged. Now no profile is looked up, every profile gets its own row saying which date stopped it, the run page names the forms a date takes, and nothing is charged.
A date with no year is no longer guessed. "Oct 1" used to be read as 1 October 2001, and "1" as 2001. A date like that now stops the run as above. A day the calendar does not have (2026-02-31, 2/31/2026) stops the run too, where it used to roll into March.
A date with a year that earlier builds read is read exactly as before. That covers 10/05/2026, 2026/10/05, October 5, 2026, the date strings programs produce ("Mon Oct 05 2026 00:00:00 GMT", "Mon, 05 Oct 2026 00:00:00 GMT") and every 2026-08-01 or 2026-08-01T09:30:00Z, so a scheduled run that recomputes its date keeps working unchanged. When such a date could be read two ways (10/05/2026 could be 5 October or 10 May, 01.10.2026 could be 1 October or 10 January), it is still read the way earlier builds read it, month first, and one uncharged note row says which day was used; write the year first (2026-10-05) to remove the doubt. A two-way date before 2010 is not guessed: the run stops and the row names both days.
More of the ways people write a date are read. A date earlier builds could not read can now be 25/12/2025 or 25.12.2025 (only one reading is possible), a 10- or 13-digit timestamp, or a span back from the run's start like 7 days, 2 weeks, 3 months, 1 year, 7d, today or yesterday.
Nothing changes about the price, which posts are charged, the input fields or the output columns.

1.0.159 — 2026-10-03

Price change from 17 October 2026 (16:58 UTC). A delivered post will cost $1.60 per 1,000 on Bronze, $1.45 on Silver and $1.20 on Gold and above (today $1.40, $0.90 and $0.60). The Apify free plan stays at $2.40 per 1,000, and the profile lookup stays at $0.003 per profile that delivers posts. The same day a new check fee starts: $0.005 once per profile a run reads that has nothing new for you, on every plan. A profile that delivers posts never pays it, and posts you already have are still never charged again. Until then nothing changes: today's prices stay in force and no check is charged.
How the check is charged, from 17 October. Once per profile, never twice in one run, and only on a profile the run actually read: one that comes back private, removed or unreachable, one the run stopped before finishing, the sample run you get by pressing Start with no input, and the Apify free plan's repeat of a check made within the hour (which reads nothing) are not charged it. It is the same per profile however you split profiles across runs, so one run for all your profiles still costs the same as one run each. A profile row that carries the check says so, with the amount.
A run that spent its time waiting no longer tells you to raise "Max run seconds". When a profile's posts were coming slowly because this run kept waiting between attempts on connections Instagram refused, the run used to say the posts would not fit and suggest a longer run, which would only have bought more waiting. It now says where the time went and that the summary row's resumeCursor continues from where it stops. When the posts themselves read too slowly to fit, the advice to raise "Max run seconds" stays.
On the Apify free plan, a profile stopped by the daily allowance now says when it can continue. It used to say "re-run to collect the rest", but a re-run before the allowance resets stops at the same point. The profile row now gives the reset time, or a paid Apify plan, and the resumeCursor still continues exactly where this run stopped.
Nothing changes about the input fields or the output columns. A profile row that carries a check also carries checkCharged: true.

1.0.158 — 2026-10-03

A walk our own limit stopped no longer says the licensed feed rate-limited it. When Instagram will not serve a profile's posts, the run reads them through a licensed data feed, and waits out that feed's busy moments. If our own side closed that feed while the run was waiting, the profile row used to say the feed had rate-limited the walk and asked you to re-run in a few minutes, which would not have helped. It now says the walk stopped part-way on our side, not because of the profile, and that the summary row's resumeCursor continues from that same page on a later run.
On the Apify free plan, a check that cannot read further now finishes in seconds. Once an account on the Apify free plan has used its daily allowance for the licensed feed, and Instagram walls the post feed, the run stops at the first wall instead of waiting several minutes for an answer that cannot change. The result is the same as before: the same posts, the same one row about the free plan allowance, and nothing extra charged.
On the Apify free plan, a long list no longer sleeps away its time limit once the daily allowance is used. When the free plan allowance for the licensed feed ran out part-way through a run, each remaining profile Instagram walled used to wait several minutes for Instagram before its row, so a 30-profile run could spend its whole hour waiting and leave a profile unread. Each profile now waits only a few seconds, as it already did while the allowance lasted, then gets its answer, and every profile on the list is reached. Instagram is still asked for every profile, so a profile it serves is still delivered. Nothing else changes, and nothing extra is charged.
On the Apify free plan, a date window too far back to reach is said up front. If "Posted before" sits deeper in a profile's feed than the free plan allowance left on your account can read, the run now stops before reading toward it, instead of spending the allowance on newer posts it would never deliver. The profile row names the window and says paid Apify plans read the whole way to it. Nothing is charged for it. The run's OUTPUT record carries profilesFreeWindow and the window's two dates.
A run stopped by your maximum cost per run before anything was charged now says so: it stopped before any charge because the maximum leaves no room for one post, so raise it. It no longer says the maximum was reached.
When Instagram's first page of a profile comes back empty, the run asks once more on a fresh connection before collecting the posts another way, so more profiles are served straight from Instagram. A profile that itself shows zero posts is not asked twice. Same price, and nothing is charged twice.
Nothing changes about the price, the input fields or the output columns. Only delivered posts are charged, as before.

1.0.157 — 2026-10-01

The input description now says how big one run can be. One run delivers up to "Max posts per profile" (resultsLimit) posts from each profile, 30 by default and up to 5,000, and up to "Max posts for the whole run" (maxItems) in all, 1,000 by default and up to 100,000, within "Max run seconds" (maxRunSeconds), 1800 by default and up to one hour. Posts the clock does not reach are not charged. By default, running the same input again carries on: posts your account already has from the last 90 days are skipped uncharged and do not count against either limit, so the run reaches further back. With "Include posts you already have" on they are delivered again, still uncharged, inside the limits; with "New posts only" on, a run stays inside each profile's newest posts; and the summary row's resumeCursor continues a cut run exactly. That memory needs the run to be able to read your account's storage; a restricted API token can block it, and the status line then says so. It also says that on a paid plan, how far a run reads through the licensed data feed when Instagram refuses grows with the number of posts you ask for. The "Instagram profiles" field names both limits in its first sentence and the default re-run rule right after. Nothing about which posts are collected, delivered or charged changed, and the price, the input fields and the output columns are unchanged.

1.0.156 — 2026-09-29

A deep profile on a long run clock keeps fetching instead of stopping early. When Instagram will not serve a profile's posts, the run reads them through a licensed data feed. Far down a long profile, that feed sometimes turns one page away — it says the page is not there, or it is busy for a moment — and serves the very same page when it is asked again. The run used to end the profile at the first page turned away that way, and on a long walk it could stop waiting after several busy moments even though each one had passed within seconds, so a run with most of its time limit left handed the rest of the profile to a second run. Now such a page is asked again after a short pause, a busy moment that has passed no longer counts against the next one, and the walk carries on to your limit or to the end of the profile. A page that keeps being turned away is still given up on after a few minutes of asking, and the rest is handed back with a resume point, exactly as before.
When the run stops waiting on that feed, the profile row now says so, with "We stopped waiting on it there rather than spend the rest of your time limit asking again." The run's OUTPUT record carries one new count, profilesPatienceCut.
Nothing changes about the price, which posts are charged, the input fields or the output columns. Only delivered posts are charged, as before.

1.0.155 — 2026-09-28

A scheduled check on a profile your account has checked before now keeps what it learned about that profile after a busy period, so quiet checks stay short. Two more things a check learns about a profile were kept in shared lists with room for 2,000 profiles each: that Instagram keeps refusing to show this profile, so the next check goes straight to the licensed data feed instead of waiting on Instagram first; and that an earlier check already read this profile down to the start of your dates, so the next check can stop at the newest page when nothing new is there. On an account that checks more profiles than that, every new entry pushed an older profile out, so some of a large scheduled check's profiles waited on Instagram again, and about a third of its quiet checks read two pages where one would do. Each profile's notes are now saved on their own, with no limit on the number of profiles, and one run can no longer overwrite another's. Notes saved by earlier builds are still used. In your account's ig-posts-watch-account store they appear as small WALL-MARK-… and FEED-PROOF-… records.
Nothing changes about the price, which posts are charged, the input fields or the output columns. A post you do not have is still delivered and charged as before.

1.0.154 — 2026-09-28

A scheduled check on a profile your account has looked up before no longer looks it up again after a busy period. The run keeps the details of each profile it looks up, so a later check that finds nothing new can answer without looking the profile up again. Those details were kept in one shared list with room for 2,000 profiles, so on an account that checks more profiles than that, every new lookup pushed an older profile out, and about half of a large scheduled check's profiles were looked up again although nothing was delivered. Several runs of one account saving at the same moment could also overwrite each other's saved details. Each profile's details are now saved on their own, with no limit on the number of profiles, and one run can no longer overwrite another's. Details saved by earlier builds are still used. In your account's ig-posts-watch-account store they appear as one small PROFILE-ID-… record per profile. A post you do not have still has the profile looked up fresh before its row, and it is delivered and charged as before.
Nothing changes about the price, which posts are charged, the input fields or the output columns.

1.0.153 — 2026-09-28

A scheduled "New posts only" check with a "Posted after" date no longer looks a profile up again after it has delivered you that profile's newest post. Once a check delivered a new post, every later check that day saw that post, which you now have, at the top of the profile, and looked the profile up again on every run although it delivered nothing. It now answers from the pages it read, and the profile row carries the details from the last lookup with their date. On such a profile a later check also reads only the newest page again, once one check has read down to the start of your dates. A post you do not have still has the profile looked up fresh before its row, and it is delivered and charged as before.
Nothing changes about the price, which posts are charged, the input fields or the output columns.

1.0.152 — 2026-09-27

The run's OUTPUT record now says, for a run that looked a profile up again, at which step of the profile's reading it did so. It carries a small lookupBought count by step, plus lookupKeyMiss, lookupKeyOther and lookupPkMismatch when the profile details saved from an earlier check could not be used. It is there so we can see why a scheduled check that finds nothing new still looks a profile up, and fix it. Nothing changes about what is read, what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.151 — 2026-09-27

A scheduled "New posts only" check whose posts you already have no longer looks the profile up again. When the newest posts inside your dates are all posts you already have, they fill the profile's result limit and nothing new can be delivered. The run still looked the profile up again on every such check, although it delivered nothing. It now answers from the pages it read, and the profile row carries the details from the last lookup with their date. The moment a post you do not have fits inside your limit, the profile is looked up fresh before its row, and it is delivered and charged as before.
Nothing changes about the price, which posts are charged, the input fields or the output columns.

1.0.150 — 2026-09-27

A scheduled check that finds nothing new on a profile with a pinned post no longer looks the profile up again. Since 1.0.149 a dated check can stop at a profile's newest page when nothing new is there, answering with the profile details from the last lookup. On a profile that had pinned an older post to the top of its grid, the run still looked the profile up again at that stop, on every check, although nothing was delivered. It now answers from the newest page alone, exactly as for a profile without a pinned post, and the profile row carries the details from the last lookup with their date. A pinned post your dates and the posts you already have would deliver is still delivered, with the profile looked up fresh before its row, and charged as before.
A profile whose post list the licensed data feed answers with an empty first page no longer looks the profile up just to write the uncharged row asking you to re-run. That row is unchanged.
Nothing changes about the price, which posts are charged, the input fields or the output columns. The run's OUTPUT record carries one new count, lookupKeptRaced, on a run that found another run of your account had overwritten a profile lookup it saved at the same moment, and wrote it back.

1.0.149 — 2026-09-27

A scheduled check whose dates move forward on every run now stops at the profile's newest page when nothing new is there. On a check with "Posted after" and "New posts only", once an earlier check has read a profile down past the start of its dates and found nothing new, a later check whose dates start no earlier reads only the profile's newest page: if that page holds nothing for you and the profile's newest post has not changed, the run stops there and the profile row says so. Until now this only worked when every check reused exactly the same dates. A profile with a new post, a check whose dates start earlier, or a check that hands back posts you already have reads exactly as before, and every post that could be delivered is still delivered and charged as before.
A profile whose post feed comes back empty on its first page is no longer reported as read to its end. Instagram sometimes answers a profile's post list with an empty first page even though the profile has posts. The run used to take that as the end of the feed: the profile row said the feed was read to its end, and your account's memory noted it, so a later scheduled run could stop early. Now that answer counts as no answer at all: the run reads the posts through the licensed data feed from the top instead (same posts, same price, nothing extra charged), or, when that is not available, ships the posts the profile itself showed and leaves the rest open to continue, or adds an uncharged row asking you to re-run. A profile that shows zero posts keeps its answer, as before.
A re-run that finds only posts you already have now stops at the newest page the next time too. Without "New posts only", a post you already have does not count against your limit, so a re-run of a profile your account holds deeply kept reading down to this actor's reading limit for the profile before it could say nothing was new, and every later re-run did the same. Now, once such a re-run has found nothing new down to that limit, the next re-run under the same settings reads the profile's newest page and, if that page holds nothing new and the profile's newest post has not changed, stops there and says so. A new post, a larger limit, another watchlist, or "Include posts you already have" reads as before.
On the Apify free plan, the run page now says which price the run was charged at and what paid plans cost. A run charged at the post price of the Apify free plan ends its run-page line with that price per 1,000 posts and the prices on the paid plans, read from this actor's own price table. It is the first thing to give way when the line is crowded, so no count or charge statement is ever shortened for it. A run on a paid plan reads exactly as before.
Nothing changes about the price, which posts are charged, the input fields or the output columns.

1.0.148 — 2026-09-26

A dated check that finds nothing new no longer fetches the profile's details again just to say so. On a check with a "posted after" date, once an earlier check of your account has fetched a profile's details, and the newest page of that profile holds nothing your dates or the posts you already have would deliver, the run now answers from that page alone, and the profile row carries the details from the last fetch with their date. It already worked this way when a check reused the same dates; it now also works when your schedule moves the dates forward on every run. The moment a page holds a post that could be delivered, the profile's details are fetched fresh before any row is built, so delivered rows, the profile fee and every charge are exactly as before.
Nothing changes about the price, which posts are charged, the input fields or the output columns. The run's OUTPUT record carries one new count, lookupKept, on a run whose profile row carries the details from the last fetch.

1.0.147 — 2026-09-26

A run cut off before it finishes is now accounted for. The run now notes its own start in its internal record, so a run that ends without finishing — a hard abort, a crash or a timeout — is still accounted for on our side. Nothing changes about what is delivered, which rows are charged, the price, the input fields or the output columns.

1.0.146 — 2026-09-26

Large runs on a paid Apify plan no longer stop part-way when many profiles have to be read through the licensed data feed. When Instagram will not serve a profile, this actor reads it through a licensed data feed, and each run had one fixed budget on that feed however many posts you asked for, so a run with hundreds of walled profiles could stop part-way on our side. On paid plans that budget now grows with the number of posts you ask for. Nothing changes about the price, which posts are charged, the input fields or the output columns, and the Apify free plan works exactly as before.

1.0.145 — 2026-09-25

A profile whose post feed Instagram keeps refusing now switches to the licensed data feed after two tries, not after about five minutes. When Instagram answered a profile but refused its post list, and the run had already used up its short pauses, it kept trying fresh connections for up to five minutes before collecting the posts through the licensed data feed. A run could sit there with "still reading posts" and nothing delivered, long enough that it looked stuck. Now, once Instagram has refused the post list on two connections in a row and no more than 48 posts are still wanted from that profile, the run switches straight away, and the run log says it was two connections in a row. In our test of that shape the switch came after about 45 seconds instead of about five and a half minutes, with the same posts and the same charges. A post list Instagram serves, one refusal followed by a served connection, a larger request, and a run where the licensed data feed is not available all behave exactly as before.
Nothing changes about the price, the input fields or the output columns.

1.0.144 — 2026-09-25

"Include posts you already have" now hands back every post you hold under your filters, even below a page your filters cut completely. A re-run with a date or post-type filter could stop at the first page where every post fell outside your filters, because an earlier run had already read that profile to its end and nothing new was below. That is true about new posts, but posts you already have were still owed back, at no result fee: they were never charged, and now they are handed back as the setting promises. A run without that setting, or with "New posts only", stops exactly where it did.
A profile whose own posts already answer your request no longer waits on Instagram for nothing. When Instagram answers a profile but refuses its post list, and the posts that came with the profile already cover what you asked for, the run used to pause and retry the post list for about eleven seconds per profile before shipping those same posts. It now ships them straight away: in our test of three profiles with ten posts each, the run went from about 57 seconds to about 11, with the same posts and the same charges. If your filters or posts you already have mean those posts do not cover your request, the run still waits and retries as before.
The "Tagged" tab now words two more endings honestly. When we stopped the licensed data feed part-way through the tab, the run page said the licensed feed had cut it short and the row said "re-run to collect the rest"; it now says the walk stopped on our side and that the resumeCursor continues from that same page on a later run. When the licensed feed said a later page of the tab had no entries after saying there were more, the row now says the feed declined that page and that a re-run adds posts only once it serves it, instead of asking you to re-run.
On the Apify free plan, the run page now says when a profile was checked within the hour. A re-run inside the hour that answers a profile from the earlier check used to show only "Delivered 0 posts from 0 profiles."; it now adds that the profile was already checked within the hour on the free plan, so it was not read again and nothing was charged.
When many runs of your account finish at the same moment, each one's note of what it read is kept. Each run now reads back its "nothing new below here" notes and the profile details it kept, and writes back any that another run's save overwrote, so a later check does not pay to read that profile again. It adds under a second, and only when another run saved moments before. One run-log line also lost a stray double colon.
Nothing changes about the price, the input fields or the output columns. The run's OUTPUT record carries one new count, profilesWindowed, on a run on the Apify free plan that answered a profile from the hourly check.

1.0.143 — 2026-09-25

A profile whose posts all fit in your result limit is no longer reported as cut short. When a profile ran out of posts while the licensed data feed was reading it, the feed could answer the page after the last post with "not found" instead of "that was the last page". The run then said the profile was "cut short by the licensed feed", counted every post above what the account has as missing, and asked you to open an issue, even though you already had every post. Now, once the walk has listed as many posts as the profile's own post counter shows (within one page of 12, because that counter can be a few posts off), that answer is read as the end of the list: the profile row says the feed was read to its end, the run is marked complete, and there is no issue ask. A "not found" well short of the counter is still reported as a partial answer, exactly as before. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.142 — 2026-09-25

On the Apify free plan, a re-run inside the hour no longer asks you to open an issue. When a run on the free plan answers a profile from the check made earlier in the hour ("checked at hh:mm UTC, nothing new since"), that is the run working as designed, but the run page added "Something off? Open an issue on the Issues tab" and the run was marked as having a problem. It no longer does either. Anything that really did go wrong in the same run, such as a profile that could not be read, still asks. Nothing changes about what is read, what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.141 — 2026-09-24

On the Apify free plan, this actor now has a daily allowance for the licensed data feed. An account on the Apify free plan can make up to 80 licensed data feed reads on this actor in any 24 hours (one read looks up a profile Instagram walls, or reads one page of 12 of its posts), and accounts on the free plan share one daily allowance on this actor. Instagram's own pages are not counted and are still read past it. Past either allowance, the run keeps every post it already delivered, adds one uncharged row saying how many profiles were not read in full and when the allowance resets (UTC), and says the same on the run page. Paid Apify plans carry no daily allowance, and nothing changes for them: not the price, the input fields or the output columns.

1.0.140 — 2026-09-24

Settings sent wrapped in an extra "input" object are now read. A run whose input arrives as {"input": {…}} — for example from run_input={"input": {...}} in the Python client — now reads those settings as if sent directly and adds one uncharged note row naming them. Before, the run stopped with a guidance row and collected nothing. Nothing changes about the price, the input fields or the output columns.

1.0.139 — 2026-09-24

A scheduled date-window check with "Include posts you already have" turned on now makes one read through the licensed data feed instead of two when nothing is there for you. Since 1.0.135 a check that an earlier run had already proved empty under the same filters reads just the profile's newest posts and skips looking the profile up again, but a check with "Include posts you already have" on never qualified, so it looked the profile up every time. It now qualifies whenever your date and type filters excluded every post the earlier run read: a post you already have is only handed back when it passes your filters, so none can be hidden by that proof. The moment the newest posts include anything your filters admit, new or already yours, the profile is looked up and those posts are delivered exactly as before.
On a dated check, a profile whose lookup Instagram keeps refusing now goes straight to the licensed data feed for about a week, not 36 hours. In 1.0.138 that memory lasted 36 hours and the check that relied on it did not renew it, so a daily check asked Instagram again every other day and waited through its paced retries (about 30 seconds) before the licensed feed read the posts anyway. It now lasts six and a half days from Instagram's last refusal: a daily check skips that wait six days out of seven and asks Instagram again once a week, and a refusal on that weekly check starts a fresh week. A profile Instagram starts serving again is noticed at that weekly check. The run's OUTPUT record's licensedFirst count names that weekly check retest. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.138 — 2026-09-24

A scheduled date-window check on a profile that Instagram's profile lookup keeps refusing now goes straight to the licensed data feed on the next day's check. Until this build, a lookup that Instagram refused and its profile page then answered was not remembered as a refusal, so every scheduled check slept through Instagram's paced retries again (about 30 seconds a check, most of it waiting) before the licensed data feed read the posts anyway. Now that refusal is remembered for 36 hours on your account, and the next check of that profile goes to the licensed data feed first: no waiting on Instagram, and the log says so once for that profile. Because a remembered refusal is not refreshed by the check that relied on it, the check after that asks Instagram again, so a profile Instagram starts serving again is noticed within about two days. A profile whose lookup Instagram answers straight away keeps its own lookup, exactly as before. When many runs of one account finish at the same moment, each run now reads that memory back at its end and puts back anything another run's save overwrote; that adds under a second, only when another run saved moments before. The run's OUTPUT record now carries a small licensedFirst count saying, for each profile the memory was asked about, whether the licensed feed was used first and why not. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.
On the Apify free plan, re-running the same profiles with a date filter inside the hour no longer reads them again. Until this build the hourly check on the Apify free plan only counted a run that had found nothing new, and a run with "Posted after" or "Posted before" that delivered posts never reached that state, so every re-run inside the hour read each profile again to hand back nothing. Now any run on the Apify free plan that reads a profile to its natural end counts as that profile's check under those settings: a run inside the next hour reads nothing for it, its row says when the check was made ("checked at hh:mm UTC, nothing new since"), the posts that check delivered are not sent again, and nothing is charged. A check your result limit filled, or that the run's own time, budget or item limit cut short, does not count, so the next run reads on. A run on a paid plan reads every profile every time, exactly as before, and a run whose settings differ is its own check. Nothing changes about which posts are charged, the price, the input fields or the output columns.

1.0.137 — 2026-09-24

When a profile's walk stops on our side, the run now says so instead of blaming Instagram. If the licensed data feed this actor reads through when Instagram will not serve was stopped by us part-way through a walk, the run page, the summary row and the profile row said "cut short by Instagram" with "please re-run". They now say the walk stopped on our side, not because of the profile, and that the resumeCursor on the summary row continues from that same page on a later run.
The "Tagged" tab no longer tells you to re-run in a few minutes when waiting would not help. That advice now appears only when the licensed feed was rate-limiting the run. When the feed turned down the next page, the row says the resumeCursor asks for that same page again, so a re-run adds posts only once the feed serves it; when this run's own time limit ended the walk, it says to raise "Max run seconds"; and when the walk stopped on our side, it says so. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.
A run that Apify restarts after it has already delivered keeps its own record of that delivery. If the restarted part of a run delivers nothing new, the run's internal record now keeps what the earlier part delivered and charged, with a note of the restart, instead of being rewritten as if nothing had been delivered; one line in the run log says so. Nothing changes about what is delivered, which rows are charged, the price, the input fields or the output columns.

1.0.136 — 2026-09-23

When the licensed data feed ends a profile's walk part-way, every part of the run now names the licensed feed and says what a re-run will do. Until this build, a page the licensed feed refused, or answered with no posts while saying more exist, was reported as "cut short by Instagram" with "please re-run", although Instagram took no part in that ending. Now the run page, the summary row and the profile row name the licensed feed, and the profile row says that the resumeCursor on the summary row asks for that same page again, so a re-run adds posts only once the licensed feed serves that page. "Please re-run" stays on the endings a re-run can fix: Instagram's own wall and the licensed feed's rate limit. And when the licensed feed serves two pages in a row that this actor cannot read a single post from, the walk now stops there instead of paging on to its page limit, and the profile row says so and is not marked retryable. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.135 — 2026-09-23

A scheduled check that finds nothing new on a profile Instagram keeps refusing now makes one read through the licensed data feed instead of two. When an earlier run on your account read the same profile with the same filters and proved there was nothing further down for you, the run now reads just the profile's newest posts and stops there, without first looking the profile itself up again. The moment those newest posts include anything you could receive, the profile is looked up exactly as before, so every delivered row, the profile row and every charge are the same. On a check that delivers nothing, the profile row's own details (followers, bio and the like) are the ones from the profile's last lookup, and the row says on which date. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.
On the Apify free plan, a profile checked within the last hour under the same settings, with nothing new, may now be answered again without a new read. The run hands back that same answer, the profile's row says when the check was made ("checked at hh:mm UTC, nothing new since"), and nothing is charged. A run on a paid plan reads the profile every time, exactly as before, and a run whose settings differ is its own check. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.134 — 2026-09-23

"Instagram profiles" is no longer marked required in the input schema. An AI agent or an API call that leaves it out gets the 5-post sample, exactly as a bare Start always has, and an explicit null there is still refused before the run starts. The field's help now opens with what to pass and an example.
The first screen of this page now says how often a profile's posts change and how to put the same input on a schedule, with what a rerun is charged: a post already delivered to your account in the last 90 days is skipped and not charged again. Nothing changes about what is delivered, which posts are charged, the price, the input fields, the output columns or the charged events.

1.0.133 — 2026-09-23

When Instagram refuses seven profiles of one run in a row, the rest of that run is read through the licensed data feed straight away. Until this build every profile in a run paid Instagram's own wait first — a paced pause and a read that never answers, about half a minute a profile on the default memory — before the licensed data feed read it anyway. Now the run counts its own refusals: after seven profiles in a row that Instagram would not serve, every later profile in that run goes to the licensed data feed first, and the log says so once per profile. One profile Instagram answers — served, private or not found — resets the count, so a run Instagram is serving is unchanged, and so is any run that is never refused seven times in a row, a run with the licensed feed unavailable, and the bare sample run. Measured in the test harness on a ten-profile list Instagram refused throughout: 30 Instagram reads down to 21, 198 seconds down to 146, the same licensed reads, the same posts delivered and the same charges. It works beside the per-profile memory from 1.0.124 and 1.0.128, not instead of it. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.
A few older notes on this page quoted our own internal running costs; those figures are gone. What each note says about your runs, and its date, is unchanged.

1.0.132 — 2026-09-22

A failed internal bookkeeping write no longer prints its storage address in the run log. Nothing changes about what is delivered, which rows are charged, the price, the input fields or the output columns.

1.0.131 — 2026-09-22

Under a tight "Maximum cost per run", the run now stops exactly where your cap runs out, and every row that says it was charged was. The run keeps a count of how many posts your cap can still pay for, and until this build that count was sized from the post price alone: the one-off profile lookup that each delivering profile adds came out of the same cap without being counted against it, so on a cap that binds the run could hand out a few more posts than the money covered — those last posts were delivered and never charged, and their rows still said charged: true. Now the lookup is counted out of the same pool the posts are, and each row of a page is checked against what that page has already set aside, so the row's charged column and your charge agree to the post. On a run without a cost cap, or on a cap large enough not to bind, nothing changes; where a cap binds you will see slightly fewer rows and the same charge. Nothing else changes about what is delivered, the price, the input fields or the output columns.

1.0.130 — 2026-09-22

The run log no longer prints internal cost lines. When Instagram refuses a page and the run switches to the licensed data feed, the log used to quote two of our own unit costs to explain why; it now says which way the run went and why in words. Your rows and charges are unchanged.

1.0.129 — 2026-09-22

How a source outage is handled is now explicit: an answer that says nothing about the profile you asked for is read as temporary, never as a final verdict. The licensed data feed behind the rescue path answers with a status code of its own when its servers are unreachable, and the run classified any answer it did not have on a short list as a final refusal about your profile. In practice the run always went on to report those as temporary and uncharged, so no run has ever told you a profile was refused for good on that basis — but the rule was the wrong way round, and it now matches what you already saw: only the answers the feed actually gives ABOUT the profile you sent — not found, private, malformed — are final, and everything else is retried inside the run and reported as an uncharged row worth re-running. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.
An answer the data source has never sent before now counts as an outage rather than as something we paid for. The run keeps its own record of which of the source's answers cost us money, and until this build that record was a fixed list — so a response nobody had listed, such as a code the source first sent during an outage, was read as one we had bought. Now only the answers the source actually bills count as bought; everything else is booked at nothing and simply tried again. Nothing changes about what is delivered, what you are charged, the price, the input fields or the output columns.

1.0.128 — 2026-09-22

A daily check of a profile Instagram refused to look up yesterday now goes straight to the licensed data feed, and the memory that decides it no longer loses its marks when many checks run at once. Two things, both about a profile this actor already knows Instagram will not serve on your account. First: since 1.0.124 a profile Instagram walled on your account's last two checks within a day is read through the licensed data feed first rather than pausing on Instagram again. A check that runs once a day can never have two inside a day — the mark is not refreshed by the run that used it, so the second check always arrives just after the first has expired — and we measured the cost of that on one scheduled watcher's own runs: roughly 855 dated checks a day, every single one of them still paying the pause, and a median of 31.9 seconds a run made up of about 11.3 seconds of pausing plus one 20-second connection that never answers. On a dated check, one refusal within the last 36 hours is now enough, which is what a daily schedule can actually meet. Measured on that shape in the test harness: 11,290 milliseconds of pausing down to none, no connection attempted on Instagram, and the same one licensed page read, the same posts delivered and the same posts charged. It counts only where Instagram refused to look the profile up at all: where Instagram served the profile and walled only its post feed, the profile is still read from Instagram, because reading it through the licensed feed would buy a request the run does not otherwise need — that shape is unchanged to the millisecond, and so are a request with no date window, a request deeper than one page, a run with no licensed feed available, a profile with nothing remembered, and the bare sample run. Second: that memory — and the "nothing new below here" marks the run keeps beside it — were each written back whole at the end of a run, so when fifteen checks ran at the same time, as they do in that watcher's daily burst, only the last one to finish left a mark and the other fourteen were lost. Every write now merges with what is already there instead of replacing it. Measured with fifteen concurrent runs over one account: one mark of fifteen survived, now fifteen of fifteen, with the newest marks kept, a profile Instagram has just answered still cleared, and the stored record in exactly the same format an older build reads. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.127 — 2026-09-21

When Instagram stops answering a post feed rather than refusing it, the run now waits twenty seconds instead of forty, and gets on with the next profile. Instagram does not always say no to a post feed — sometimes it simply holds the connection open and never answers, and the only thing that ends the request is this actor's own twenty-second limit. Until now a connection that ended that way was treated as a dropped line and tried once more on the same connection, which is the right thing to do when a cable drops and the wrong thing when the other end has quietly stopped answering. We measured it properly: over 1,252 live attempts, 71 first reads went unanswered that way, and the second twenty seconds returned nothing at all — zero times out of 71. Sixty-one of them went unanswered for another full twenty seconds, and the other ten came back with a sign-in wall, which is not posts either. So that second wait is gone. A genuinely dropped connection still gets its one immediate retry, unchanged. What this is worth, measured on the same shapes in the test harness: a dated check of a profile with nothing remembered finishes in 24.9 seconds instead of 44.9, reading the same one licensed page and delivering and charging exactly the same posts; a watchlist of nine profiles asking four posts each now reaches all nine and delivers 36 instead of 20 in the same time limit, still buying no licensed page at all; and a deep run of nine profiles at thirty posts each delivers 96 instead of 78. This also corrects the arithmetic in the note below for 1.0.126, which was right about the code as it stood: that stalled first connection cost forty seconds of platform usage, so waiting was worth it only where Instagram answered a profile more than about seven times in ten. It now costs twenty seconds, half of that, so the line is about one time in three — and the profiles that memory sends straight to the licensed page still answer far under it, between one and two times in ten, so the same checks skip the same connection as before. The run's own summary now also records how many reads went unanswered this way, so a slow run can be explained instead of guessed at. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.126 — 2026-09-20

On a dated check of a profile Instagram has walled on your account in the last day and a half, the run no longer waits on a connection that has stopped answering — it reads the licensed data feed first, which is the page it was going to read anyway. 1.0.125 stopped this shape buying extra connections to retry a refused feed. Measured on our own run of the scheduled shape the next hour — one profile, a date window, a 120-second limit, 256 MB — what is left is the connection the run already had: the profile itself was read from Instagram in 2.5 seconds, and then the post feed spent 40 seconds on two requests that never came back, each one ended by this actor's own 20-second timer, with nothing paused and no paid connection used, before the run read the licensed page in 5.3 seconds and delivered from it. Forty of that run's fifty-three seconds were spent on a feed that answered nothing, and they are now the whole platform cost of a check that finds nothing new. Those 40 seconds of platform usage are weighed against the licensed page they can save, so waiting is worth it only where Instagram answers that profile more than about seven times in ten — and on the profiles this remembers it is measured between one and two in ten. So a dated check of a profile whose feed walled on this account within the last 36 hours goes straight to the licensed page, and the run says so in its log. Measured on the same shape in the test harness: 44,900 milliseconds down to 4,900, two Instagram feed requests down to none, the same one licensed page read, the same posts delivered and the same charges. Everything else keeps every connection it takes today, to the millisecond: a request with no date window, a request deeper than one page, a run with no licensed feed available, a profile with nothing remembered, and the bare sample run. A profile Instagram does serve is never remembered at all, so it is never affected. The memory is not refreshed by the run that used it, so Instagram's own surface is re-tested at least once every 36 hours. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.125 — 2026-09-20

On a scheduled check that one page answers, a connection Instagram has just refused is no longer retried on further connections — the licensed data feed reads the page instead, because the retries cost more than the page they are trying to save. Since 1.0.110 this actor has bounded the PAUSING between those retries to what it is worth: about eleven seconds per profile, priced against the one licensed request that pausing could save. Nothing priced the retries themselves, and on this shape they are the dearer half. Measured on our own run of the scheduled shape on 20 September — one profile, a date window, a 120-second limit, 256 MB: the profile itself was read from Instagram in 5.7 seconds, and the post feed then spent 30.9 seconds and 55.8 kilobytes of paid connection across five attempts on four fresh connections, delivered nothing, and the run read the licensed page it had been avoiding in 3.5 seconds anyway. One of those fresh connections costs about three times the platform usage it can save — one page at the recovery odds measured over seven days of this actor's own runs, where 183 of 2,812 runs that retried at all went on to deliver from Instagram. So on an ask the licensed feed answers in a single page, Instagram is still asked first on the connection already in hand, and a refusal hands over rather than buying another connection. Measured on the same shape in the test harness: four fresh connections and 55.6 kilobytes of paid transfer down to none, eight Instagram reads down to four, and the run twenty-seven per cent shorter, with the same page read, the same posts delivered and the same charges. A request deeper than one page, a run with no licensed feed available, the profile-page rescue and the bare sample run all keep every connection they take today, to the millisecond. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.124 — 2026-09-20

A profile Instagram has walled on your account's last two checks is now read through the licensed data feed first, instead of pausing on Instagram again before buying the same page. When Instagram refuses a profile, this actor retries on fresh connections with a pause between them, and reads the profile through a licensed data feed when those run out. Since 1.0.110 that pausing has been bounded to what it is worth — about eleven seconds per profile — on the measured odds that roughly one in five runs which pause goes on to deliver from Instagram itself. Those odds are honest across every account and wrong for the profiles that actually spend the pause: over the seven days to 20 September, of 2,812 runs that paused at all only 183 delivered from Instagram without the licensed feed, and on one scheduled watcher it was 36 of 2,442. So the run now remembers, per profile and per account, when its last checks all ended with the licensed feed answering: after two such checks inside a day, the next one goes straight to the licensed feed and skips the pausing it has already measured as waste. The one page it reads is the page the run was going to read anyway — same posts, same result limit, same per-post price, nothing extra charged. Measured on a nine-profile watched list with a 212-second limit: 76,400 milliseconds asleep and 181 seconds of the limit spent today, against nothing asleep and 23 seconds with the memory, with the same nine profiles read, the same posts delivered and the same charges. The memory never refreshes itself: it expires after a day, so Instagram's own surface is re-tested, and one profile Instagram does serve clears it immediately — a profile Instagram answers is never remembered at all. A run with no licensed feed available, a request deeper than one page, and a profile with nothing remembered are all unchanged to the millisecond. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.123 — 2026-09-20

When this actor's own time limit cuts a run before your ask is filled, the run now tells you the number to type next instead of telling you to raise something. Until this build a run that stopped on "Max run seconds" said only "stopped before the run timeout — raise "Max run seconds" (or the run timeout) to collect more", which is true and says nothing about how far. One buyer spent thirty-seven runs across two days finding that number by trial on a sixty-profile list, and two others asked once for far more than an hour could deliver, got under one per cent of it with no explanation, and did not come back. A cut run now measures its own rate out of the run that just happened and says what fits: "This run collected 0.23 rows/s, so the whole ask needs about 1,400 s — raise "Max run seconds" to 1,500." When the whole ask is past this actor's one-hour ceiling, it says how many runs to split the list into rather than naming a setting that cannot go that far — and when the run timeout rather than our field is what cut it, it never names our field at all. The same five numbers ride the run summary and the _summary row (askedRows, deliveredRows, elapsedMs, rowsPerSecond, and exactly one of suggestedMaxRunSeconds or suggestedSplit), so an API caller or an agent reads them without parsing a sentence, and the README now states this actor's measured throughput band beside the setting it explains. The sentence appears only where our own clock cut a run that was still delivering: never on a limit you set, never on a cost cap, never on a server move, and never on a run that finished your ask. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.122 — 2026-09-20

A request for more than one page of posts no longer sleeps most of its time limit while the licensed feed is open and answering. When Instagram refuses a profile, this actor retries on fresh connections with a pause between them, and reads the profile through a licensed data feed when those run out. Since 1.0.110 those pauses have been bounded wherever one read of that second source could answer the request — about eleven seconds per profile — and a request for more than a page of posts was left out of that entirely, on the reasoning that one read cannot stand in for two pages. It cannot; but it can stand in for part of it, and the bound was always a price rather than a yes or no: a pause is worth buying while it costs less than the reads it saves, so a request for three pages is worth three times the pause of a request for one. Measured on a nine-profile request for the newest 30 posts each, with the licensed feed funded and open the whole time: 1,495 seconds asleep in a 1,775-second run — 84% of it, with one profile alone asleep for 152 seconds — eight of the nine profiles reached, 48 posts delivered, and thirty posts written off against the run's own time limit. Each profile now gets a pause allowance of its own, priced at the pages it asked for: 305 seconds asleep in a 483-second run, every one of the nine profiles read, 54 posts delivered and charged, and nothing cut by the time limit. Nothing is skipped to get there — every connection and every retry is still attempted in full, and only the waiting between them is bounded. A request with no second source available keeps every pause it takes today, unchanged to the millisecond, and so does a run with a date window, which is answered from the newest posts and was already bounded. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.121 — 2026-09-20

The pause between whole retry rounds is now bounded the same way every other pause already was — so a run on the default time limit no longer sleeps almost all of it while the licensed feed is open and answering. When Instagram refuses a profile, this actor retries it on fresh connections, waits a minute or two, and runs the whole round again; when those rounds run out it reads the profile through a licensed data feed instead. Since 1.0.110 the short pauses inside a round have been bounded on any request one read of that second source can answer — about eleven seconds per profile — but the long pause between rounds was never part of that: it asked only how much of your time limit was left. On a short limit it never came up. On the default Max run seconds of 1,800 it is the whole run. Measured on a one-profile request of exactly that shape, with the licensed feed funded and open the entire time: 461 seconds asleep in a 501-second run — 92% of it — of which 450 seconds were those between-round pauses, and the bound that was meant to price this run's sleeping accounted for none of them. The pause now asks the same question every other pause asks, and the answer is booked against the same budget, so on that request the run sleeps 11 seconds instead of 461 and finishes in 25 seconds instead of 501, with the same profile read and the same posts delivered and charged. Nothing is skipped to get there: every connection and every round is still attempted in full — what is bounded is only the waiting between them. A run with no second source available keeps every pause it takes today, unchanged to the millisecond, and so does a request deeper than one page with no date window, apart from the one licensed read 1.0.115 already holds back for it. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.120 — 2026-09-20

A one-profile date-window check on a short time limit no longer sleeps most of the run when the licensed feed can answer it. When Instagram refuses a profile, this actor pauses and retries on fresh connections, and reads the profile through a licensed data feed when those run out. Since 1.0.110 those pauses have been bounded on any request one read of that second source can answer — about eleven seconds per profile — but the bound switched itself off whenever Include posts you already have was on, on the reasoning that a run handing back posts you already hold is no longer a simple yes/no check. That reasoning belongs to a different decision: what the second source costs to read is the same whether you keep the repeats or not, and it is the cost the bound is priced against. So the one shape it was written for — one profile, a date window, a short Max run seconds — was the shape it never reached. Measured on a scheduled run of exactly that shape: about fifty-two seconds asleep in a ninety-four-second run, more than half its life, and of ninety-one such runs in one morning only eleven of the pauses recovered anything at all while the licensed feed went on to answer. The bound now applies to a date window whatever you set for repeats: on the same shape the sleeping falls to the priced eleven seconds and the run finishes in about a third of the time. Every read is still attempted — only the pauses between them are bounded — and a run with no second source available, or one asking for more than a page with no date window, keeps every pause it takes today. Nothing changes about what is delivered, which posts are charged, the price, the input fields or the output columns.

1.0.119 — 2026-09-20

A run with many profiles and a short time limit now reaches every profile: the patience budget is spent per profile, never all on the first few. When Instagram refuses a profile, this actor pauses and retries on fresh connections, and reads the profile through a licensed data feed when those run out. Since 1.0.110 those pauses have been bounded on any request one read of the second source can answer, and the bound is worth about eleven seconds per profile — but it was one budget for the whole run, and nothing stopped a single profile taking all of it. On a list of nine profiles with a 222-second limit, the first two profiles each spent about forty-eight seconds of it, a third took the rest, and the profiles after them met an empty budget with the run's clock already gone: seven of the nine were reached and two were never read at all. Each profile now has its own share, a share a profile does not use is not passed to the next one, and the whole run still spends no more than it did before. On the same list, all nine profiles are now read, inside the same 222 seconds, and none is left "skipped — the run's time limit". A run asking for one profile is unchanged to the millisecond, and so is any run with no second source available. Nothing changes about what is delivered, the price, the input fields or the output columns.

1.0.118 — 2026-09-20

A watched list of profiles no longer spends most of its time limit waiting on Instagram. When Instagram refuses a profile, this actor retries on fresh connections with a pause between them, and reads the profile through a licensed data feed when those run out. Since 1.0.115 those pauses have been bounded on any request one read of the second source can answer — but the bound looked at your filters as well as at how many posts you asked for, so setting Post type (or a date window together with "Include posts you already have") switched it off. A watched list of nine profiles asking for four posts each spent more than half its 222-second limit asleep, reached six of the nine, and returned four posts. The bound now looks only at depth — up to one page of posts per profile, and no resume point — because your filters change which of a page's posts you keep, never what the page costs to read. Filtered runs asking for more than a page keep every pause they take today, and so does any run with no second source available. Nothing changes about what is delivered, the price, the input fields or the output columns.
A profile your own "Max run seconds" cut off now says so even when that limit had already stopped the run. 1.0.115 added an honest row for a profile Instagram would not serve and your time limit left no room to read through the second source: it names the setting and the two things that fix it, instead of naming Instagram and asking for a re-run into the same limit. That row could not appear on the runs it was written for — the moment the time limit stopped the run, the second source counted as closed for every reason at once, and the profile went back to reading "temporarily unavailable, please re-run". Those profiles now get the honest row and their posts are counted against the time limit that really stopped them. A profile stopped by something else — your result limit, your cost cap — keeps exactly the row it has today, and so does one where no second source was ever available.
A profile that hands back posts you already have, and then delivers a new one, now carries its profile lookup like any other. The $0.003 profile lookup is charged once per profile that delivers a post you are charged for. It was being skipped whenever the first row handed back for that profile was one you already had: the fee was waiting for the profile's first row rather than for its first charged post, and a repeat filled that place. A profile that hands back only posts you already have still pays nothing at all — no post fee and no lookup — exactly as before. No price, input field, output column or charged event changed.

1.0.117 — 2026-09-20

An Instagram “Copy link” address of the instagram.com/s/… kind is now recognised as a share link, instead of being read as an account called “s”. Instagram mints share links under two paths — /share/… and /s/…, the one it uses for stories and highlights — and only the first was recognised. The second was read as a one-character profile name, so a lookup was spent on an account that does not exist and the answer came back “not found” about a link that really did carry a profile behind its redirect. It now gets the same plain sentence the other share links get: open the link, then paste the handle or the profile URL it lands on. Nothing is read and nothing is charged for it. Real accounts are untouched, including one whose name simply starts with s, and s typed on its own is still read as the account you named. No price, input field, column or charged event changed.

1.0.116 — 2026-09-19

Links passed under directUrls — the field name the most-used Instagram scraper on the store uses — are now read as "Instagram links or handles" instead of being ignored. If you arrive from another Instagram actor, or send input built by an agent that read one, your links often carry that name. This actor does not have a directUrls field, and until this build a run that sent one collected nothing: it ended with a single uncharged row saying that name is not an input field here, which is honest and leaves you with no posts. The links are now read, each one placed by its own shape: a profile link or a handle becomes a profile to collect, a single post or reel link still points you at our reel transcript actor, and a hashtag or other app link still says it is not a profile. The run adds one row, charged nothing, naming the field you set and the field this actor reads, so your next run needs no guess. Nothing changes about what is delivered, the price, the input fields or the output columns.

1.0.115 — 2026-09-19

On a short run, profiles Instagram would not serve are now answered through the licensed data feed before the run's time limit, instead of waiting out Instagram's cooldowns first. When Instagram refuses a profile, this actor retries on fresh connections with a pause between them, and reads the profile through a licensed data feed when those run out. On a run with a small "Max run seconds" and several profiles, the pauses could use up the whole limit first — so the second source was reached for the first profiles on the list and the rest came back as "temporarily unavailable, please re-run", even though the second source would have answered them in about a second each. Two things change. The pauses are now bounded on any request one read of the second source can answer — a date window, or up to one page of posts per profile — as they already were on a date window. And whatever the pauses are allowed to spend, they can no longer spend the time the second source itself needs: the run keeps enough of your limit back to read it. A profile our own time limit really did cut now says so, and points at the settings that fix it, instead of naming Instagram and asking for a re-run into the same limit. A run with no second source available is unchanged: it keeps every fresh connection and every pause it tries today. Nothing changes about what is delivered, the price, the input fields or the output columns.

1.0.114 — 2026-09-19

A run that stopped on the second data source now says so — before this build it could read as Instagram cutting the walk short. When Instagram stops serving a profile's post feed part-way through, this actor carries the walk on through a licensed data feed. If that second source is what eventually stops the run, the profile's own row already said so; the run page and the summary row did not — they said the walk was cut short by Instagram, which sends you to a fresh connection for a limit a fresh connection cannot clear. All three now name the source that actually stopped the walk, and a walk Instagram really did cut is worded exactly as it always was. A run your own settings ended — the scan limit on a far-back date window, "Max run seconds", your row or cost cap — keeps its own row and its own wording, whichever source was reading when it ended. The same applies to the tagged-posts tab, which Instagram's own feed never serves. Nothing changes about what is delivered, the price, the input fields or the output columns.

1.0.113 — 2026-09-19

A profile whose post feed refuses from the very first page is now continued through the licensed data feed on the same run. When Instagram serves the profile itself but then refuses its post feed from page one, the run tries fresh connections until it has exhausted what it is allowed to spend on them — and then, until this build, it could stop there and hand you a resume point instead of posts. Whether the second source was reached depended on how the run ran out of patience rather than on what it had learned: one way out of the wall opened it and the others did not, and a run inside a date window took a way that did not. It now reaches for the second source on the fact alone — the profile read proved the account is real and your request still has room the feed could fill — whichever way the connections ran out. The same page is asked for, at the same price, and nothing extra is charged for it. A run with no second source available is unchanged: it keeps every fresh connection it tries today and ends exactly as it does now. Nothing changes about what is delivered, the price, the input fields or the output columns.

1.0.112 — 2026-09-19

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

1.0.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 has been raised — 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

Instagram Profile Posts & Reels Scraper · No Login

data-slayer/instagram-posts

Scrape all posts from any Instagram profile — no login. Get likes, comments, shares, captions with parsed hashtags & mentions, tagged users, collaborators, carousel media, video URLs, and timestamps. 107 fields per post including a 24-field creator profile. JSON/CSV/Excel.

Data Slayer

1.1K

Instagram Posts, Reels & Comments Scraper [NO LOGIN] ✅

unseenuser/IG-posts

Instagram posts scraper. Get every public post, reel, and carousel from any profile in one run. Optional comments, story highlights, AI transcripts, engagement metrics. No login. Split IG/FB plays. Carousel slides per row. Outcome summary. 99.7% success.

Unseen User

542

4.7

(5)

Instagram Boolean Search Scraper | Posts & Reels

scraping_solutions/instagram-boolean-search-scraper-posts-reels

Search Instagram posts and Reels with Boolean queries using AND, OR, NOT, phrases, keywords, and hashtags. No login or cookies. Filter by date, engagement, and content type, then export structured JSON, CSV, or Excel for brand monitoring, trend analysis, lead generation, and content research.

Scraping Solutions

210

3.9

(4)

Instagram Scraper

vortex_data/instagram-scraper

One Instagram scraper for everything — profiles, contacts (emails & phones), posts, reels, comments, likers, followers, following, tagged, stories, highlights, hashtags, locations & search. No code: paste usernames or URLs, export to Excel, CSV, JSON or API. Public data needs no login.

VortexData

256

5.0

(2)

Instagram Posts & Reels Scraper

intropix/instagram-posts-reels-scraper

Scrape Instagram posts and reels with no login, no cookies, no OAuth. Captions, likes, views, comments, carousels, video URLs as clean JSON from $1.90 per 1,000 posts.

IntroPix _

288

5.0

(1)

Instagram Stories & Highlights Scraper

goat255/instagram-stories-highlights-scraper

Scrape current Instagram stories (24h tray) and all permanent highlight reels with inner items from any public profile. Get original-resolution media URLs, expirations, music, stickers, captions. No Instagram API key, no login.

Goutam Soni

5.0

(2)

Instagram Scraper

automation-lab/instagram-scraper

Scrape public Instagram profiles, posts, comments, reels, and hashtags. Public routes are tried first; supply an Instagram session cookie for login-gated workflows. Export as JSON, CSV, or Excel.

Automation Lab

1.2K

4.8

(3)

Instagram Post Scraper

clappi/instagram-posts-scraper

Scrape Instagram Posts and Reels with combined Instagram + Facebook metrics. Get views, likes, comments from both platforms when content is cross-posted — all with built-in authentication, no cookies required.

Clappi

419

4.5

(2)