Creator Income Data via API: Fields, Sources and Verification

Creator income is the field with the widest gap between demand and availability in this entire category. Lenders, underwriters, course platforms and payout products all need it, and almost no platform provides it.

The honest starting position: of the 4 major social platforms, exactly 1 returns revenue through a developer API. And the figure it returns is an estimate that revises twice before it settles, with the final number held somewhere the API cannot reach.

Below: what each platform exposes, the exact YouTube fields and their definitions, the revision cycle that should drive your refresh design, and how to build an income product that is honest about what it cannot see.

Which platforms expose creator revenue?

That table is short and it is the whole platform picture. Any product promising multi-platform creator income verification is either aggregating non-social sources, modelling from engagement, or describing YouTube. Ask which. The wider field matrix is in social data API coverage.

Note also that earnings are never rendered on any public surface on any platform, so no scraping approach reaches them at any scale or price. This is the clearest example in the market of a field that requires the account holder's authorisation, which we set out in authenticated versus public social data.

What revenue fields does YouTube return?

A detailed set, and the distinctions between them matter for anyone doing arithmetic on the output.

2 traps in that table. Gross and net appear side by side with similar names, so grossRevenue and estimatedRevenue are not comparable and a dashboard mixing them produces nonsense. And there are 3 CPM variants with different denominators, so a CPM figure is meaningless without knowing which one produced it.

Figures default to USD, and the Analytics API supports a currency parameter for some estimated revenue and ad performance metrics. If you serve creators outside the US, set it explicitly rather than converting afterwards at a rate that will not match the platform's.

One deprecation to check in older code: the earnings metric was deprecated and API requests specifying it now return HTTP 400. It was renamed estimatedRevenue. This fails loudly rather than silently, which is the better kind of breakage, but it fails completely. Scope detail is in YouTube OAuth scopes.

Check which revenue fields each platform exposes before you scope an income product. See the coverage list

Why does the figure keep changing?

Because estimated revenue is genuinely an estimate, and it is adjusted twice on a published schedule after the revenue is generated.

That last row is the most important fact on this page for anyone underwriting on creator income. The API gives you estimated revenue. Finalized earnings exist in AdSense for YouTube and may differ from the estimate, for example because of tax withholding. The API does not return them.

So a product that verifies creator income from the Analytics API is verifying an estimate, not a settlement. That is still far better than a rate card or a follower count, and it is not the same thing as a bank statement. Say so in your product rather than letting a lender assume otherwise.

The causes of movement are documented: invalid traffic, Content ID claims and disputes, and certain ad campaign types such as cost-per-day campaigns. A creator whose video attracted a Content ID dispute will see their estimate move, and the movement is correct rather than a data error.

How should the refresh cadence work?

Around the revision schedule rather than on a fixed interval, because a fixed interval either wastes calls re-reading settled months or misses the revisions on recent ones.

# Revenue refresh driven by the revision schedule, not a cron interval.

from datetime import date

def revenue_state(period_month, today=None):
    """How settled is the revenue figure for a given month?"""
    today = today or date.today()
    months_elapsed = (today.year - period_month.year) * 12 \
                   + (today.month - period_month.month)

    if months_elapsed == 0:
        return "PROVISIONAL"   # current month. Changes daily.
    if months_elapsed == 1 and today.day < 15:
        return "ADJUSTING"     # second adjustment not yet applied
    if months_elapsed == 1:
        return "NEAR_FINAL"    # mid-month adjustment applied
    return "SETTLED"           # unlikely to move further

REFRESH = {
    "PROVISIONAL": 1,     # days. It is moving, so read often
    "ADJUSTING":   1,
    "NEAR_FINAL":  7,
    "SETTLED":     None,  # stop. Re-reading a settled month is waste
}

# 2 rules that follow:
#   1. NEVER underwrite on a PROVISIONAL month. It is incomplete
#      by construction, not by accident.
#   2. Stop refreshing SETTLED months. Most income products burn
#      most of their quota re-reading figures that cannot change.

The second rule is where the cost sits. An income product pulling 24 months of history daily is re-reading 22 months that have not moved since they settled. Mark months settled, stop reading them, and your call volume drops by an order of magnitude with no loss of accuracy.

