Pricing

from $0.50 / 1,000 followers

Try for free

Go to Apify Store

Instagram Followers Scraper — Followers & Following by Username

Try for free

From $0.50 per 1,000 followers. The followers and the following list of any public Instagram account, by handle or profile URL — handle, name, user ID, verified and private flags. No login, no cookies. Your result limit is exact: ask for 500 and you get 500. A row we cannot deliver is never charged.

Pricing

from $0.50 / 1,000 followers

Rating

0.0

(0)

Developer

Steadyfetch Team

Actor stats

Bookmarked

Total users

Monthly active users

a day ago

Last modified

Changelog

1.0.10 — 2026-09-14

A run that brings back no rows now tells you what to do about it — and counts the mistake it never showed. A run that delivered nothing used to name only the count and a reason code — "Delivered 0 rows of 1 asked for across 1 list. Not delivered: 1 not found" — and stop there, with no next step, because the run had ended cleanly and only a run stopped by a limit ever said anything further. Each reason now carries its own plain sentence: a handle Instagram has nothing at tells you to open it in a browser and says a re-run answers the same, a private account says this actor reads public accounts only, an account whose list Instagram publishes nothing for says so, a temporary read says to start the run again, and an answer this actor could not map says it is ours rather than yours and asks you to open an issue. And a value this actor could not read is now counted on that line at all: it was named on its own uncharged row but was missing from the run page's summary entirely, so a run whose handles were all unreadable said "Delivered 0 rows of 1 asked for across 1 list." and nothing else. It now names the count and tells you which field to paste handles into and what one looks like. Instagram's own limit on very large accounts keeps the sentence it already had rather than being explained twice, a run that did deliver rows is unchanged and says nothing extra, and nothing about what is collected or charged changed.
The sample row now sits at the top of the page, where you can see what you would be paying for. A real delivered row was seven thousand characters down the page, below the price table, the honest-row list and the section on Instagram’s own cap — so the columns and a row of real output were the last things you reached rather than the first. The column table and the sample row now come straight after the opening block, and the opening block itself carries the price ($0.50 per 1,000 rows on Gold and above, $2.00 per 1,000 on the Apify free plan, the same for a followers row and a following row, no start fee) and how often the data changes: follower lists churn daily on an active account, and the rows you already have are skipped rather than charged again, so a schedule pays only for what changed. No price, no input field, no output column and no charged event changed.

1.0.9 — 2026-09-14

A run that can read your repeat memory but not write to it now says so, instead of letting your next run pay for everything twice. The previous entry covered a token that cannot OPEN that memory. This is the other half: an API token can be allowed to read key-value stores and not to write them — or to write them and not to create one you do not have yet — and such a run opens your memory, recognises every row you already had correctly, and then remembers nothing it delivered. The run looks perfect and your NEXT run is charged for the whole delivery all over again. The run page now names it the moment the first write is refused, an uncharged row at the top of the dataset carries the cause and the fix in full, the receipt carries repeatWrite: "denied_scope", and the run log keeps Apify's own message and adds the permission to grant: key-value store Write (and Create), or Actor runs set to Full access, under Settings → API & Integrations. A write that fails for an ordinary reason is still just retried bookkeeping and says nothing. Both run-page sentences are also shorter and now read the same on every actor in the portfolio, with the whole fix on the row. No price, no input field, no delivered column and no charged event changed.
A run that set a field this actor does not have now reads as one sentence on the run page. The sentence naming the field you set and the field this actor reads carried a semicolon, which is the character the run page uses to separate one statement from the next — so anything reading that line saw two half-sentences instead of one. Same words, clearer line. Nothing about what is collected or charged changed.
A run that cannot open your account's repeat memory now says so instead of quietly charging you twice. This actor promises the same row is never charged a second time: it remembers what it delivered to your account in a key-value store there, and skips those next time, which is what makes a schedule on the same handles cost only what changed. A run started from the API with a scoped token in restricted-access mode cannot open that store unless the token is allowed to — so the check never ran, every row you already had was collected and charged again, and nothing on the run page, the rows or the receipt said a word about it. The run page now names the cause and the fix, an uncharged row at the top of the dataset says the same thing for anything reading rows rather than the page, the receipt carries repeatCheck: "unavailable_scope", and the run log keeps Apify's own message and adds the permission to grant: key-value store Read, Write and Create, or Actor runs set to Full access, under Settings → API & Integrations. Every other reason the memory can be unreadable reads exactly as it did before. No price, no input field, no delivered column and no charged event changed.

