Authenticated vs Public Social Data: What Each Can and Cannot Return

Public social data is anything a platform renders to someone who is not logged in and has no relationship with the account: handle, bio, follower count, post captions, public like and comment counts. Authenticated data is what the platform renders to the account holder after they have granted your application permission: true impressions, audience demographics, Stories performance, earnings.

That is the whole distinction, and it is not a difference of degree. No amount of money, coverage or engineering moves a field from one side to the other, because the boundary is a platform policy decision rather than a technical limitation.

What follows is the full picture in both directions. What public can return and never can. What authenticated can return and, in the section most articles skip, what it cannot. How public estimates are actually calculated. What happens on revocation. Which source survives an audit. And how to run both with a precedence rule that does not corrupt your data.

What does authenticated actually mean?

It means the account holder completed an OAuth flow in your product and approved a specific set of scopes, and the platform now answers your requests on their behalf. Four things exist afterwards that did not before, and each one has consequences later.

• A consent record. A timestamped, auditable fact that this person authorised this application for these scopes. This is the artefact that matters in a dispute.
• A scoped token. Permission is granular. Approving profile read does not grant insights, and requesting scopes you do not use is a common app review rejection.
• A revocation path. The creator can withdraw permission from their platform settings at any time, without telling you.
• A lifecycle you now own. Tokens expire. Instagram long-lived tokens last about 60 days. TikTok access tokens last 24 hours. Neither refreshes itself.

Public data has none of these four. There is no consent, no scope, no revocation and no lifecycle, because there is no relationship. That absence is the source of both its advantages and its liabilities.

What can public social data return?

More than people give it credit for, and it is the right tool for a large class of products. Anything visible in a logged-out browser is fair game, at scale, on accounts that have never heard of you.

Field group	Typical contents	Good for
Profile	Handle, name, bio, avatar, external link, follower and following counts, post count	Discovery, screening, benchmarking
Content	Captions, hashtags, media URLs, permalinks, timestamps, media type	Listening, campaign tracking, content analysis
Public engagement	Like counts, comment counts, video and Reels view counts	Ranking, filtering, trend detection
Derived	Engagement rate, posting frequency, growth rate, caption length	Shortlisting at volume
Contact	Public emails and links where the creator published them	Outreach and enrichment

The strength is breadth and immediacy. You can query millions of accounts on day one with no relationship to any of them. That is not a compromise, it is a different capability, and no authenticated system substitutes for it. We covered the official public surfaces and their limits in social media public data.

What can public data never return?

Five field groups, and this is a structural boundary rather than a gap that will close. Each one is a deliberate platform decision to release the data to the account holder alone.

Field group	Why it is withheld	What public tools offer instead
True impressions and reach	Rendered only inside the creator's own analytics view	Estimated reach, modelled from followers and engagement
Audience demographics	Age, gender and location released to the owner only	Inferred demographics from follower sampling
Saves, shares, profile visits	Private engagement signals never exposed publicly	Likes and comments as a proxy, which misses the formats that drive discovery
Stories and ephemeral content	Expires in 24 hours and is never publicly archived	Nothing. There is no public Stories layer
Earnings and payouts	Never rendered on any public surface on any platform	Rate card estimates, which are guesses about price not records of payment

The right-hand column is the part worth arguing about, so the next section takes it apart.

How are public estimates actually derived?

By modelling, from the public signals that are available. That is legitimate and useful, and it becomes a problem only when a modelled number is presented, resold or filed as a measured one.

The two most common derivations work roughly like this. Estimated reach extrapolates from follower count and recent engagement, often with a platform-specific multiplier: an account with 100,000 followers and a 4 percent engagement rate might be modelled at some fraction of followers as likely viewers. Inferred audience demographics sample a subset of visible followers, classify each one from their own public profile, and project the distribution onto the whole audience.

Both can be genuinely accurate at the top of the follower distribution and both degrade sharply on small accounts, where the sample is thin and the multiplier is unstable. If your product serves nano and micro creators, that is exactly where you need the numbers to hold and exactly where they do not.

