Follower and following graphs on X, Instagram, and TikTok
Public follower and following lists as JSON. A graph here means who follows whom — not the Meta Graph API.
A follower graph is who follows whom on a public account. X, Instagram, and TikTok expose that object on fetcher.sh. YouTube does not — this catalog has no YouTube follower list, so we do not pretend.
“Graph” here is not the Meta Graph API (that is the Instagram access naming collision) and not a knowledge graph. It is also not “who viewed my profile.” Public edges only. Incomplete samples, paged. Not a dump of the whole network.
Public edges, three hosts
Twitter/X: followers, followings, and tweet retweeters. Instagram: followers and followings. TikTok: followers and followings. Each call is a GET that returns public profiles in the envelope. Use it to size an audience or walk a neighborhood of accounts.
Most of those paths want a numeric id. If you only have @name, resolve the handle first. Then, for example:
GET https://instagram.fetcher.sh/api/user/{id}/followers
Walk one hop at a time. These are public follower lists, not a complete social graph dump. Creator lookup consumes these lists when the job is “size this person,” not “walk the graph.”
Retweeters on X are a different edge: they hang off a tweet id, not a user id. Do not send a user id to a retweeters path and expect a follower list.
Limits
Not Meta Graph API. Not YouTube subscribers. Not private “who viewed my profile.” Resolve the handle, then page the edges. A page is a sample. Completeness is not a promise. GDPR-grade audience files are not the product.
If you need ads targeting, you want Ads Manager. If you need YouTube subscriber counts as a list, you will not find that list here — channel stats on YouTube are a different shape on youtube.fetcher.sh, not a follower graph.
A case: overlap between two public creators
A talent team has two Instagram handles. They want a rough sense of whether the audiences overlap, not a marketing-cloud identity graph.
They resolve both handles. They page followers on each. They compare ids they actually retrieved — a sample, not a promise of completeness. They do the same on TikTok if both accounts exist there. They do not call youtube.fetcher.sh for a follower list; it is not in the catalog.
That sample is enough to say “these neighborhoods look related” or “these are different planets.” It is not a GDPR-grade audience file. Public edges, one hop, stop.
A case: retweeters as a one-hop neighborhood
A reporter has a viral tweet. They want to know which public accounts amplified it, not who liked it in private.
They fetch retweeters on the tweet id. They resolve nothing if the payload already has ids. They do not walk those accounts’ followers unless the story actually needs a second hop — and even then, one hop, public only, no people-search.
Following lists are the other direction: who this public account chose to follow. Talent teams use that as “who do they consider peers.” It is still a sample, still public, still not a private close-friends list. Walk it the same way: resolve, page, compare ids you actually have.
Paging forever because you wanted a complete audience file is how a lookup job becomes something we will not help you build. One hop. Stop.
A useful weekly version, if you even need one: resolve two ids you already trust, pull one page of followers on each, store the overlap count of this page, not a fantasy of the full graph. Direction matters. Following lists answer “who do they treat as peers.” Follower lists answer “who publicly subscribed.” Retweeters answer “who amplified this tweet.” Those are three questions. One endpoint each. If a slide says “audience graph” and you cannot name which of the three you fetched, the slide is decoration.
YouTube still has no follower list here. Channel stats on a public video page are not a subscriber dump. Do not pad a roster with a fake YouTube edge column.
What a graph is not on this catalog
Not Meta Graph API. Not YouTube subscribers. Not private “who viewed my profile.” Not a marketing-cloud identity stitch. Resolve the handle, then page the edges. Docs on each host; payment is the usual 402 or Bearer key. If you needed ads targeting, you want Ads Manager, not a follower page. Completeness is not on offer. If a stakeholder asks for “the full follower graph as a CSV,” the answer is no — not because the JSON is shy, but because paging a huge public list into a file is a different product, and usually a bad idea. One page, one hop, ids you actually retrieved. Write “sample” on the slide. If that word makes the stakeholder unhappy, they wanted a different vendor, not a larger page size. Retweeters still want a tweet id. Followers still want a user id. Mixing those is a 400, not a graph.