1.0.8 — 2026-09-13

An account sent under a slightly different field name is now collected instead of ignored. A run that put its accounts in username, user, users, handle, handles, account, accounts, profile, profiles, profileUrl, profileUrls, url, urls or startUrls used to collect nothing: Apify passes a field this actor does not declare straight through, so the run looked like a Start with no account set and came back with one uncharged row naming a field you had never filled in. Those names are now read as the field they plainly mean — Apify's own {"url": …} Start-URLs shape included — an account sent under both names is collected once and charged once, and one uncharged row tells you which field to use next time so it stops appearing. A field name that matches nothing still gets an uncharged row, and that row now names the field you set as well as the field this actor reads. No price, no input field, no output column and no charged event changed.

1.0.7 — 2026-09-13

Your result limit now holds even when Apify moves the run to another server part-way through. This actor already picks up exactly where it left off after such a move, and it works out how much of your limit is left from the rows it has already delivered — but it was counting only the rows that carried a fee. A row your account already has comes back delivered and uncharged, and so does every row on a run that cannot be billed at all, so those were invisible to the count: the run believed more of your limit was unspent than really was, and could hand you more rows than you asked for. It now counts every one already delivered to you, whether or not it carried a fee. Nothing about what you are charged moves — a repeat is still delivered without a result fee, and only delivered rows are charged.

1.0.6 — 2026-09-13

The page now shows you a row before you spend anything, and its first line is the listing's own name. A new What a row looks like section carries one real delivered row from a live run — the account, its flags, which list it came from and the charge record — and the heading at the top of the page is now the store title instead of a different name for the same product. No price, no input, no output column and no charged event changed.
A read that will never work is no longer reported as one that might. Two different answers used to arrive as vendor_unavailable, the row that says "this is temporary — please re-run": a list Instagram refuses to answer for outright, and an answer that arrives in a shape this actor cannot read yet. Neither changes on a re-run, so that row was selling you a second run for exactly the same answer. Each now has its own uncharged row — source_refused and unsupported_shape — saying what is actually true, what to check, and that running it again will not change it. The same goes for the account lookup itself: a reply this build cannot read is no longer reported as a passing outage. A genuine outage still ships as vendor_unavailable, still asks for a re-run, and still carries no result fee. No price, no input and no delivered column changes.
A run may now wait longer for a slow source before it gives up. How long a run can keep waiting is sized against what the rows it is still owed are worth, and this build lets that sizing draw on half of the run's own margin instead of a quarter — so a page that is answering slowly gets about twice as long to come back, and a delivery cut short on a slow page is rarer. Everything that bounds the waiting is unchanged: your run-time limit, your result limit and your cost cap still end it on the spot, no run ever waits less than it did before, and a small ask waits exactly as long as it always has. No input, no output column, no charged event and no price changes.
The last row of the run now tells you, in a field of its own, whether running again would get you more. That row carries a retryable field, and until this build it always read false — even on a run that had stopped part-way through a list, was still holding the point to continue from, and had rows it had not collected. Worse, the same row opened with the word "Completed" whenever the reading itself had ended tidily, which is not the same thing as your ask being answered. From this build retryable is worked out from what the run actually did: rows it did not collect and nothing explains, a live resumeCursor on the row, and run time still left. A run that answered your ask in full still reads Completed and retryable: false, even though it saves a cursor — a cursor on its own has never meant you were owed anything, because almost every list is deeper than the rows you asked for. The row also now publishes budgetLeftMs, the run time that was still unspent when it stopped. Nothing about what you are charged changes.
The input schema now speaks to an AI agent as well as to a person. An agent that finds this actor through Apify's MCP server never opens this page — it reads the input schema. So the schema's own description now opens with the call that works, says what one follower row costs and what 300 rows come to, lists what is never charged, says that the result limit is per account and per list, and names the run option that caps the bill. The handles field leads with the value shape and examples, then what is never charged, then where a hashtag or a single post belongs, with the console sample instruction last. No price, no charged event, no input field and no delivered column changes.