The one question that sorts honest vendors from careless ones

Ask what the API returns when the model cannot produce a defensible number.

One vendor response I have seen returned null for engagement rate along with a warning explaining that a lifetime likes-to-followers ratio above 1.0 is not a real engagement rate, so it declined to invent one. That is the correct behaviour and it is uncommon. A vendor that always returns a number is either always confident or never checking, and only one of those is possible.

Two follow-ups worth asking in the same call. Is this field measured or modelled, in writing. And is the model documented, or is it proprietary. A proprietary model is fine. An undisclosed one you are reselling as measurement is not.

What can authenticated data return that public cannot?

The five groups from the previous table, as measurements rather than models, because they come from the platform's own analytics through its official channel.

Field group	What arrives	Why it matters commercially
True impressions and reach	Exact counts per post from the platform	Real cost per impression instead of a modelled estimate. This is the number a media plan is defensible on
Audience demographics	Age, gender and location distributions	A brand can rely on it. Inferred demographics do not survive a client challenge
Stories and ephemeral formats	Performance captured while the Story is live	A large share of campaign delivery happens in formats public data cannot see at all
Earnings and payouts	Where the platform exposes them	The only route to income verification. No public source holds this at any size
Verified cross-platform identity	One creator, their connected accounts, confirmed	Public identity linking is inference. Consent makes it a fact

The mechanism matters as much as the fields. Because the data comes from the platform to you through an authorised channel, you get three properties public collection cannot offer: it is first-party rather than modelled, it is auditable back to a consent record, and it carries a documented legal basis.

What can authenticated data not return?

Six things, and this is the section that usually goes missing. I would rather you find these here than in month three.

1. Anyone who has not connected. This is the whole constraint. A creator who has never authorised your app does not exist in your authenticated data, at any price. If your workflow is discovery, prospecting or competitor research, authenticated access cannot serve it.
2. Most history from before they connected. Platforms typically expose a limited analytics window, so connecting today does not hand you three years of impressions. Some fields backfill, many do not. Ask per field, per platform.
3. Anything after revocation. The moment a creator disconnects, the tap closes. More on the consequences below.
4. Breadth. Your authenticated coverage equals your connected user count. On day one that is zero.
5. Fields the platform withholds even from the owner through its API. This is the nuance most people miss, and it is the honest ceiling on the model. Consent gets you what the account holder can see through the API, not what they can see in the app. If Meta does not expose a metric to a creator programmatically, no consent flow unlocks it. Historical Stories are the clearest case: after 24 hours the creator cannot retrieve them either.
6. Immunity from platform limits. An authenticated layer inherits every rate limit, quota and deprecation the platform imposes. Instagram's rate limit runs on a formula tied to each account's impressions. TikTok tokens expire every 24 hours. Meta retired an entire API with 90 days notice. Consent does not exempt anyone from that, as covered in our Instagram API guide and TikTok rate limits guide.

Point five is worth sitting with if you are evaluating a consented vendor, including us. The correct question is not "do you have consent" but "which fields does the platform expose to an authorised app, per platform." Those are different lists and only the second one is coverage.

What happens when a creator revokes access?

Authenticated data stops immediately, usually without warning, and you may owe deletion depending on your lawful basis and what you told the creator. Public data has no revocation mechanism, which sounds like an advantage and cuts both ways.

	Authenticated	Public
How it ends	Creator revokes in platform settings, or the token expires	It does not end. There is no relationship to sever
How you find out	API calls start failing. You will not get a notification	Not applicable
Historical data you hold	Retention depends on your basis and your notice. Take advice	Unaffected by any creator action
Practical consequence	A live connection becomes a dead one and your UI must handle it	You keep collecting, and you keep owning the compliance question
Detectability	High. A failed call is loud	Low. Nothing tells you a record is stale

