Social Data API Pricing in 2026: What You Actually Pay Per 1,000 Profiles

Published rates for social data APIs in July 2026 land between roughly $0.18 and over $7 per 1,000 profiles. The reason nobody tells you that plainly is that no two vendors price in the same unit, so the comparison requires arithmetic that pricing pages are not designed to make easy.

I normalised eleven providers to a single number: what it costs to retrieve 1,000 public profiles, using each vendor's own published rates and their own credit weights. The table is below, the working is shown, and there is a script you can run against your own volumes.

Two warnings before the numbers. Every figure comes from a vendor's public page in July 2026 and this category reprices constantly, so verify before you take anything to finance. And the headline rate is usually not what you pay, for five specific reasons I will go through.

Why can you not just compare the prices?

Because there are seven different billing units in play, and four of them are not units at all. Until you convert everything to one denominator, you are comparing a per-item rate against a monthly pool against a daily allowance against a compute second.

What does 1,000 profiles actually cost?

Here is the normalised table. Every number is derived from the vendor's published price and published credit weights, at 100% utilisation of whatever allowance you bought. Working is shown in the next section so you can check it.

Two rows deserve a second look. Data365 gets more expensive per profile as you move up a tier, from EUR 5.40 on Basic to EUR 7.65 on Standard, because you are buying network breadth rather than volume. That is a legitimate product decision and it is invisible if you only compare monthly prices.

And the X official API sits at roughly 67 times the price of a third-party alternative on tweet retrieval. Basic is $100 a month for 10,000 tweets, which is $10 per 1,000. twitterapi.io publishes $0.15 per 1,000. That gap, plus the $42,000 monthly floor on enterprise, is the whole reason this vendor category exists.

How was that table calculated?

Three formulas, depending on the billing model. All of it is arithmetic you can redo in a spreadsheet, which is the point.

Per-item providers

Simplest case. SocialData publishes $0.0002 per profile returned, so 1,000 profiles is $0.20. twitterapi.io publishes $0.18 per 1,000 profiles directly.

Daily-unit providers

EnsembleData sells units per day, and on TikTok a User Info call costs 1 unit and returns one full profile. So one profile is one unit.

monthly_units   = daily_units * 30
cost_per_1k     = monthly_price / monthly_units * 1000
# Bronze: $200/mo, 5,000 units/day
#   = 150,000 units/mo
#   = $200 / 150,000 * 1000
#   = $1.33 per 1,000 profiles
# Platinum: $1,400/mo, 50,000 units/day
#   = 1,500,000 units/mo
#   = $0.93 per 1,000 profiles

Note what else that unit table tells you. On EnsembleData, User Posts costs 1 unit and returns 10 posts, Post Comments costs 1 unit and returns 30 comments, and Followers List costs 2 units and returns 100 followers. So comments are effectively 30x cheaper per item than profiles. If your workload is comment-heavy, the profile rate is the wrong number to optimise.

Weighted-credit providers

This is where the marketing number and the real number diverge most. Data365 publishes that a profile with info costs 9 credits, a post costs 1, and a search costs 7.

credits_needed  = profiles * credits_per_profile
cost_per_1k     = monthly_price / plan_credits * credits_needed
# Basic: EUR 300/mo, 500,000 credits, profile = 9 credits
#   1,000 profiles = 9,000 credits
#   = EUR 300 / 500,000 * 9,000
#   = EUR 5.40 per 1,000 profiles
# The 500,000 credit pool sounds enormous.
# At 9 credits per profile it is 55,555 profiles.

That last line is the one worth internalising. A 500,000 credit allowance reads like a lot until you divide by the weight. It is 55,555 profiles a month, which a monitoring product refreshing 2,000 accounts daily would exhaust in 28 days.

What are the five things that change your real bill?

None of them appear on a pricing page. All five have moved a real budget by more than 2x.

1. Utilisation, the silent multiplier

Every subscription rate per 1,000 assumes you consume the entire allowance. Use half and you have doubled your true rate. EnsembleData Bronze is $1.33 per 1,000 at full use and $2.67 at half. SocialAPIs Ultra is $1.63 and $3.27. This single factor moves more budgets than any negotiation.

2. Reset policy, which punishes bursty work hardest

If your access pattern is spiky, a never-expire balance at a higher headline rate frequently beats a daily-reset plan at a lower one. Do that arithmetic before you optimise the rate.

3. The small-pack penalty

Entry tiers are priced 2x to 8x the volume rate, which means the price you validate against is almost never the price you scale at.

• SocialCrawl: GBP 6.00 per 1,000 on Starter against GBP 1.99 on Pro. 3x.
• SociaVault: $4.83 on Starter against $2.00 on Enterprise. 2.4x.
• EnsembleData: $2.22 on Wood against $0.93 on Platinum. 2.4x.
• SocialAPIs: $3.33 on Pro against $1.49 on Mega. 2.2x.

4. Endpoints that bill per item, not per call

This is the one that produces genuinely shocking invoices, and it is the most important paragraph in this post. On per-item providers, a follower endpoint bills for every follower returned.

One creator. One follower list. One thousand dollars. Now imagine a nightly refresh, and imagine you sized your budget from the $0.20 per 1,000 profiles headline. The same logic applies to comments, quotes, retweeters and list members on any per-item provider.

5. Whether failed requests are billed

Most providers do not charge for failed calls, and several say so explicitly. SocialData and EnsembleData both state that failed requests consume no balance. SocialAPIs states that 4xx and 5xx responses do not consume credits.

One nuance worth reading carefully. SocialData's fair-use policy gives every account 3 free requests per minute that return no data, and charges $0.0002 for empty responses beyond that. If your workflow probes for existence at high frequency, checking whether handles are valid, you are paying for the misses.

How do you model this against your own volumes?