1.0.5 — 2026-09-12

The time a run waits out a quiet source is now sized to what you asked for, instead of being the same fourteen seconds for every run. Since the last build a list that hit a quiet stretch was waited out twice — a short wait, then a longer one — and then given up on, whether you had asked for three rows on a two-minute run or five hundred on an hour-long one. A big ask on a long run now keeps waiting and reading the same page again, each wait longer than the last, for as long as the rows it is still owed are worth the run time it costs. A small ask waits exactly as long as it did before, so nothing gets slower or dearer; no run ever waits less than it used to; and no run waits past your own run-time limit, your result limit or your cost cap, all of which still end the waiting on the spot. Where the source comes back, the rows behind the pause are delivered and charged exactly as they always were. Where it does not, nothing changes: the rows in hand are yours, the rest carries no result fee, and the resume point still picks up where this run left off.

1.0.4 — 2026-09-12

An answer this actor already paid for is never bought twice. When the source replies in a shape this build cannot read, waiting and asking again cannot change one byte of it — the run did it anyway, buying the same dead page up to nine times and spending up to fourteen seconds of your run clock on it. From this build only the refusals that cost nothing and clear in seconds are waited out: a rate limit, a server error, a dropped connection, exactly as before. Nothing about what you are charged moves.
A list that came back completely empty is no longer reported as Instagram's limit, or as an account with nobody on it. A first page holding nobody used to be read as a final answer either way — "Instagram limits how much of a very large account's list it will show ... no tool can go past it", or "that is a definitive answer" — even for an account that publishes a follower count of its own. Both told you to stop asking on exactly the run where asking again was what would have got you your rows. Now the account's own published count decides: where it says zero, the answer stands as the definitive one it is; where it says otherwise, or says nothing at all, the row is marked temporary, asks you to re-run, and the place to carry on from is kept. A list that really does serve rows and then stop short of the account's stated total is unchanged — that is still Instagram's cap and still says so. Either way there was no result fee.

All notable changes to this actor are documented here. Each entry matches one build on the Builds tab.

1.0.3 — 2026-09-12

A build about what an unfinished list tells you, plus an internal cost fix.

A list no longer ends because Instagram could not be reached for a moment. When the source went quiet part-way through a list, the run used to stop collecting it on the spot — about five seconds after the first sign of trouble — and report every row it still owed as not delivered. It now waits and reads the same page again: a short wait, then a longer one, spent once per list rather than on every page, and only while the run still has the clock for it and none of your own limits have been reached. Where the source comes back, the rows behind the pause are delivered exactly as they always were. Where it does not, nothing changes at all: the rows already collected are yours and charged as marked, the rest carries no result fee, the resume cursor still points at where to continue, and the row still says a re-run is the fix. An account that does not exist, a private one, an empty list and a run that has reached a limit are answers, not pauses, and are never waited on.
A link in your rows can never carry a network address, whatever form it arrives in. Every link this actor delivers already went through our own URL hygiene before reaching your dataset, and that pass had a gap: where an upstream body writes its links with HTML-escaped separators (& in place of &), the address parameter was not recognised by name and could survive into a row. It is now removed however the link is written — escaped, plain or legacy separators, upper or lower case, and inside a link that wraps another link. Nothing else in a link moves: the expiry, the signature and every routing parameter are delivered exactly as they were served, so the links keep working exactly as before. No column, no input, no price and no charge changes.
A run that has reached your maximum cost per run now stops before fetching another page of followers it will not deliver to you. Your rows, your charges and your prices are unchanged — the run stops in the same place and bills exactly the same amount; the read it no longer makes was one we were paying for.
A limit set higher than this actor's own no longer refuses the run. "Max results per account" above 50,000, or a run clock outside 30 seconds to 1 hour, used to be rejected by the platform before the run started — no run, no rows, and nothing to tell you why, which is what a caller arriving with another scraper's numbers hit. From this build the run starts, continues at the nearest limit, and leaves one uncharged row naming what you asked for and what bound it; where Instagram's own limit on very large accounts is what stops a list, that still has its own row. Your prices, your charges and every column are unchanged.
A list that stops part way through no longer says "there was no result fee" over rows you were already charged for. When a feed stops answering — or an account is renamed, removed or turned private — after part of its list has been delivered, the uncharged row now opens with how many rows were delivered and that each of those rows says what it was charged; the no-fee sentence covers only what was never collected. Nothing about your prices or your charges changes: the same rows were billed before and after, the row was describing them wrongly.
The two places this actor stops reading on its own now leave a row instead of nothing. It stops after three pages in a row that held nothing but rows you already have, and it reads at most 2,200 pages for any one list. Either bound used to end the list with no row at all for the rows it did not collect, so a run could deliver fewer rows than you asked for with nothing to say why. Now the shortfall gets one uncharged row that names the bound as this actor's own rather than Instagram's, says the list still has more in it, and points at the lever — "Include rows you already have", or the resume cursor the run already publishes so a second run continues exactly where this one stopped.
Internal only: our own record of how a run ended now names those two bounds as a deliberate stop of ours, instead of leaving the rows they did not collect unexplained in our telemetry. Nothing in your dataset, your columns, your prices or your charges changes.