Build for revocation explicitly. Distinguish a revoked connection from an expired token in your error handling, because one needs the creator to reconnect and the other needs your refresh job to run. Surface disconnected accounts in your UI rather than showing stale numbers. And decide your retention policy before launch, not after the first deletion request.

# Distinguish the three states. They need different responses.

from enum import Enum

class ConnState(Enum):
    LIVE      = "live"        # token valid, data flowing
    STALE     = "stale"       # token expired, refresh it, no user action
    REVOKED   = "revoked"     # creator withdrew consent, needs reconnect
    DEGRADED  = "degraded"    # platform rate limited us, retry later

def classify(err):
    code = getattr(err, "code", None)
    if code in (401, "access_token_invalid"):
        return ConnState.STALE if refresh_token_valid() else ConnState.REVOKED
    if code in (429, "rate_limit_exceeded", 80002):
        return ConnState.DEGRADED
    if code in (403, "scope_not_authorized"):
        return ConnState.REVOKED       # scopes withdrawn
    raise

# Rules that follow from the state:
#   STALE    -> refresh silently. Never bother the user.
#   REVOKED  -> stop reading. Mark dead in the UI. Prompt reconnect.
#   DEGRADED -> back off. Do NOT show an error; the data is still valid.
# Showing a revoked account as if it were live is the failure mode
# that produces a support ticket instead of a reconnect.

Which source survives an audit?

Authenticated, and it is not close. This is the difference that decides procurement in regulated categories, and it has almost nothing to do with data quality.

The question an auditor, a client or a regulator asks is not "is this number accurate" but "where did this number come from, and what entitled you to have it." Authenticated access answers both: the platform returned it, and here is the timestamped consent record that authorised the request. Public collection answers neither with the same force. You have a vendor's assertion about a number and a general argument about public availability.

Question	Authenticated	Public
Where did this figure come from?	The platform, through an authorised channel	A vendor, by collection or by model
Can you evidence the basis?	Yes, a consent record with scopes and a timestamp	A general argument about public availability
Is it measured or modelled?	Measured	Often modelled, and not always labelled
Can the subject object?	They can revoke, which is itself the answer	There is usually no mechanism they know of
Fit for hiring, lending, visas	Designed for it	Depends heavily on jurisdiction and use

If you sell into fintech, HR, background verification or immigration, this table is the reason a consent-first model is a procurement requirement rather than a preference. We go through the specific cost and compliance mechanics in social screening pricing. None of this is legal advice, and the position varies by jurisdiction and use case, so take counsel.

Why do the two have opposite coverage curves?

Because one starts complete and erodes, and the other starts empty and compounds. This is the most useful thing in the post for anyone making a three-year architecture decision, and I have not seen anyone else make the point.

Public coverage starts at its maximum on day one and decays. You can query everything visible today. Then platforms restrict. Meta retired the Instagram Basic Display API entirely. Instagram hashtag search will not return a username. TikTok's Research API narrowed to academic institutions. LinkedIn withholds creator engagement at every commercial tier. Every one of those moves went the same direction, and none reversed.

Authenticated coverage starts at zero and grows with your product. Every creator who connects adds permanent depth on that creator. Nothing a platform does about public access takes it away, because the account holder authorised it. Your coverage curve is your adoption curve.

	Public	Authenticated
Day one	Maximum breadth, zero depth	Zero breadth, maximum depth per connection
Direction of travel	Narrowing. Every platform change in five years has restricted access	Widening with your user base
What a platform policy change does	Can remove a field or a whole API overnight	Can change the API surface, not your permission
Risk concentration	Platform policy risk	Adoption and onboarding-friction risk

Neither curve is better. They mean different things for a business plan. If your roadmap depends on public breadth staying where it is today, that is a bet against a five-year trend. If it depends on authenticated depth, the bet is on your own onboarding conversion, which you control.

How do you run both, and what breaks at the seam?

