Scrape 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.
All notable changes to Instagram Followers Scraper (formerly "Instagram Followers & Following Extractor") are documented here.
The format follows Keep a Changelog .
[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). The upstream API renamed the media timestamp field (taken_at_ts → taken_at) around 2026-06-25, 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 spellings are now accepted at the fetch boundary (feed media and clips), restoring documented behavior.
Reel view matching hardened against upstream ID-type drift (feed posts and Reels now report IDs in different types; matching is type-agnostic).
[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 upstream 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 clean upstream now finish around the printed estimate, not at half of it.
[3.1.14] - 2026-05-06
Changed
Faster recovery from transient upstream errors. The retry-pacing wait between attempts on 5xx was reduced from 5s/10s/15s to 2s/4s/6s, so brief upstream 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, runs on plans with high upstream rate were capped at 8 concurrent requests by the actor itself; the new ceiling lets larger upstream rate plans translate into faster runs immediately.
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 upstream 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 upstream request for a target's followers or following list errors out and produces zero accounts (404 from a deleted/private/misspelled profile, transient 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 that return 404 from the followers/following endpoint (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 upstream 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 upstream — 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).