1.0.2 — 2026-09-11

A listing-copy build.

The store page now carries the plain note that this actor is unofficial and not affiliated with, endorsed by, or sponsored by Instagram or Meta Platforms, Inc., the same line the rest of the Instagram actors carry.
Internal only: our own record of what a licensed data feed costs us was corrected, and a request that feed rejects is no longer retried — nothing about your rows, your charges or your prices changes.

Nothing about the actor itself changed: the same inputs, the same columns, the same events and the same prices. There is no reason to re-run anything.

1.0.1 — 2026-09-11

First public release.

The followers list and the following list of any public Instagram account, by handle or profile URL. Pick followers, following or both; every row carries the handle, full name, user id, profile URL, profile picture, the private and verified flags, the account badges, and the position it held in the list.
The result limit is exact, per account and per list. Ask for 500 and the run delivers 500, or a row of its own says why it could not. Three handles in both mode at 100 each asks for 600 rows, and all 600 are either delivered or named.
One charged event, follower, from $0.50 per 1,000 rows, platform usage included. It covers both directions at the same price, there is no start fee, and there is no second charge for "details" — every column is in the row at that one price.
Instagram's cap on very large accounts is reported, not hidden. Measured on 2026-09-11, an account with 104,378,996 followers served 49 rows and stopped; an account with 19 followers served all 19. When the cap lands you get a capped_by_instagram row naming how many rows were reached against how many the account reports having, and the rows past the cap are not charged.
Honest uncharged rows for every other way a row can go missing too: an account Instagram does not have, a private account (answered from the account lookup, before a list read is spent), a list that ran out, a read that did not go through, this actor's own monthly collection allowance, a limit or clock on the run, and an input value that could not be used — each says so in its own words and none of them is billed.
A run that stops short hands back a resume point. A follower list is longer than any one run's limit, so the last row of a run that left a list unfinished carries a resumeCursor. Pass it back in Continue a stopped run, with the same usernames, and the next run starts each list exactly where the previous one stopped: no page is read twice, no row already delivered to you is delivered or charged again, and nothing in between is skipped. A run whose lists all ran out carries no cursor, so a finished walk never invites a re-walk.
Repeat memory: rows already delivered to your account are skipped on a later run, not charged again, and their slot goes to the next new follower — so a daily or weekly schedule on the same handles costs only what changed. Turn it off with Include rows you already have, or carry it across accounts with Skip rows in this dataset.
Pressing Start with nothing filled in returns three built-in sample rows so the column shape is visible before anything is collected: nothing is read from Instagram on that run, and there is no result fee for it.
Profile picture links are delivered with the requesting network address stripped out.

