Instagram Followers scraper

What it collects

socialNeeds an accountProxy advised

Who follows an account, or who it follows back — handle, name, verification and Instagram’s own id for each one, a row per account and ready to join onto a profiles table. It is a scraper, which means the whole contract is: fill in the form, and one table comes back. No browser window opens, it costs none of your plan's automation slots, and the requests go out over plain HTTP carrying a real browser's TLS fingerprint.

At volume this target is sensitive to where the request leaves from, so pick a proxy on the run — it is advice at the form rather than a gate, and a run without one still starts. Whichever way it went, every row records it — see the provenance columns below.

What you give it — 3

The form the app draws, read out of the card itself. Each hint below is the one shown beside that field in the run dialog, so nothing here is a description of the product written separately from it.

The one answer it needs

usernames

Accounts · list · required

Whose list to walk — nasa, @nasa, the profile URL or the numeric id all work. Each account is walked separately and the rows are pooled into one table, labelled by whose list they came from.

Everything else is optional

direction

Which list · select

Two different endpoints, not a filter — this one does change what is requested, and the rows are labelled with the answer.

resultsLimit

Accounts per list · number

Walked fifty at a time, so this rounds up to the next fifty. A private account returns none however high this is set, and a very large list will be capped by Instagram before it is capped here.

What comes back — 13 columns

One dataset per run — a typed table your workspace owns, which you can then sort, filter, edit in the grid, export whole, or read back over the local API. These are the columns it is created with.

9 from Instagram Followers

4 that every scraper writes

The same four on every card, so a table can still answer months later how its rows got there: which service they came from, when, which profile's identity the requests carried, and whether that identity was signed in.

Four ways to run it

The Scrapers tab. Pick the card, fill in the form, press Start. Every run started here makes a new table, named after what you searched for and when. Check first if you like — it collects one page, writes nothing, and reports which columns came back filled.

Ask the assistant. It has the whole catalogue, so this card is a sentence rather than a form. It fills in the parameters above from what you said and shows you them before it starts.

Over MCP or the local API. The same card, from a coding agent — argus_run_scraper over the MCP server, or POST http://127.0.0.1:39219/v1/scrapers/run on the local API. There is a sample call beside it that writes nothing.

{
  "kind": "instagram_followers",
  "inputs": {
    "usernames": [
      "…"
    ]
  }
}

As a step inside a workflow. The Run scraper step puts this collector in the middle of an automation — collect, then filter, then mail — and the tree still opens no window doing it. It is also the one caller that can overrule the table-per-run rule: pointed at a table you name, it creates that table with the columns above if it is missing and files every run into it after, appending or updating the row in place on a column you match on. The step hands the next one the table's name, its id and the row count.

Where it stops

It will not drive a page. Anything that needs a real browser — a site with no list endpoint behind it, or anything operating an account of your own — is an automation instead, and that is a different tool rather than a worse version of this one.

Even signed in, no browser window opens to collect. One opens once, by hand, so you can log in; every request after that is the same plain HTTP every other card makes. Use a throwaway account — automated collection is against these sites' terms and the account carrying it can be disabled.