The first rule is where the risk sits. Underwriting on a current-month figure means underwriting on a number that is incomplete by design. Use completed, settled months and say which months your decision used.

What is excluded from the API figure?

3 things, and each one is a gap a lender should be told about rather than discover.

• Partner-sold and partner-served advertising. The estimated revenue metrics explicitly exclude it, so a channel with meaningful partner-sold inventory earns more than the API reports.
• Finalized earnings and tax withholding. Only in AdSense. The amount withheld is not visible through the API at all.
• Everything that is not YouTube. Which for most creators is most of their income.

How much of a creator's income does any platform see?

Less than people assume, and this is the structural limit on every income verification product including ours.

Patreon's own creator census found that Patreon accounts for 41% of a Patreon creator's income. That is the platform where those creators actively monetise, and it still sees under half the picture. The remainder comes from website advertising, sponsorships and influencer compensation, direct sales, fan contributions and social traffic revenue.

Brand deals are the biggest gap. They are negotiated privately, paid by invoice or through an agency, and appear on no platform API. For many creators they are the largest single income line, and they are entirely invisible to a platform-based verification product.

The honest conclusion for anyone building underwriting on this: verified platform revenue is a floor, not a total. It proves income exists and establishes a verifiable baseline. It does not establish the full picture, and a model that treats it as total income will systematically under-lend to exactly the creators who earn most from brand work.

How should an income product present this?

1. Report the verified portion separately from any self-declared total. A creator stating $12,000 a month with $4,100 verified from YouTube is a useful record. Collapsing them into one figure is not.
2. Label estimated against settled per month. The state machine above belongs in your data model and in your interface.
3. Name the sources you checked and the sources you could not. Coverage transparency is what makes a verification product defensible rather than merely confident.
4. Use settled months for decisions. Provisional months are useful for trend, not for underwriting.
5. Keep the revision history. When a figure moves, the movement is information, and a lender asking why a number changed deserves an answer rather than a shrug.

Why does this market exist now?

Because creator income stopped being a private matter and became a reporting obligation, which manufactures a verification requirement.

• DAC7 in the EU requires platforms to report seller and creator income to tax authorities.
• The phased 1099-K threshold reduction in the US brings far more creators into scope for reporting.
• Platform monetisation eligibility itself now turns on private data. X's 2026 Ads Revenue Share requires Premium, 500 verified followers and 5 million impressions over 3 months, and verified impressions are not visible publicly.

When income must be reported, it must be verifiable, and when a creator cannot prove eligibility from public data, neither can anyone underwriting them. The vertical picture is in social data use cases across HR, fintech, edtech and govtech.

Where does Phyllo fit?

Creator income data is the reason most fintech and creator lending products come to us, and it is worth being precise about what that means. We return the platform's own revenue figures for creators who connect, normalised across the platforms that expose them, through one API with the token lifecycle handled. Identity resolution ties a creator's accounts to 1 record so income across sources attaches to 1 person rather than several guesses.

What we do not do is invent revenue for platforms that expose none. There is no Instagram or TikTok earnings field to return, so we do not return one, and a vendor showing you TikTok creator earnings is modelling from engagement rather than reading a payout. That may be useful and it is a different claim. Per-platform coverage is public at getphyllo.com/coverage and the API reference needs no sales call.

The limit we would state to a lender in the first meeting. Platform revenue is a verifiable floor rather than a total, brand deals are invisible to every API in this category, and the YouTube figure is an estimate that settles over about 6 weeks. An underwriting model built on those 3 facts is sound. One built on the assumption that verified platform revenue equals creator income is not.

The short version

1 platform of the 4 returns revenue, the figure it returns is an estimate that settles over roughly 6 weeks, and the finalized number lives somewhere the API cannot reach. Build your refresh around the settlement schedule and make underwriting decisions on settled months only.

Then be explicit about the blind spot. Platform revenue is a verified floor, brand deals are invisible to every API in this category, and a product that presents the floor as the total will misprice exactly the creators who earn most outside the platforms.

Want verified platform revenue, with the settlement states and the limits stated plainly? Get a demo