Download Instagram followers and following lists from any public account. Every profile returns emails, bio links, engagement rate, business category and language — 20+ fields, with 12 filters to keep only the accounts you want. No login needed. Export to CSV, JSON or Excel.
Profiles that a profile-level filter turns down (Min / Max Followers, Verified, Account Type, Category, Influencers, Website, Contact Info, Location, and Keywords searched in the bio or name) are now judged before their posts and Reels are read, so runs with these filters finish faster. Results, the reason each profile was skipped, and the price are unchanged; skipped profiles are charged as before. When you later re-filter such a run for free with a looser profile filter and a post-based filter (Last Post, Last Reel, Engagement Rate, Median Views, Posts in Period), profiles whose posts were not read are listed as skipped for that reason instead of being judged.
[3.1.98] - 2026-10-16
Changed
Reels columns (Reels Count, Last Reel (Days Ago), Median Views, Views/Followers Ratio): when a profile's latest posts already include at least three Reels, these columns are computed from those Reels, and the run finishes faster. Median Views can read somewhat lower than before, because the newest Reels are still gathering views. Runs with a Reels filter on are unchanged.
The "Reels Count" column is now described as what it is: how many of the profile's most recent Reels the Reels columns were computed from (usually 12 or fewer), not the profile's lifetime total.
[3.1.96] - 2026-10-14
Maintenance
Internal maintenance. Results, columns and price are unchanged.
[3.1.95] - 2026-10-14
Maintenance
Internal maintenance. Results, columns and price are unchanged.
[3.1.94] - 2026-10-14
Added
Contacts behind the bio link: when a profile shows no email or phone on Instagram, the page its bio link opens is now checked too — a link-in-bio page like Linktree or Beacons, a WhatsApp link, or the account's own website (its home page and contact page). A contact found there fills the Email or Phone column and counts for the Contact Info filter, so a profile that keeps its contact behind the link is no longer turned down for having none. The new Phone Source column and the Email Source column say where each contact came from (link_page, website, whatsapp). Same price per profile.
A phone number written in the bio text (for example "call (305) 555-0142") now counts like an email in the bio: it fills the Phone column and passes the phone contact filters.
[3.1.93] - 2026-10-11
Changed
Maintenance: internal improvements. No change to inputs, results, run time or price.
[3.1.92] - 2026-10-11
Changed
Maintenance: groundwork for faster, better-targeted searches. No change to inputs, results, run time or price.
[3.1.91] - 2026-10-08
A temporary error from Instagram data is waited out instead of skipping the follower after a few seconds. When a follower's posts or Reels answered with a temporary error, the request was asked three times over about nine seconds and the follower was then skipped. These errors sometimes last a few minutes. A request now keeps asking, spread out, for up to about two minutes of waiting — never past the run's own timeout. If two requests in a row still fail, the run stops asking and reports what is left as not read this time. Nothing is charged for anything not read.
[3.1.90] - 2026-10-05
New title: «Instagram Followers & Following Scraper — Lists, No Login». The README heading matches it. Input fields, output columns, defaults and pricing are unchanged from 3.1.89.
[3.1.89] - 2026-10-02
A follower whose posts or Reels could not be read is no longer judged without them, or charged for. At a busy moment, when a profile's posts or Reels could not be read in time, the profile went on to your filters without them. An engagement or date filter then rejected it — "no media to calculate engagement rate" — and that rejection was charged. Without such a filter it came back with empty engagement and views columns, also charged. Now such a profile is not delivered and not charged, and SKIPPED_ACCOUNTS lists it as not read this time.
A busy moment no longer ends a read after a few seconds. When many runs ask for Instagram data at once, a request used to be given up after about 7 seconds. It now waits its turn, never past the run's own timeout. A dropped connection or a temporary error is asked again before anything is given up.
[3.1.88] - 2026-10-01
The price limit per kept profile now keeps to its price check budget. Until the check is done, a profile starts only while the price check budget can still pay for it together with the profiles already being analyzed. If nothing passes your filters, the run spends no more than the check budget — before, profiles that started at the same time could add to it.
[3.1.87] - 2026-10-01
Continue a finished run without paying twice for the same profiles. Every run that analyzed profiles now leaves ready inputs in the RUN_ACTIONS record: refresh the profiles it delivered, find new profiles in the same lists, or re-filter the profiles it already read. Find new skips every account the earlier run analyzed — kept or rejected by your filters — so none of them is charged again. Re-filter applies new filters to the saved profiles, the rejected ones included, with no new extraction charge. Nothing starts on its own: each follow-up needs an explicit start with a budget you choose. A run that kept nothing gets the same options.
New optional price limit per kept profile. Set a maximum cost per kept profile and a price check budget. Once the check budget has been charged, the run starts no new profiles if its cost per kept profile is above your limit, or if nothing has passed your filters. Profiles already being analyzed finish and are charged as usual.
Max budget is now in the input form. It is optional for an ordinary run and required for a paid follow-up.
Every run that analyzed profiles ends with its numbers on the status line — profiles analyzed, kept, and charged. RUN_SUMMARY adds analyzed, kept, chargedUsd and nextActions for apps and AI agents.
[3.1.86] - 2026-09-30
Category filters and the influencer category list now match capitalization variants while preserving the original category in results.
Low nonzero filter yield now reaches API and MCP clients as free dataset diagnosis rows: an interim measurement after at least 100 analyzed profiles with fewer than 20% kept, inside the first 20 dataset items when still possible, and a final count, including when the yield recovers. Restarts reconcile actual profile rows so notices never become profiles or paid work.
[3.1.85] - 2026-09-29
A target account whose owner has hidden its followers or following list is now reported as exactly that, not as a temporary error. The run names the account and the list and says that running again won't change it. Before, it said "Couldn't finish reading — please re-run". Nothing is charged for a hidden list. The account is listed in SKIPPED_ACCOUNTS with the category list_hidden.
When some target lists are hidden and the others were read, the run names the hidden ones.
[3.1.84] - 2026-09-24
Every profile row now includes Email, Email Source, Phone, External URL, Category and Address, with no filter needed and at no extra cost. Before, Email and Phone came only with the Contact Info filter, and the other three not at all. "N/A" means the profile publishes none. The Contact Info filter still keeps only profiles with contact details.
When your filters keep only a small share of the profiles analyzed, the run says so first — how many were kept, which filter rejected the most, and what to change — and the status line shows the kept share.
Setting only Keywords now shows the narrow-filter warning before the run, and on the run's status line.
The narrow-filter warning names only the filters you set, in the Input form's words.
A run with no results always ends with an explanation, and returns one row (Source "Run diagnosis") so apps and AI agents get it too. That row is never charged.
On very large runs, "No profiles matched your filters" names the filters that rejected the most profiles across the whole run.
Docs: to continue an interrupted run, click Resurrect; a new run starts from zero.
A run no longer stalls, or stops without explanation, when Apify doesn't give it access to a storage it uses. If a run can't start, it now says why and what to do in the USER_MESSAGE record (Storage tab) and in its status line.
[3.1.83] - 2026-09-23
A followers or following list that could not be read is no longer reported as a missing account. When the target account opened fine but its list could not be read, the run used to say the account might be deleted, banned or misspelled. It now says the account itself is reachable, that the read did not complete this time, and that this is almost always temporary — a re-run usually works.
[3.1.82] - 2026-09-11
Followers and following lists no longer skip accounts when the list changes while it is being read. When accounts move around in a smaller list while the run collects it, the run now checks the list again and collects the accounts it would otherwise have missed, instead of delivering a list that is quietly a few people short.
The incomplete-list note appears less often. On lists small enough to be checked again, the USER_MESSAGE and RUN_SUMMARY.partialListReads note now covers only the accounts that still could not be collected.
[3.1.81] - 2026-09-10
A followers or following list that comes back short now says so. When fewer accounts arrive than the profile declares, the run reports how many of how many were delivered — in the RUN_SUMMARY storage record and, unless the run has something more important to tell you, in its message. Until now a short list passed without a word.
The note says what actually happened. A list can change while it is being read, and then some accounts are skipped — running again may return a slightly different set. When Instagram limits how much of a list is visible on some Verified and Business accounts, the note says that instead.
Clearer reasons when a list cannot be read. The run log and the skipped-accounts record now describe the problem in plain words.
[3.1.80] - 2026-09-10
Clarified wording in the documentation and earlier changelog entries. Nothing changes in how the actor runs, what it returns or what it costs.
[3.1.79] - 2026-09-10
Follower and following lists work again. Since 9 September the follower list could not be read at all, and runs finished with no results and no explanation. Lists are now read through a different route and return data as before. If you ran this actor on 9 or 10 September and got an empty result, please run it again — you were not charged for those runs.
An empty result now tells you whether the list was empty or unreadable. These are opposite facts and the actor used to report both the same way. A list that cannot be read is now reported as a temporary problem on our side, not as a fact about the account you asked for.
[3.1.78] - 2026-09-09
A brief hiccup no longer makes a real, public account look deleted. When an account can't be looked up on the first try, it is now double-checked through a second, independent route before being reported as unreachable. Accounts that really are deleted, private, or mistyped are still reported exactly as before.
A run that returns nothing now says why in its status line. Previously an empty run finished green with an empty status box, and the explanation was only in the USER_MESSAGE record in the Storage tab.
Clearer wording when nothing could be scraped. The end-of-run note no longer says "Nothing was charged" on runs where some accounts were read and then rejected by your filters — reading is what the charge is for, so the note now says which part was charged and which wasn't.
Hitting the free-plan ceiling no longer ends the run in silence. Such a run used to stop without writing its summary or its explanation; it now finishes normally and tells you what happened.
[3.1.77] - 2026-09-09
When a run cannot finish, it now says so in one plain sentence instead of passing along
raw error text. Input fields, output columns, defaults and pricing are unchanged from 3.1.76.
[3.1.76] - 2026-09-04
Fixed
Creator accounts were being reported as personal, and the account-type filter dropped them.
Instagram has three kinds of account — business, creator and personal — and the first two are
both professional: both can publish a Contact button with an email or a phone number. This actor
had been reading a single business/not-business signal, so every creator fell into the personal
bucket. On 60 profiles taken from real follower lists, 48% were creators against 13%
business and 38% personal — so Business only was keeping about an eighth of a follower list
when nearly two thirds of it was professional.
Added
Account Type column, on every row: business, creator or personal, read from
Instagram's own account type. It is the last column, so every column you already read keeps its
position.
Two new choices in Filter by Account Type: Creator only, and Professional (business or
creator) for when you want everyone with a Contact button and do not care which kind. Looking
for influencers in a follower list? Choose Creator — the old advice to choose Personal
was wrong.
[3.1.75] - 2026-09-04
Documentation only. The Related actors table now lists Instagram Email Scraper, for the
contact details a list of usernames publishes — email, phone, website and business category,
one row per account. No change to this actor's behaviour, input, output or prices.
All notable changes to Instagram Followers Scraper (formerly "Instagram Followers & Following Extractor") are documented here.
The format follows Keep a Changelog .
[3.1.74] - 2026-09-04
Documentation only. The Related actors table now lists Instagram Comments Scraper, for
reading what a post's comments say — every comment and reply as a row, with @mentions and
#hashtags in their own columns. No change to this actor's behaviour, input, output or prices.
[3.1.73] - 2026-09-03
Maintenance build — no user-facing changes. Input schema, output dataset
columns, KVS records, console output, error messages, defaults, and pricing
are all unchanged from 3.1.72. Saved tasks continue to work identically.
[3.1.72] - 2026-09-01
Changed
Related actors section updated to include Instagram Likes Scraper (post likers and
commenters) and Instagram Influencer Search (keyword and hashtag search). The second one
had been missing since it shipped on 2026-08-11 — a customer landing here saw a family that
was two members short of the real one.
[3.1.71] - 2026-08-31
Fixed
A mistake in the input no longer marks the run as failed. If a target isn't a username, the
account list is empty, or both list toggles are off, the run now finishes normally and the status
line says exactly what to change. Nothing is fetched and nothing is charged, as before.
The status line now names the problem for every kind of input mistake, not just a missing target.
If a billing call fails mid-run, the run now shuts down in an orderly way instead of stopping
dead. Everything already collected is saved to the dataset and the run summary, and profiles the
platform did not actually bill for are no longer counted as charged.
A failure during start-up — before the first profile is read — no longer ends the run without
explanation. The reason is now written to the log and to the run's status.
The live status page can no longer take the run down with it if its port is unavailable.
Reading a very long followers or following list is now capped at 50,000 accounts per run, so one
read cannot exhaust the run's memory. When a list is longer than that, the log says so instead of
leaving you to assume you got all of it.
[3.1.70] - 2026-08-18
Fixed
The expected-yield figure in that warning is now specific to the contact type you picked.
All four choices used to be quoted the same ~10%. They do not behave the same: asking for
BOTH an email and a phone — the strictest of the four — actually keeps about twice as many
profiles as asking for an email alone, and the warning now says so instead of understating it.
[3.1.69] - 2026-08-17
Maintenance build — no user-facing changes. Input schema, output dataset
columns, KVS records, console output, error messages, defaults, and pricing
are all unchanged from 3.1.68. Saved tasks continue to work identically.
[3.1.68] - 2026-08-17
Maintenance build — no user-facing changes. Input schema, output dataset
columns, KVS records, console output, error messages, defaults, and pricing
are all unchanged from 3.1.67. Saved tasks continue to work identically.
[3.1.67] - 2026-08-12
Fixed
A run that gets moved to another server no longer re-analyses — and re-charges — the
accounts it was in the middle of. The actor kept a record of every account it had already
analysed, so it could pick up exactly where it left off, but that record was switched off:
it was being written into the same place as your results, and it would have shown up in
them. It is now kept privately, out of your results, and switched back on. A moved run
resumes from the last account instead of the last batch, and you are not billed twice for
the ones in between.
This actor no longer shares storage with Instagram Profile Scraper. Both used the same
two internal storage names, so if you ran them at the same time each one would clear the
other's saved progress. They now have separate names.
Starting a fresh run no longer deletes saved profiles another of your runs is still
using, and runs started together no longer clear each other's progress records at all —
each run keeps its own.
[3.1.66] - 2026-08-12
Fixed
Runs no longer fail when you start several at the same time. If you launched two or more
runs together — of this actor or of Instagram Profile Scraper, which keeps its progress list
under the same name — one of them could stop with "Could not read this run's progress record
in full", and there was nothing wrong with it. Each run keeps a list of the accounts it has
already looked at so it can pick up where it left off, and a run starting up would clear that
list at the very moment another run was reading it. Three things changed:
a run that cannot read the list now waits a moment and tries again, twice, instead of
giving up the first time;
it re-opens the list after the retry, so anything it saves afterwards is kept rather than
written into thin air;
a run that has not analysed anything yet no longer stops at all. That check exists to
protect a resumed run from being charged twice for the same account; a run that has just
started has nothing to be charged twice for, so it carries on with an empty list and a note
in the log.
Only runs started alongside other runs were ever affected. A single run on its own was not.
[3.1.65] - 2026-08-10
Fixed
A failed run no longer prints raw technical failure text. That text went into the run log and
into the run's storage records, and on a connection problem it carried a server address. None of it
was ever useful to you. Failures now read as a short, plain message; the reasons you can act on are
unchanged.
[3.1.64] - 2026-08-10
Changed
The free-plan limit ids listed in the run's FREE_LIMITS_APPLIED storage record now use one
shared vocabulary across all our actors, so the same limit reads the same wherever you meet it.
The human-readable message on each entry is unchanged.
[3.1.63] - 2026-08-02
Fixed
A narrow follower range is now recognised as the strong filter it is. Setting both a minimum and
a maximum close together is the single fastest way to spend a run and keep almost none of it, and
the up-front warning did not treat it as narrow at all. It now does, and it fires before the run
starts collecting rather than after the money is spent. A wide range is unaffected — nothing that
ran quietly before starts warning now.
[3.1.62] - 2026-07-30
Added
Related actors now lists Instagram Reel Script Extractor — the family member for reading what a creator's reels actually say and show (spoken transcript, text burned into the frame, opening hook) rather than who follows them.
[3.1.61] - 2026-07-29
Fixed
Results are no longer lost when the platform moves a run to another server. Results used to be
held in memory and written out in groups, so a run that was moved, aborted or interrupted before a
group was complete lost everything it had collected since the last write — and because those
accounts were already marked as done, they were skipped instead of retried when the run continued.
Results are now written continuously and again immediately before a run is interrupted. If an
earlier interruption did lose results, a continued run rebuilds them from the profiles it already
holds, at no extra cost and without fetching anything again.
The run summary now describes the whole run, not just the part after an interruption. Profiles
saved, filtered, private and skipped counts, the skipped-accounts list and the analysis time all
used to restart from zero when a run was moved to another server, so a finished run under-reported
everything that happened before the move.
Each row of "Target Accounts" is treated as one account. Entries containing spaces were split
on the space, so "Alex Hormozi" was read as two separate accounts — and because short words like
those often exist as real usernames, a run could quietly read the followers of accounts that had
nothing to do with the ones requested. A row is now kept whole, and a leading @ or a full profile
link is accepted and cleaned up automatically.
Entries that are not Instagram usernames are caught before anything is fetched or charged.
A person's real name, an email address or a link to a post now stops the run with the exact rows
at fault and instructions for finding the right username, instead of quietly reading someone
else's audience.
Usernames that do not exist now fail immediately instead of stalling the run. A missing account
was retried four times with waits of up to 30 seconds even though the answer could never change,
which held up other profiles waiting to be analyzed.
A run continuing after an interruption can no longer re-analyze accounts it had already
finished. If the record of completed accounts was slow to load, it was treated as empty and the
run started over — repeating work and overstating the number of profiles scanned in the run
summary. The record is now read in full, and a run stops with an explanation rather than guessing.
[3.1.60] - 2026-07-29
Changed
The Store listing now says what this actor returns — emails, bio links, engagement rate,
business category and language on every profile in a follower or following list — and the price
line shows the per-profile price instead of a generic label.
[3.1.59] - 2026-07-28
Added
A "Live Status" link in the run's Output tab. The run has always kept a status page up to date while it works, but nothing linked to it — you had to know the record was there. The link opens the page during the run and still opens it after the run has finished.
The run's Storage tab now has a named tab for the accounts-processed count, so the record is labelled instead of appearing as a bare key.
Fixed
The Storage tab no longer advertises an "Internal Cache" tab that never had anything in it — that cache is kept elsewhere and was never a stored record.
[3.1.58] - 2026-07-28
Changed
The Related Actors table now describes Instagram Profile Scraper accurately: it gained a sixth discovery mode that returns the accounts which liked or commented on a given post, so the row no longer says five.
[3.1.57] - 2026-07-28
Maintenance build — no user-facing changes.
[3.1.56] - 2026-07-28
Maintenance build — no user-facing changes. Same input shape, output columns, dataset shape, and pricing.
[3.1.54] - 2026-07-28
Added
Your first run no longer pays for filter mistakes. On a first run with this Actor, profiles rejected by your filters are not charged until the run finds its first match — up to 100 of them. Once one profile passes, your filters are working and the run bills normally for the rest. Nothing changes on later runs, and no run is ever billed more than before.
RUN_SUMMARY carries a new filterRejectsWaived count so you can see exactly how many profiles the guarantee covered. The run log prints the same number.
Changed
The "no profiles matched your filters" message now tells you what to change. It names the filter using the exact label from the Input form instead of an internal code, and prints the values it actually saw — for example 5 rejected by "Min Followers" — the profiles we found had 14,320 – 291,699 followers, your minimum is 999,999. Rejections caused by accounts with no readable posts and by missing public contact details are now explained rather than reported as raw text.
The charge for a profile is now settled after the filter verdict instead of immediately after retrieval. Every profile that used to be billed is still billed, apart from the first-run case above.
Input-form wording for Min Followers, Max Followers, Min Engagement Rate (%), Posted Reel Within (Days) and Contact Info now states what each filter actually rejects. The follower-band example that suggested 5 000–100 000 has been removed: measured across first runs, that band returned nothing.
Fixed
The Input section of the README claimed filters drop profiles "before they're billed". They do not — a profile has to be retrieved before anything can decide whether it matches. The README now says so plainly and links to a new What filters do to your bill section. The pricing table, which was already correct, is unchanged.
[3.1.53] - 2026-07-27
Removed
Removed the Also monitor follower changes input option and the follower-monitoring next step it drove. Measured across the three sibling Actors that carried it, no customer ever used it: 0 clicks from 20 eligible users on the completed screen and 0 adopters of the machine-readable contract among 61 paying users who saw it. It started nothing on its own and charged nothing, so nothing that ran before this release is billed differently.
RUN_SUMMARY no longer carries the relatedWorkflow and relatedWorkflowExecution blocks, and dataset rows no longer carry the Follower Monitoring Offer column. Every other RUN_SUMMARY field, every dataset column, and every storage record are unchanged.
A saved task that still sends startFollowerMonitoring keeps running normally. The field is accepted and ignored, and it is not reported back as an unrecognized input.
Changed
The review invitation returns to the completed screen of successful paid runs. The removed offer had been taking its place there.
[3.1.52] - 2026-07-29
Changed
The existing false-default startFollowerMonitoring consent is visible as Also monitor follower changes in the Web Input form. A successful paid WEB run may now start the same separately billed, one-child, up-to-10-profile tracker baseline used by API/CLI/MCP; free runs and the default-off path still start nothing and incur no tracker charge.
The first dataset profile returned to a paid API, CLI, or MCP caller carries one compact programmatic_dataset_tracker_call_v1 contract. It starts and charges nothing, requires affirmative user confirmation, then provides both a direct MCP call-actor payload and an equivalent authenticated Actor API POST for up to 10 lowest-follower saved profiles under a combined $5 cap. It does not rerun the source Actor; WEB/free/demo dataset rows are unchanged.
The $5 combined cap, cheapest-profile ordering, pre-read budget skips, durable receipt, separate attribution, PII-free telemetry, and exact same-token repeat contract are unchanged.
[3.1.51] - 2026-07-23
Added
Paid API, CLI, and MCP callers can set the hidden startFollowerMonitoring=true input to authorize one separately billed Instagram Follower Tracker baseline for up to 10 successfully saved profiles, ordered from the lowest known follower count. The flag defaults to false, uses the caller's token, caps the combined child run at $5, skips profiles that do not fit the remaining tracker budget before list reads, and records the outcome plus an exact same-token repeatObservation contract in RUN_SUMMARY.relatedWorkflowExecution.
The private analytics row now records only aggregate auto-start request, eligibility, started, and normalized outcome fields. Child run IDs, URLs, usernames, and tokens remain confined to caller-owned storage, while opt-in and start-failure rates become measurable.
A durable pre-start receipt prevents a resurrection or ambiguous Actor-start response from launching the same child twice. Auto-start adoption uses its own api_sibling_autostart attribution instead of contaminating the manual api_sibling_handoff funnel.
Fixed
Run.output.runSummary now exposes the existing caller-owned RUN_SUMMARY record through Apify's standard output link, matching the two sibling Actors and repairing the missing link in 3.1.50. The record contents, storage key, billing, and dataset rows are unchanged.
Unchanged
Calls without the exact opt-in, plus free, WEB, scheduled, demo, failed, and zero-value runs, never start a child. Source extraction, source billing, dataset rows, and the existing manual relatedWorkflow POST fallback are unchanged.
[3.1.50] - 2026-07-18
Changed
The paid successful WEB completed action now uses the same one-account copy, $0.30 starting-observation disclosure, and paid_sibling_single_account_cross_sell_v2 click contract as the other Instagram source Actors. The existing single-account task destination, eligibility, extraction, source billing, dataset rows, and programmatic direct_actor_api_v2 handoff are unchanged.
[3.1.49] - 2026-07-17
Changed
RUN_SUMMARY.relatedWorkflow is now the single-account direct_actor_api_v2 contract. It selects the saved profile with the lowest known follower count, so a programmatic caller starts with the least expensive available observation instead of receiving up to five separately billed accounts. The direct Actor endpoint, $5 run cap, attribution, eligibility, billing, and dataset rows are unchanged.
[3.1.48] - 2026-07-17
Changed
The terminal Follower Tracker pointer now tells API/CLI/MCP callers to read RUN_SUMMARY from the run's default key-value store before posting relatedWorkflow.input. This matches the actual Apify MCP response surface while keeping the contract ID/version, endpoint, payload, $5 cap, attribution, billing, and dataset rows unchanged.
[3.1.47] - 2026-07-17
Fixed
Paid MCP value runs now normalize to mcp and receive the same machine-executable Follower Tracker handoff as paid API/CLI runs.
The terminal handoff status pointer now exits from the final post-RUN_SUMMARY branch where relatedWorkflow exists. The earlier patch had modified a pre-summary free-cap exit instead, which could neither surface a paid handoff nor safely reference that variable. Contract ID, endpoint, payload, $5 cap, attribution, billing, and dataset rows are unchanged.
[3.1.46] - 2026-07-17
Changed
The machine-visible Follower Tracker title and note now describe one or more saved accounts instead of implying that multiple accounts are required. Contract ID/version, endpoint, payload, $5 cap, attribution, and billing are unchanged.
[3.1.45] - 2026-07-17
Fixed
The REST API instructions now match the live single-profile direct_actor_api_v1 eligibility rule instead of retaining the former five-profile threshold.
[3.1.44] - 2026-07-17
Changed
The direct Follower Tracker API contract now appears after any successful paid API/CLI value run with at least one saved profile, instead of requiring five. Its URL, $5 safety cap, payload, attribution, billing, and dataset behavior are unchanged; the 5+ account agency segment remains separately measurable.
[3.1.43] - 2026-07-17
Changed
Eligible paid API/CLI runs now repeat the direct Follower Tracker pointer in their terminal run statusMessage, which is already returned to polling integrations. The executable input remains in RUN_SUMMARY.relatedWorkflow; dataset rows, eligibility, billing, and all other runs are unchanged.
[3.1.42] - 2026-07-17
Added
Eligible paid API/CLI runs now receive a machine-executable direct_actor_api_v1 Follower Tracker contract in RUN_SUMMARY.relatedWorkflow: a Bearer-authenticated Actor POST URL capped at $5 plus input populated with up to five successfully saved usernames. The same request can be repeated for later observations without copying a Console task; the existing template link remains as a human fallback.
[3.1.41] - 2026-07-17
Fixed
The existing paid web completed-screen action now opens the same attributed single-export Follower Tracker task as the top README banner (monitor-followers-after-an-instagram-export) instead of the older generic unfollower template. The CTA, eligibility, click event, source behavior, billing, and IFT runtime are unchanged; this removes a split destination and preserves task attribution after the click.
[3.1.40] - 2026-07-17
Fixed
Remote Apify CLI runs now normalize to the existing cli origin instead of unknown, so eligible paid CLI exports receive the same RUN_SUMMARY.relatedWorkflow as API runs. The 3.1.39 owner check exposed this before a qualifying CLI proof; web/API/scheduled classification and run behavior are otherwise unchanged.
[3.1.39] - 2026-07-17
Added
Successful paid API/CLI runs that save at least five profiles now expose one static, PII-free RUN_SUMMARY.relatedWorkflow for the ready-made multi-account Instagram Follower Tracker task. The public ID is explicitly marked as a template: clients open taskUrl once, then reuse the new task ID Apify creates in their account.
The API documentation now shows how to retrieve RUN_SUMMARY through defaultKeyValueStoreId and treats field omission as the eligibility contract. Free, web, scheduled, demo, failed, and smaller runs are unchanged; billing, input, dataset rows, and completed-screen behavior are unchanged.
[3.1.38] - 2026-07-16
Changed
The top README handoff now opens a ready-made Follower Tracker task directly instead of the generic Store page. The dedicated task name keeps this acquisition path measurable without query-string tracking or personal data.
[3.1.37] - 2026-07-16
Added
Paid web users who finish a non-empty export now get one focused next step on the completed screen: open the ready-made Instagram Follower Tracker to monitor new followers and unfollowers over time. The link is click-measured without personal data and replaces the review prompt on that success path. Free, API, scheduled, failed, and zero-result runs are unchanged.
[3.1.36] - 2026-07-06
Fixed
Timestamp filters work again (last post / last Reel / posts-per-period). Around 2026-06-25 the post date started arriving under a different name, which made every profile look like it had "no media found to apply last post filter" — any run using lastPostDays, lastReelDays, minPostsInPeriod, or posts-per-month metrics returned 0 results while still charging for the scan. Both forms are now accepted for posts and Reels, restoring documented behavior.
Reel view counts now match their posts reliably, even when post and Reel IDs come back in different formats.
[3.1.35] - 2026-07-03
Fixed
Profiles are now billed only after they are successfully retrieved. Previously the per-profile charge fired before the fetch, so a discovered profile that turned out private, deleted, or temporarily unreadable could be billed without delivering anything. Now unreadable retrievals are never charged — matching what the README and FAQ always promised. RUN_SUMMARY gains an additive profilesCharged field reporting the exact number of billed profiles.
On-screen cost figures now match the real event price. An internal constant still used the pre-April per-profile rate, so the live status page's Cost tile and RUN_SUMMARY.cost.spent under-reported the run's actual spend by 40%. What Apify bills is unchanged — only the displayed numbers were wrong, and now they're right.
Runs that fail on empty input now explain themselves. An empty "Target Accounts" field (or a legacy required field) writes a plain-language USER_MESSAGE (missing_input_v1) naming the exact field to fill plus a verified starter value, and the run's status message carries the specific error instead of the generic "critical error" line.
The free-plan cap notice is recorded honestly.cap_max_profiles_free (in FREE_LIMITS_APPLIED) now appears only when the 100-profile ceiling actually constrained the run — previously it was recorded on virtually every free run, whether the cap mattered or not.
README free-plan numbers now match the actor's real behavior: the free plan allows up to 100 profiles per run (the old text said 50 in some places and 5 in another) and multiple target accounts (the old text claimed 1). Nothing about the actual limits changed — the docs were behind.
Added
Zero-result completed screen now shows a diagnosis. When a run ends with 0 saved profiles, the live status page explains what happened (cause + top fix + a verified starter input) instead of a bare "Complete" badge with an upsell. The upgrade link is not shown on an empty delivery.
Guard for "no list type selected". With both "Extract Followers" and "Extract Following" switched off the run used to finish silently with 0 rows; it now stops upfront with a clear message naming the toggles.
New list_harvest_empty_v1 message when the target account is readable but the fetched list has nothing to analyze — empty list, or every entry private. Explains that private-only fetches are never billed and suggests the fix.
README: 4 new FAQ entries (no-login/no-cookies, multi-account bulk runs, scheduling, "how do I get more results"), TikTok sibling in the related-actors table, and expectation notes on private targets.
[3.1.34] - 2026-06-22
Added
New "Example tasks" section in the README linking ready-to-run example tasks — one-click, pre-configured use cases (export followers, export following, export followers with emails, find mutual followers) you can run with no setup.
[3.1.33] - 2026-06-12
Added
Partial list reads are no longer silent. When a Verified or Business target's followers/following read is cut off deep in the list by a persistent failure (after the full per-page retry ladder), the run now says so plainly: a USER_MESSAGE reports "delivered ~N of the ~M the profile declares" and explains that Instagram limits how much of such accounts' lists is visible (the Instagram app shows the same note on those profiles), and RUN_SUMMARY gains an additive partialListReads field with the exact per-list numbers. A matching FAQ entry was added to the README. Previously the run delivered the partial list with no indication anything was missing. Billing, stop reasons, input fields, and output columns are unchanged.
[3.1.32] - 2026-06-10
Fixed
The narrow-filters heads-up introduced in 3.1.31 now names this actor's real cost-control field. The warning suggested validating with a small maxCount, but this actor's field is maxResults — following the advice as written had no capping effect. The suggested filter examples now also match this actor's input options.
The heads-up now also accounts for the engagement, posting-recency and follower-range filters when estimating how much of a fetched list will be kept. Runs using only those filters previously produced no prediction at all.
[3.1.31] - 2026-06-10
Added
Heads-up before launching a run with very narrow filters. Some filter combinations (for example Contact Info combined with Profile Language, or Keywords combined with Location Keywords) save only a small fraction of fetched profiles — billing is per fetched profile, not per saved profile, so a big run with such filters can be much pricier per saved result than expected. The actor now shows a pre-run warning estimating the expected save-rate, suggests validating yield with a small maxCount first, and writes the prediction to a new FILTER_BURN_PREDICTION record in the run's Storage tab. No change to billing, run behaviour, or input schema.
[3.1.30] - 2026-06-05
Fixed
More patient when Instagram briefly returns a server error on the first account lookup. The account-resolution step now uses the same long retry window the followers / following list reads already use — short hiccups no longer abort the run with zero results. No change to behavior on successful runs; no change to billing.
[3.1.29] - 2026-05-29
Added
A short callout near the top of the README announcing the new Instagram Follower Tracker — a sibling Actor (same author) that reports who started following and who unfollowed any public account over time. Links to its Store page for anyone who wants change-over-time monitoring rather than a one-time scrape.
[3.1.28] - 2026-05-28
Fixed
Runs started via API, MCP, or a schedule now finish as soon as the results are ready, instead of holding a 20-second "completed" screen at the end. That hold only ever helped the in-browser live view; for synchronous API and agent/MCP integrations it was dead time that could push a long run past the caller's own timeout — so the caller could receive nothing even though the run finished and was billed. Runs you start from the web console keep the completed screen unchanged.
[3.1.27] - 2026-05-26
Fixed
Runs that end with every input account skipped now always say why. The previously silent case — some accounts 404'd, some are private, and some hit a temporary read error in the same run — now ends with a clear "Nothing was scraped this run" note that lists each category. A separate case — every target reachable but every read hit a temporary rate-limit — now says "Couldn't finish reading, please re-run" instead of finishing blank.
Paid-plan welcome / check-in messages no longer overshadow real run results. The onboarding banner only surfaces when there's nothing more specific to report.
[3.1.26] - 2026-05-25
Fixed
Large follower / following lists now finish reliably even if a single page briefly hiccups partway through. Before, one temporary blip while reading a long list could stop the read early and return a truncated list; the read now waits and retries that page before moving on, so big accounts come back complete.
[3.1.25] - 2026-05-22
Changed
Added the Instagram Profile MCP Server (connect Claude / Cursor / ChatGPT to live Instagram data via MCP tools) to the Related Actors section. No change to input, output, behaviour, or pricing.
[3.1.24] - 2026-05-22
Changed
Added the new Instagram Follower Tracker (track who follows / unfollows a public account over time) to the Related Actors section. No change to input, output, behaviour, or pricing.
[3.1.23] - 2026-05-14
Changed
Expanded the Resume / checkpoint section with a concrete recovery example and explicit billing-on-resume behaviour (already-analyzed profiles not re-billed). No change to input, output, behaviour, or pricing.
[3.1.22] - 2026-05-13
Changed
Expanded the legal section with a clearer answer to "Is it legal to scrape Instagram?" — what data is and isn't scraped, operator compliance responsibilities (ToS, GDPR, CCPA, CAN-SPAM), and a note that Instagram schemas/categories/pricing can change without notice. No change to input, output, behaviour, or pricing.
[3.1.21] - 2026-05-13
Changed
Tightened README opener and Store description to match Apify Store best practices: removed pricing repetition from the value prop (Store card already shows pricing). No change to input, output, behaviour, or pricing.
[3.1.20] - 2026-05-12
Fixed
Dataset was not found warning storm on non-LIMITED clearSavedData: true runs — when run outside LIMITED_PERMISSIONS, every fresh-data run was silently logging hundreds of [finalize] checkpointDataset.pushData failed: Dataset was not found and matching detailedCacheDataset warnings during the account-processing loop. Cause: the drop-then-reopen sequence wrapped the reopen in a 3-second timeout and silently kept the stale dataset reference when the timeout fired, so every subsequent pushData targeted a just-dropped backend store. Replaced the racey block with a retry-until-writable helper (6 attempts, 1.5–10 s backoff) that aborts the run loudly if it can't recreate the checkpoint and detailed-cache datasets — propagated 1:1 from parent instagram-profile-scraper 0.1.50. Same input, output, and pricing.
[3.1.19] - 2026-05-08
Changed
Maintenance build — no user-facing changes.
[3.1.18] - 2026-05-07
Changed
README — refreshed structure for clarity (restored prior section layout). Same input, output, dataset shape, and pricing.
[3.1.17] - 2026-05-07
Changed
README — aligned to Apify quality template. Hero rewritten with value-first prose and a "beyond what Instagram's official Graph API offers" comparison; numbered 3-step Quick start; new 💡 Tips & Best Practices section (4 sub-sections × 3 bullets); new 🛟 Support & feedback section pointing to Apify Store reviews / bookmark / Issues tab; promoted disclaimer to dedicated ⚖️ Is it legal to scrape Instagram? H2 with link to Apify's web-scraping legality blog; FAQ expanded to 12 Q&As (including legality, ban risk, data freshness); MCP wrapper added to Related actors. No functional changes — same input, output, dataset shape, and pricing.
[3.1.16] - 2026-05-06
Fixed
Test runs that used the default demo seed (nike) now also write a USER_MESSAGE storage record (in addition to the existing console banner). API-origin runs that never open the run console will now see — wherever they read run output — that the run used the example seed, the output was capped at 10 profiles for cheap testing, and that the canonical input field for their own seeds is usernames. Previously the only signal was the console banner, so customers who started the actor programmatically with the example seed could end up with 10 unrelated test profiles and assume that's what the actor returned for their input.
Unknown input field names now surface a warning in the run log and a USER_MESSAGE storage record instead of being silently dropped. Common typos and field names imported from sibling actors — e.g. startUsernames, targetUsernames, profileUrls, seedAccounts, maxItems, maxResults, maxProfiles — are detected and mapped back to this actor's canonical names (usernames for seeds, maxResults for the cap). Previously a run configured with the wrong field name would still execute but ignore the customer's intended values without any indication.
[3.1.15] - 2026-05-06
Changed
The "Estimated run time" log line is now closer to typical real-world durations. The previous estimate baked in extra buffer for slow-day retry overhead that's no longer needed after the 3.1.14 retry-pacing speedup. Real runs on a normal day now finish around the printed estimate, not at half of it.
[3.1.14] - 2026-05-06
Changed
Faster recovery from brief errors. The wait between retry attempts after a server error was reduced from 5s/10s/15s to 2s/4s/6s, so short wobbles no longer add minutes to a run. Retry attempts realigned with the rest of the Instagram actor family (now 3, was 5) — all observed retries succeed well within the first two attempts.
Higher concurrency ceiling (8 → 16 parallel requests). Until now the actor itself capped every run at 8 concurrent requests; the higher ceiling lets runs finish faster whenever more parallel requests are allowed.
The retry log line now reads "Pacing requests — next attempt in Ns..." matching the wording used in the parent actor.
The "Estimated run time" buffer was tightened from 1.5× to 1.25× to reflect the lower pacing overhead.
[3.1.13] - 2026-05-06
Changed
The "Estimated run time" log line now factors in a 1.5× buffer for retries, so the printed ETA matches real-world durations more closely on long runs.
[3.1.12] - 2026-05-06
Fixed
No charge when a followers/following fetch returns no list. If the request for a target's followers or following list errors out and produces zero accounts (a deleted, private or misspelled profile, a temporary timeout, etc.), the per-fetch paid event is no longer charged. Previously the run could charge for the attempt even when no data came back. Successful fetches that return any accounts are charged as before.
Changed
The "All target accounts unreachable" diagnostic now spells out all common causes for a 404 — the account may be private, deleted, banned, or the username is misspelled — instead of only "deleted or username changed", so users have a clearer first-pass checklist when a target fails.
[3.1.11] - 2026-05-06
Fixed
Targets whose followers/following list comes back as not found (deleted, banned, or mistyped username) are now reported as unreachable instead of completing silently with 0 saved profiles. Previously the run could finish with 0 output even though the list fetch had failed — the Stop Reason: All target accounts unreachable diagnostic now fires correctly for this case.
[3.1.10] - 2026-05-05
Fixed
"No profiles matched filters" is no longer reported on small runs that fetched zero candidate accounts — it now fires only when at least one candidate was actually evaluated against your filters. Previously, a run with maxFollowers=1 could trip this diagnostic incorrectly when the fetch returned no candidates at all (a different root cause that should surface as "Completed successfully" with 0 saved, not as filter rejection).
[3.1.9] - 2026-05-05
Changed
Improved diagnostics when every fetched follower / following account is rejected by the configured filters. Runs now show Stop Reason: No profiles matched filters (instead of completing silently with 0 saved profiles) and write a USER_MESSAGE storage record listing the top 3 filter rejections so it's easier to see which filter to relax.
[3.1.8] - 2026-05-05
Changed
Improved diagnostics when every target account in a run is deleted, renamed, or private. Runs now show Stop Reason: All target accounts unreachable (instead of "Completed successfully") and write a USER_MESSAGE storage record explaining what happened, so paid runs against accounts that no longer exist surface a clear message rather than completing silently with 0 profiles.
Unreachable target accounts (404 / private) are now recorded in the SKIPPED_ACCOUNTS storage record with category not_found / private / error. Previously these failures were logged to console but absent from the storage record.
Removed an unnecessary Actor.exit() on the "no public accounts to process" early-return path so the finalize block (analytics, USER_MESSAGE, SKIPPED_ACCOUNTS) always runs to completion, matching the parent actor's pattern.
[3.1.6] - 2026-05-04
Changed
README expanded with a full output sample, $0.01-per-profile pricing math, three filter recipes (nano-influencer outreach / English-speaking creators / B2B partnership shortlist), an FAQ section, and a comparison table vs the other Instagram scrapers in this family.
Every output column now has a per-field description, type, and example available in the Apify Console's dataset view and to clients that read the actor schema programmatically — covers all 7 always-emitted columns + the conditional Email / Phone / Category / Address / Reels / Quality / Post N / contacts-from-posts columns.
Input field help text rewritten throughout — each field now leads with what it does and any prerequisites (e.g. "Free plan ceiling: 50 profiles", "Required field"), so it's clearer what to set before running.
SEO title / description tightened on the Apify Store page (no functional change).
[3.1.5] - 2026-05-03
Fixed
"Last Post Within (Days)" now reflects the actual most-recent post date. Profiles with pinned posts (Instagram pins up to 3 to the top of the grid regardless of age) were reporting the pinned post's age instead of the latest activity, sometimes by hundreds of days. Affects both the column value and the lastPostDays filter.
"Median Views" and "Views/Followers Ratio" populate correctly for accounts that post Reels. Previously, these came back as 0 / 0.00% on most profiles because the calculation was reading from the feed-posts list (photos / carousels — no view counts) instead of the Reels list. Fixes the false-zero on the column and the corresponding minViewToFollowerRatio filter.
Accounts with no Reels at all now show "Median Views: N/A" instead of "0" — the prior 0 was misleading and made these profiles look like dead Reels accounts when really there were no Reels to measure.
Added
New SKIPPED_ACCOUNTS Storage record listing every username skipped during the run, with reason and category (filter, not_found, private, error). Open the Storage tab → SKIPPED_ACCOUNTS to see exactly which usernames hit which filter, and which ones errored (re-run those — most errors are transient). The Log also prints up to 3 examples per category at the end of the run.
[3.1.4] - 2026-05-01
Changed
Documentation: added a "Other Instagram Tools" section to the README, with one-line descriptions of the sibling Instagram actors.
[3.1.3] - 2026-05-01
Maintenance build — no user-facing changes.
[3.1.2] - 2026-04-30
Maintenance build — no user-facing changes.
[3.1.1] - 2026-05-01
Maintenance build — no user-facing changes.
[3.1.0] - 2026-04-30
Added
Demo-input runs (target usernames left at the nike example) are now capped at 10 profiles on any plan, making one-click test runs predictable (~$0.10 max). Custom inputs are unaffected — default Max profiles (1000) is restored as soon as you change the seed username.
TEST RUN banner at start of demo runs explaining how to scrape your own data.
RUN_SUMMARY Key-Value Store record at end of every run — fetch via Actor.getValue('RUN_SUMMARY') for run-level stats (status, profiles found/analyzed, cost, free-tier limits applied).
FREE_LIMITS_APPLIED KVS record when free-plan caps were hit on this run, with stable id codes for programmatic consumption. Empty/omitted on paid runs.
USER_MESSAGE KVS record on a paid user's 1st and 3rd paid run — short onboarding/check-in tips, also embedded in RUN_SUMMARY.
Live status page + JSON status API exposed via the run container (/, /api/status, /api/health). The Apify Console "Live View" tab now shows real-time progress (saved/filtered/private/errors counters, cost, elapsed time).
Key-value store schema groups records into named UI tabs ("Run Summary", "User Message", "Free-tier Limits Applied", "Live Status Page", "Internal Checkpoint State", "Internal Cache") so internal checkpoint/cache keys no longer clutter the run's Storage tab.
Fixed
Run finalization is now bounded with 3-second per-step timeouts plus a 60-second cleanup safety net. Under reduced-permission run contexts these calls were stalling silently and runs could reach the platform timeout instead of exiting cleanly. Completed runs now reliably terminate within ~25 seconds of "Run Complete".
Transient Dataset was not found errors during result writes now retry up to three times with exponential backoff and a forced dataset re-open.
Changed
Language detection switched to cld3-asm (Google's Compact Language Detector v3, compiled to WebAssembly) for improved short-text accuracy on bios. Existing profileLanguage filter behavior is preserved for the major language tags but edge-case classifications may shift.
[3.0] - earlier 2026
Added
Initial public release of Instagram Followers & Following Extractor.
Single-mode actor for extracting followers / following lists from target Instagram profiles.
Filters: minimum/maximum followers, language, account type, verification, business category, contact info type, last post / last reel days, engagement rate, keyword + keyword location.
Free plan: 100 profiles per run.
Pay-per-event pricing: $0.006 per profile analyzed (raised to $0.01 in subsequent build).