With an explicit precedence rule, and the seam is identity. Most production systems in this category use public data for discovery and screening, then authenticated data for verified numbers once a creator is onboarded. The failure is not in either source. It is in the merge.

Three rules keep it clean.

1. Authenticated wins on any field it returns. Not the newer value, not the higher value. The source. If both return follower count, the authenticated figure is the one you render.
2. Never average or reconcile numerically. A modelled reach of 40,000 and a measured reach of 26,000 do not average to anything meaningful. Pick the measured one and discard the other.
3. Carry provenance on every field, all the way to the UI. If a brand asks whether a number is measured or estimated, the answer must be in your data model, not in someone's memory.

# Field-level resolver with provenance. Precedence, not arithmetic.

SOURCE_RANK = {"authenticated": 2, "public": 1}   # higher wins

def resolve(field, candidates):
    """candidates: [{"value":..., "source":..., "fetched_at":...,",
       "measured": bool}]  ->  one value plus provenance."""
    usable = [c for c in candidates if c["value"] is not None]
    if not usable:
        return {"value": None, "source": None, "measured": None}

    best = max(usable, key=lambda c: (SOURCE_RANK[c["source"]],
                                      c["fetched_at"]))
    return {
        "value":      best["value"],
        "source":     best["source"],
        "measured":   best["measured"],   # render this in the UI
        "fetched_at": best["fetched_at"],
        "alternates": [c for c in usable if c is not best],
    }

# Example: reach for a connected creator
resolve("reach", [
  {"value": 40000, "source": "public",        "measured": False,
   "fetched_at": "2026-07-27T09:00Z"},
  {"value": 26410, "source": "authenticated", "measured": True,
   "fetched_at": "2026-07-27T08:00Z"},
])
# -> 26410, authenticated, measured=True
# Note the authenticated value is OLDER and still wins.
# Recency is not a tiebreaker across sources, only within one.

The comment on that last line is the rule people get wrong. Sorting by freshness across sources will silently promote a modelled estimate over a measurement, and nothing in your logs will tell you it happened.

On identity: reconciling a public record to a consented one is its own problem, and getting it wrong means attributing one creator's numbers to another. That is what identity resolution and account linkage exist for, and it is worth more attention than it usually gets.

Which should you build on?

Answer one question: does your product require the creator to show up? If they are signing in anyway, authenticated access adds no friction and unlocks fields no index holds. If your product must work on people who have never heard of you, authenticated access cannot help you at any price.

What you are building	Primary source	Why
Creator discovery or search	Public	Needs breadth on people who have not signed up
Media kit or creator dashboard	Authenticated	The creator is logged in and wants their real numbers
Income verification or creator lending	Authenticated	No public source holds earnings at any size
Brand monitoring and social listening	Public	There is no account holder to ask
Influencer vetting before spend	Both, in sequence	Public to screen, authenticated to verify once onboarded
Social screening for hiring or visas	Public, with consent process	Subject rarely connects. Consent is a legal design question
Campaign reporting to a client	Authenticated	Estimated reach does not survive a client challenge
Competitor benchmarking	Public	Nobody authorises you to study them

Where does Phyllo fit, and where does it not?

We are the authenticated side. A creator connects through your product, and Phyllo's social data API returns true impressions, audience demographics, engagement across every format including Stories, and earnings where the platform exposes them, normalised across 25+ platforms through one integration with token lifecycle handled. Per-platform, per-field coverage is public at getphyllo.com/coverage and the reference at docs.getphyllo.com.

We also run social listening and social screening on public signals, because those jobs have no account holder to ask. Both models exist here for the reasons in this post, not as a product accident.

Where we are the wrong purchase, stated plainly. Everything in the public column above is available on creators who have never heard of you, and we cannot serve that, because we need the creator to connect. If discovery, competitor research or breadth is the job, buy a public index. Modash for creator discovery with audience modelling, EnsembleData for TikTok volume, Bright Data or Oxylabs for enterprise scale. Those are recommendations, not politeness, and we say the same thing in the universal API guide.