Social Media Public Data: What You Actually Get, and What No Vendor Can Give You

Social media public data is the information a platform renders to someone who is not logged in and has no relationship with the account. Follower counts, post captions, public like and comment counts, media URLs, bios. That is the whole category, and it is genuinely useful.

The confusion starts because "Instagram Public Data" is also a product name used by a dozen business intelligence connectors, and those products do not all run on the same thing. Some wrap Meta's official endpoints and inherit every one of Meta's limits. Some offer capabilities that Meta's official endpoints cannot produce, which tells you they are getting the data another way.

I am going to lay out the official surfaces with their real limits, show the calls, audit what fields you actually receive against what vendors advertise, and be specific about the five things no public source will ever return. Current as of July 2026.

What counts as social media public data?

Anything visible without authentication. The practical test is simple: open a private browser window, visit the profile, and whatever you can see is public data. Whatever you cannot see is not, and no vendor changes that.

That gives you three broad categories across platforms.

Notice what is not on that list. Every metric a brand actually uses to judge a campaign, meaning impressions, reach, saves, shares, profile visits and audience breakdown, sits behind the account holder's login. I will come back to that.

What are Instagram's official public data surfaces?

Three, and each one is narrower than its name suggests. If a vendor is offering something these three cannot do, that is a question worth asking them.

Surface 1: Hashtag Search

This is what Meta formally calls Instagram Public Content Access, and the documentation is unusually specific about what it is for: discovering content tied to your hashtag campaigns, understanding public sentiment around your brand, identifying entrants to contests and sweepstakes, customer support, and audience management. Those allowed usages are enumerated, not illustrative.

The gate is real. You need the instagram_basic permission and the Instagram Public Content Access feature, both granted through App Review, plus business verification. Meta also notes you may need to sign additional contracts.

Read the username row twice, because it reshapes products. You can build a hashtag feed, measure volume, and analyse caption sentiment. You cannot build creator discovery on it, because the API will not tell you whose post you are looking at. Our full walkthrough of pulling photos by hashtag covers the flow in more depth.

Surface 2: Business Discovery

This is the only official way to read another account's public profile data, and it comes with two conditions people miss. You need your own authenticated Instagram Business account and token, so "no authentication" is never true. And the target must be a Professional account, meaning Business or Creator. Personal accounts return nothing.

Surface 3: oEmbed

Returns embed HTML for a public post or Reel. Useful for displaying content on your site, useless as a data source. Worth knowing exists so you do not confuse an embed with an API.

What do the calls actually look like?

Two flows, both against graph.facebook.com. Replace the version with the current one and verify against Meta's reference before you build on these.

Hashtag Search: resolve, then read

Hashtags are nodes with IDs, so it is always two calls. Cache the ID, because resolving the same hashtag twice is a wasted request against a tight budget.

# Step 1: resolve the hashtag to a node ID
curl -s -X GET \
  "https://graph.facebook.com/v25.0/ig_hashtag_search\
?user_id=IG_USER_ID\
&q=coffeelover\
&access_token=LONG_LIVED_TOKEN"

# { "data": [ { "id": "17843826142012701" } ] }

# Step 2: read recent media. Last 24 hours only.
curl -s -X GET \
  "https://graph.facebook.com/v25.0/17843826142012701/recent_media\
?user_id=IG_USER_ID\
&fields=id,caption,media_type,media_url,permalink,\
comments_count,like_count,timestamp,children\
&limit=50\
&access_token=LONG_LIVED_TOKEN"

# Note: "username" is NOT a requestable field here.
# Adding it returns an error, not a null.

# Step 3: top_media works the same way, different edge
# GET /{hashtag-id}/top_media?user_id=...&fields=...

Business Discovery: one call, nested syntax

This one trips people up because the target username goes inside the fields parameter rather than as its own argument.

curl -s -X GET \
  "https://graph.facebook.com/v25.0/IG_USER_ID\
?fields=business_discovery.username(target_account){\
id,username,name,biography,website,profile_picture_url,\
followers_count,follows_count,media_count,\
media{id,caption,media_type,media_url,permalink,\
like_count,comments_count,timestamp}}\
&access_token=PAGE_ACCESS_TOKEN"

# Fails if target_account is a personal account.
# Media edge is cursor-paginated.

Both surfaces sit under Meta's Platform Rate Limits rather than the Business Use Case formula that governs most Instagram Platform endpoints. If you want the full rate limit picture, we broke it down in our complete Instagram API guide.

What fields do you actually get?

Fewer than the marketing implies, and the gap is mostly calendar columns. I went through the published field references from four business intelligence connectors that all sell an "Instagram Public Data" product, and the counts do not agree with each other or with themselves.

Work through one of them and the pattern is obvious. Supermetrics lists 43 dimensions. Fourteen of those are calendar columns: year, yearOfWeek, yearOfWeekIso, yearMonth, month, yearWeek, yearWeekIso, week, weekIso, dayOfMonth, dayOfWeekName, dayOfWeekNameIso, date, today. Nine more are query metadata like start date, end date, timezone and duration. Three describe the data source itself. What remains is about 21 actual Instagram fields, and two of those are caption length calculations.