Instagram Followers & Following Scraper [From 💰$0.99] No Login

memo23/instagram-following-scraper

[From 💰$0.99/1k] Scrape the followers and following of any public Instagram account — no login, no cookies, zero risk to your account. Get username, full name, verified & private flags, profile pic and profile URL for every account. Followers, following, or both, many profiles per run.

Muhamed Didovic

5.0

Instagram Followers & Following Scraper (CSV/JSON, No Login)

convertfleetdotonline/instagram-followers-scraper

Instagram followers scraper - export followers or following lists from public profiles to JSON, CSV or Excel. Username, full name, user ID, profile picture, verified and private flags. Multiple accounts per run, auto-pagination.

Hasnain Nisar

Instagram Followers Scraper

seemuapps/instagram-followers-scraper

Fetch followers or following list for any public Instagram profile

Andrew

1.3K

5.0

Instagram Followers and Following Scraper

danek/instagram-followers-following-scraper

Scrape followers and following of an Instagram account.

Jan Danecki

Instagram Followers & Following Scraper

dami_studio/instagram-followers-following-scraper

Get the followers and following list of any public Instagram account. Each row has the username, full name, profile picture and profile URL. It also says if the account is verified or private. Only public accounts work. No login, no cookie. $0.60 per 1,000 rows.

Dami's Studio

Twitter (X) Followers Scraper | $0.10/1K | Followers/Following

ecomdate/x-followers-scraper

Export any X (Twitter) account's followers or following list in bulk — no login, just $0.10 per 1,000 users. One row per user: handle, name, bio, followers, verification & more.

Ecomdate Tech

Instagram Followers/Following Scraper

toolzerhub/instagram-profile-follower-followee-scraper

Extract the followers or following list of one or more public Instagram accounts. Get each Instagram user's username, full name, profile picture, verification status, and private-account flag, with a full profile and email on request. No Instagram login or cookies required.

ToolzerHub

TikTok Followers & Following Scraper [$0.99/1k] No Login

memo23/tiktok-followers-scraper

Scrape the followers, following, or suggested accounts of any public TikTok profile — no login, no cookies, zero risk to your account. Get username, nickname, bio, verified & private flags, avatar, profile URL, and full stats (followers, likes, videos) for every account.

Muhamed Didovic

Instagram Following Scraper

khadinakbar/instagram-following-scraper

Export the full following and followers list of any Instagram profile as structured JSON — username, full name, verified/private flags, and profile URL. MCP-ready.

Khadin Akbar

Instagram Followers / Following Scraper (No cookies🍪)

dead00/instagram-followers-following-scraper-no-cookies

Scrape followers or following lists from any public Instagram profile. Input usernames, set a limit, get clean structured data. No cookies, no login, no setup

Dead

228

1.0

Instagram Followers Scraper — Followers & Following by Username

Changelog

1.0.10 — 2026-09-14

1.0.9 — 2026-09-14

1.0.8 — 2026-09-13

1.0.7 — 2026-09-13

1.0.6 — 2026-09-13

1.0.5 — 2026-09-12

1.0.4 — 2026-09-12

1.0.3 — 2026-09-12

1.0.2 — 2026-09-11

1.0.1 — 2026-09-11

You might also like

Instagram Followers & Following Scraper [From 💰$0.99] No Login

Instagram Followers & Following Scraper (CSV/JSON, No Login)

Instagram Followers Scraper

Instagram Followers and Following Scraper

Instagram Followers & Following Scraper

Twitter (X) Followers Scraper | $0.10/1K | Followers/Following

Instagram Followers/Following Scraper

TikTok Followers & Following Scraper [$0.99/1k] No Login

Instagram Following Scraper

Instagram Followers / Following Scraper (No cookies🍪)

Changelog

1.0.10 — 2026-09-14

1.0.9 — 2026-09-14

1.0.8 — 2026-09-13

1.0.7 — 2026-09-13

1.0.6 — 2026-09-13

1.0.5 — 2026-09-12

1.0.4 — 2026-09-12

1.0.3 — 2026-09-12

1.0.2 — 2026-09-11

1.0.1 — 2026-09-11