With about thirty lines of Python. Run it with your real access pattern before you sign anything, because the answer frequently reorders the vendors.

# social_api_cost.py
# Normalise any vendor to cost per 1,000 of YOUR unit mix.
def per_item(rate_per_item, n):
    return rate_per_item * n
def daily_units(monthly_price, units_per_day, units_needed,
                utilisation=1.0, days=30):
    """Daily-reset plans. Unused units are lost each day."""
    usable = units_per_day * days * utilisation
    if units_needed > usable:
        raise ValueError("Exceeds plan. Price the next tier up.")
    return monthly_price * (units_needed / usable)
def weighted_credits(monthly_price, plan_credits, weights, mix):
    """weights: {"profile": 9, "post": 1, "search": 7}
       mix:     {"profile": 1000, "post": 5000, "search": 200}"""
    credits = sum(weights[k] * v for k, v in mix.items())
    if credits > plan_credits:
        raise ValueError(f"Needs {credits:,} credits, plan has {plan_credits:,}")
    return monthly_price * (credits / plan_credits), credits
# --- your actual monthly workload ---
MIX = {"profile": 1000, "post": 5000, "search": 200}
# Per-item provider, and remember followers bill per follower
print("per-item profiles:", per_item(0.0002, MIX["profile"]))
print("one 500k follower list:", per_item(0.0002, 500_000))
# Daily-unit provider at realistic 60% utilisation
print("daily-unit @60%:", daily_units(200, 5000, 1000, utilisation=0.6))
# Weighted-credit provider
cost, credits = weighted_credits(300, 500_000,
                                 {"profile": 9, "post": 1, "search": 7}, MIX)
print(f"weighted: {credits:,} credits, EUR {cost:.2f}")

Change one input and watch the ranking move. Set utilisation to 0.4, which is normal for a product with weekday traffic, and the daily-unit provider stops being cheap. Add a single follower enumeration and the per-item provider stops being cheap. Neither vendor is being dishonest. Their pricing just answers a different question from the one you are asking.

How do you track spend once you are live?

Read the usage headers on every response and store them, rather than reconciling from an invoice at month end. Most providers expose consumption inline and the field names differ.

# SocialAPIs: header
#   X-SocialAPIs-Credits-Used: 1
# SocialCrawl: in the response body
# {
#   "success": true,
#   "credits_used": 1,
#   "credits_remaining": 184333
# }
# Pattern worth adopting in your HTTP client wrapper:
def log_spend(response, provider):
    used = (response.headers.get("X-SocialAPIs-Credits-Used")
            or response.json().get("credits_used"))
    remaining = response.json().get("credits_remaining")
    metrics.increment(f"{provider}.credits", float(used or 0))
    if remaining is not None and float(remaining) < LOW_BALANCE:
        alert(f"{provider} balance low: {remaining}")
    return response

Two habits that pay for themselves. Alert on balance, not on spend, because a depleted balance returns HTTP 402 or a 403 with an insufficient credits code and your pipeline stops rather than degrades. And tag spend by feature, so when the bill jumps you know which product surface caused it.

Where do vendors contradict themselves?

Often enough that you should verify every quote against the vendor's own live page on the day you buy. These are not accusations, they are observations about published pages in July 2026, and each one would change a budget.

The practical takeaway is not that these vendors are unreliable. It is that a screenshot of the pricing page with a date on it belongs in your procurement file. If a rate is load-bearing in your business case, get it in writing from a human.

Why is consented data priced differently?

Because the cost structure has nothing in common with public collection, and comparing the two on cost per 1,000 profiles is a category error rather than a competitive comparison.

A public data provider runs collection infrastructure. Their marginal cost is per record retrieved, so they bill per record, and volume discounts follow naturally. A consented provider runs OAuth infrastructure: consent flows across platforms, token lifecycle management, refresh jobs, webhook delivery, and app review maintenance with every platform. Their marginal cost is per connected account, not per record read, because once a creator is connected, reading their data again is nearly free.

So the two models bill for different things:

Look at the third and fourth rows together, because that is the whole decision. If your product refreshes the same 5,000 creators daily, a per-record model bills you 150,000 times a month for the same 5,000 accounts. If your product needs one-time reads across two million profiles nobody has authorised, a consented model cannot serve you at any price.

That is what Phyllo's social data API is priced against. A creator connects once through your product, and you get true impressions, audience demographics, Stories performance and earnings across 25+ platforms from one integration, refreshed as often as you need. Field-level coverage is public at getphyllo.com/coverage, the API reference needs no sales call, and current pricing is on our pricing page.

Where we are the wrong purchase, plainly. We need the creator to connect. If your job is cold breadth across accounts that have never heard of you, buy a public data API from the table above and do not let anyone talk you out of it. We cover the split in consent-based versus public social APIs and the full market in the best social media data APIs.

How should you run a real cost test before buying?

1. Write down your access pattern first. How many distinct accounts, how often each is refreshed, how many posts and comments per account. The pattern decides the winner more than the rate does.
2. Convert every quote to your own unit mix using the script above, including the vendor's credit weights. Not to profiles, to your mix.
3. Apply realistic utilisation. Use 40 to 60 percent unless you have evidence otherwise. Then check the answer again.
4. Price one follower or comment enumeration explicitly. If any endpoint bills per item, model your largest account, not your average one.
5. Ask what happens at zero balance. A 402 or a 403 that stops your pipeline is an outage, so you need alerting before you need pricing.
6. Run the free tier against your real target. Every provider in the table has one. A 200-response with an incomplete body is not a success, and you will only find that out by looking.
7. Compute cost per validated result, not cost per call. Total spend divided by outputs that passed your quality check. That is the only number that compares across vendors.
8. Screenshot the pricing page with a date. For the reasons in the contradictions table.