None of this is dishonest. Those columns are genuinely useful when you are building a Looker Studio report and need to group by week. But "43 dimensions" and "21 Instagram fields" are very different claims, and only one of them is about Instagram.

Here is the actual set, which is consistent across all four vendors because they are all reading the same underlying surfaces:

One quiet trap in that list. Comment counts from these surfaces include replies, so they will not match the number a person sees in the Instagram app. Porter documents this in their own troubleshooting. It is expected behaviour, and it is the kind of thing that turns into a client dispute if nobody flagged it.

What can public data never tell you?

Five things, and no vendor, index or scraper reaches them, because Instagram releases them to the account holder alone. This is a structural boundary, not a difficulty curve, and it is the single most important thing to establish before you scope a product.

That table is why the two data models exist rather than one. We wrote up where the line falls in consent-based versus public social APIs.

Why does public data have no history?

Because the surfaces return a snapshot of the present, not a time series. This catches teams out more than any rate limit does, and both of the connector vendors who document it honestly say the same thing.

Dataddo states it plainly in its own docs: none of the Instagram Public Data datasets use a date range, and every run pulls all currently available data. Porter's troubleshooting page answers the complaint directly, telling users that public data provides current profile snapshots and recent media, and that for deep historical analysis you should start tracking a profile early and let the tool build history over time.

So the honest framing is that you are not querying history, you are starting a recorder. Follower counts, post counts and engagement figures are point-in-time values. If you want a competitor's growth curve for the last two years, no public data product has it, and any that claims to has been collecting it since then and is selling you their archive.

Two practical consequences. Start collecting before you need the data, because you cannot backfill. And store every snapshot with its own fetch timestamp, which is exactly why Windsor exposes a data_fetched_at column and Dataddo exposes an extraction timestamp.

How do the public data connectors differ?

Mostly by destination and pricing model, and in one important way by how they get the data. The first four in this table are business intelligence pipes, which is a different product from an API you build a feature on.

Dataddo is the clearest on the constraint. Its documentation says outright that the Instagram Public Data API is not for accessing data from personal accounts, requires OAuth, and points to Meta's official endpoints. That is what running on the official surfaces looks like.

Porter markets something different: no Instagram login required, enter any public username, start pulling in under two minutes, and an explicit FAQ on tracking competitors without their permission. No Meta surface produces that capability. Business Discovery needs your own authenticated account and only returns Professional accounts. Hashtag Search needs App Review and business verification and will not tell you who posted anything. I am not accusing anyone of anything, and there may be a licensing arrangement I cannot see from the outside. I am saying that if a tool offers a capability the documented endpoints do not, the correct response is to ask how, in writing, before you build a client deliverable on it.

That question matters more than it used to. If you resell this data, put it in a media plan, or use it in screening or due diligence, your buyer will eventually ask where it came from. "A connector" is not an answer that survives a procurement review.

What should you ask before buying a public data product?

1. Which Meta surface does this run on? Hashtag Search, Business Discovery, oEmbed, or something else. If the answer is vague, that is the answer.
2. Does it work on personal accounts? No official surface does. A yes here is worth understanding fully.
3. Is any of it estimated? Reach and audience figures usually are. Fine if disclosed, a liability if you resell it as measured.
4. What is the real field count, excluding calendar columns? Ask for the list, not the number.
5. How far back does history go? If the answer is "from when you start", plan for that. If it is "two years", ask where the archive came from.
6. How does it handle the 30 hashtag limit? If they run hashtag collection on your connected account, that budget is shared with every other tool you have connected.
7. Do comment counts include replies? They usually do, and it will not match the app.
8. What is the compliance position in writing? GDPR basis, retention, deletion. Ask before price if you sell into hiring, lending or immigration.

When do you need consented data instead?

When the answer to your product question is in the five-row gap table above. Public data is the right tool for discovery, competitor benchmarking, hashtag campaigns and social listening. It is the wrong tool the moment a brand asks what a post actually reached.

The two models are complementary rather than competing, and the strongest platforms run both. Public data at the top of the funnel to find and screen creators nobody has a relationship with. Consented data once a creator is onboarded, to replace estimates with the numbers the platform gives the account holder.

That second half is what we built Phyllo's social data API for. A creator connects their accounts through your product, approves the scopes, and you receive true impressions, audience demographics, engagement across every format including Stories, and earnings where the platform exposes them, normalised across 25+ platforms through one integration. For the public side, our social listening API covers conversation and mention tracking, and influencer vetting combines both. Field-level coverage per platform is public at getphyllo.com/coverage and the API reference needs no sales call.

Where we are the wrong tool, plainly. We need the creator to connect. If your job is analysing ten thousand competitor profiles who have never heard of you, a public data product is correct and we are not. We compared the whole market by access model in the best social media data APIs and covered the architectural split in the universal API guide.