Customer Concentration API: Major Customer Share

A customer concentration API answers one question that 10-K readers ask all the time: how much of this company's revenue comes from its biggest customer? For Cirrus Logic the answer is 91%. Apple accounted for approximately 91% of its net sales in the fiscal year ending March 28, 2026, up from 79% four years earlier, and the figure is printed in the company's own 10-K. Getting it as data, for many companies and many years, is a different job.

The percentage lives in an XBRL fact that SEC's free JSON APIs do not serve, the customer is often unnamed, and the receivables table can name different counterparties, with different numbers, than the revenue disclosure in the same filing. /api/footnotes/concentration returns these disclosures as time series per counterparty. This tutorial covers what a 10% customer disclosure is, how it is tagged, why SEC's API returns a 404 for it, a real request and response for Cirrus Logic with the SEC receipt, a short Python script that finds the largest customer share of revenue, and the pitfalls that split or mislabel a naive series.

What a 10% customer disclosure is, and why names go missing

Two rules put customer concentration into a 10-K. The first is the segment reporting standard. ASC 280-10-50-42 requires a disclosure "if revenues from transactions with a single external customer amount to 10 percent or more of a public entity's revenues": the company states that fact, the total amount of revenues from each such customer, and the segment or segments reporting them. The same paragraph adds the sentence that shapes every dataset built on these disclosures: "The public entity need not disclose the identity of a major customer or the amount of revenues that each segment reports from that customer." It also says that "a group of entities known to a reporting public entity to be under common control shall be considered as a single customer." Deloitte's segment reporting roadmap quotes the paragraph in full.

The second is Regulation S-K. Item 101(c)(1)(i) asks for a description of the business that covers "any dependence on revenue-generating activities, key products, services, product families or customers, including governmental customers" (17 CFR 229.101). That is why the same customer often appears twice in a 10-K: once by name in the business section or the risk factors, and once as a percentage in the notes to the financial statements.

Put together, the rules explain the data you get. The 10% threshold means a company with no customer at that level discloses nothing, so a missing figure is information too. The identity carve-out means a disclosure can say "Customer A", and many do. And the common-control rule means a parent and the entities it controls count as one customer. Some filers go further and count an end customer that buys through several contract manufacturers as one customer, as Cirrus Logic does for Apple. That choice is the filer's, not the rule's, and it matters later when the receivables table names the manufacturers instead.

How customer concentration is tagged in XBRL: ConcentrationRiskPercentage1

In the XBRL behind the 10-K, every concentration percentage is the same concept, us-gaap:ConcentrationRiskPercentage1, a pure number. What makes a fact mean "Apple's share of revenue" rather than "Foxconn's share of receivables" is the set of dimensions it carries:

XBRL US published data quality rule DQC_0109 for this concept because "the concentration risk percentages are poorly tagged with many inconsistent practices adopted by filers." The rule, effective September 1, 2021, requires both the benchmark axis and the type axis on every concentration disclosure, and expects a percentage that carries only those two axes, with no third axis such as the Major Customers Axis, to equal 1. That last point is the useful one: a single customer's share can only be expressed with a third dimension, and a fact without one is 100% of the benchmark.

The rule is recent compared with the filings. Older 10-Ks, and some current ones, skip the type axis or the benchmark axis, use different benchmark members from one year to the next, or name the customer with a generic member. All of that ends up in the data, and the pitfalls section below shows each case on a real filer.

Why SEC's XBRL API returns 404 for customer concentration

The natural first try is SEC's companyconcept endpoint for Cirrus Logic (CIK 772406):

curl -A "your-app you@example.com" \
  "https://data.sec.gov/api/xbrl/companyconcept/CIK0000772406/us-gaap/ConcentrationRiskPercentage1.json"

It returns HTTP 404, as if Cirrus had never tagged the concept, although its latest 10-K uses it throughout its concentration table. The same URL with RevenueFromContractWithCustomerExcludingAssessedTax returns Cirrus's revenue history, so the company and the endpoint are fine. The frames endpoint, which returns one fact per company for a period, is no better:

curl -A "your-app you@example.com" \
  "https://data.sec.gov/api/xbrl/frames/us-gaap/ConcentrationRiskPercentage1/pure/CY2025.json"

The CY2025 frame holds 25 facts, and every one of them is 1, which is 100%. None comes from Cirrus Logic or Qorvo, and none says which customer or which benchmark it refers to.

SEC's EDGAR API documentation explains both results. The XBRL APIs aggregate facts that "use a non-custom taxonomy" and "apply to the entire filing entity". A customer's share of revenue does not apply to the entire entity; it applies to one member on a dimension, so it is left out altogether, not returned without its dimensions. The only concentration facts that pass the filter are the undimensioned ones, and by the logic of DQC_0109 those are the 100% totals. It is the same limit that keeps operating income by segment and Level 3 assets by company out of SEC's API.

The free route that does have the dimensions is SEC's Financial Statement and Notes data sets, which "provide the text and detailed numeric information from all financial statements and their notes" and are updated monthly. They are bulk files: you download them, join each fact to its dimensions, map every filer's benchmark and customer members, and stitch the years together yourself. That works, and it is the work an API does for you.

The customer concentration API: request, response and receipt

One call per company. Here is Cirrus Logic, annual view, five points per series:

curl "https://api.stockfit.io/v1/api/footnotes/concentration?symbol=CRUS&period=annual&limit=5" \
  -H "Authorization: Bearer $STOCKFIT_API_KEY"

The response is series-major: instead of one block per fiscal year, it has one group per risk type and benchmark, and each counterparty in a group carries its own history, newest first. Cirrus comes back with four groups (customer × revenue, customer × receivables, and one untyped group for each benchmark). The customer × revenue group, trimmed to two of its three counterparties:

{
  "riskType": "customer",
  "benchmark": "revenue",
  "riskTypeMembers": ["us-gaap:CustomerConcentrationRiskMember"],
  "benchmarkMembers": ["us-gaap:SalesRevenueNetMember"],
  "counterparties": [
    {
      "member": "crus:TenLargestCustomersMember",
      "name": "Ten Largest Customers",
      "history": [
        { "period": "2026-03-28", "fiscalYear": 2026, "fiscalPeriod": "FY", "share": 0.96, "dateFiled": "2026-05-21" },
        { "period": "2025-03-29", "fiscalYear": 2025, "fiscalPeriod": "FY", "share": 0.96, "dateFiled": "2026-05-21" },
        { "period": "2024-03-30", "fiscalYear": 2024, "fiscalPeriod": "FY", "share": 0.95, "dateFiled": "2026-05-21" },
        { "period": "2023-03-25", "fiscalYear": 2023, "fiscalPeriod": "FY", "share": 0.92, "dateFiled": "2025-05-23" },
        { "period": "2022-03-26", "fiscalYear": 2022, "fiscalPeriod": "FY", "share": 0.93, "dateFiled": "2024-05-24" }
      ]
    },
    {
      "member": "crus:AppleIncMember",
      "name": "Apple Inc",
      "history": [
        { "period": "2026-03-28", "fiscalYear": 2026, "fiscalPeriod": "FY", "share": 0.91, "dateFiled": "2026-05-21" },
        { "period": "2025-03-29", "fiscalYear": 2025, "fiscalPeriod": "FY", "share": 0.89, "dateFiled": "2026-05-21" },
        { "period": "2024-03-30", "fiscalYear": 2024, "fiscalPeriod": "FY", "share": 0.87, "dateFiled": "2026-05-21" },
        { "period": "2023-03-25", "fiscalYear": 2023, "fiscalPeriod": "FY", "share": 0.83, "dateFiled": "2025-05-23" },
        { "period": "2022-03-26", "fiscalYear": 2022, "fiscalPeriod": "FY", "share": 0.79, "dateFiled": "2024-05-24" }
      ]
    }
  ],
  "aggregate": null
}

The fields you will use:

Now the receipt. Cirrus Logic's 10-K for the fiscal year ending March 28, 2026 (accession 0000772406-26-000018, filed May 21, 2026) says: "For the twelve-month periods ending March 28, 2026, March 29, 2025, and March 30, 2024, we had one end customer, Apple Inc., who purchased through multiple contract manufacturers and represented approximately 91 percent, 89 percent and 87 percent of the Company's total net sales, respectively." The next sentence puts the ten largest end customers at 96, 96 and 95 percent. The tagged table is R45 of the same filing, and every value in the response above matches it: Apple 91%, 89%, 87%, and the ten largest 96%, 96%, 95%.

Two details worth noticing already. "Ten Largest Customers" arrives as a counterparty, not in aggregate, because Cirrus tagged it with its own member; the endpoint reports what the filer tagged, so a group can mix single customers and groups of customers. And share is a fraction: multiply by 100 for display. When a filer tags a whole percent by mistake (91 instead of 0.91), the API rescales it and marks the point normalized: true.

Largest customer share of revenue in Python

The series-major shape is convenient for one company and awkward for a screen across many. The script below flattens each response into one row per counterparty and period, keeps the revenue rows, merges the duplicates explained in the next sections, and prints the latest period per company. It uses Cirrus Logic, Qorvo and Skyworks, three chip suppliers whose 10-Ks all name Apple as a major customer.

import os
import requests
import pandas as pd

BASE = "https://api.stockfit.io/v1/api"
HEADERS = {"Authorization": f"Bearer {os.environ['STOCKFIT_API_KEY']}"}


def concentration(symbol, period="annual", limit=15):
    r = requests.get(
        f"{BASE}/footnotes/concentration",
        params={"symbol": symbol, "period": period, "limit": limit},
        headers=HEADERS,
        timeout=30,
    )
    r.raise_for_status()
    return r.json()


def flatten(symbol, payload):
    rows = []
    for g in payload["groups"]:
        series = [(c["member"], c["name"], c["history"]) for c in g["counterparties"]]
        if g["aggregate"]:
            series.append(("(aggregate)", "(aggregate)", g["aggregate"]["history"]))
        for member, name, history in series:
            for p in history:
                rows.append({
                    "symbol": symbol,
                    "riskType": g["riskType"] or "untyped",
                    "benchmark": g["benchmark"] or "untyped",
                    "member": member,
                    "name": name,
                    "period": p["period"],
                    "share": p["share"],
                    "dateFiled": p["dateFiled"],
                })
    return pd.DataFrame(rows)


df = pd.concat([flatten(s, concentration(s)) for s in ["CRUS", "QRVO", "SWKS"]], ignore_index=True)

# Customer (or untyped) shares of revenue, one row per counterparty and period:
# when two groups report the same member and period, keep the newest filing.
rev = df[(df.benchmark == "revenue") & df.riskType.isin(["customer", "untyped"])]
rev = rev.sort_values("dateFiled").drop_duplicates(["symbol", "member", "period"], keep="last")

latest = rev[rev.period == rev.groupby("symbol").period.transform("max")]
for r in latest.sort_values(["symbol", "share"], ascending=[True, False]).itertuples():
    print(f"{r.symbol:<5} {r.period}  {r.name:<22} {r.share:>5.0%}  filed {r.dateFiled}")

Against the live API it prints:

CRUS  2026-03-28  Ten Largest Customers    96%  filed 2026-05-21
CRUS  2026-03-28  Apple Inc                91%  filed 2026-05-21
QRVO  2026-03-28  Apple                    50%  filed 2026-05-08
QRVO  2026-03-28  Samsung                  10%  filed 2026-05-08
SWKS  2025-10-03  Company                  67%  filed 2025-11-07

Qorvo's 10-K for the fiscal year ending March 28, 2026 (accession 0001628280-26-032873) confirms its two lines: Apple, reached "through sales to multiple contract manufacturers, which in the aggregate accounted for 50% and 47% of total revenue in fiscal years 2026 and 2025", and Samsung at 10% in both years. Qorvo's members use the legacy rfmd: prefix, not qrvo:, which is another reason to key on member per company rather than on a global list of names. Apple's share at Qorvo went from 37% for the year ending April 1, 2023 to 50% for the year ending March 28, 2026.

Two lines need a closer look before you rank anything. The top Cirrus line is a group of ten customers, not one, so a "largest customer" screen should drop members that stand for groups (match on the name or keep a per-company exclusion list). And the Skyworks line has no customer name at all; that is the subject of its own section below.

Apple's share of Cirrus Logic revenue since 2011

To chart one customer, filter on its member and sort by period:

apple = rev[(rev.symbol == "CRUS") & (rev.member == "crus:AppleIncMember")].sort_values("period")
for r in apple.itertuples():
    print(r.period, f"{r.share:.0%}", r.riskType, r.dateFiled)

2011-03-26 47% untyped 2013-05-29
2012-03-31 62% untyped 2014-05-28
2013-03-30 82% untyped 2015-05-27
2014-03-29 80% untyped 2016-05-25
2015-03-28 72% untyped 2017-05-24
2016-03-26 66% customer 2018-05-30
2017-03-25 79% customer 2019-05-24
2018-03-31 81% customer 2020-05-20
2019-03-30 78% customer 2021-05-21
2020-03-28 79% customer 2022-05-20
2021-03-27 83% customer 2023-05-19
2022-03-26 79% customer 2024-05-24
2023-03-25 83% customer 2025-05-23
2024-03-30 87% customer 2026-05-21
2025-03-29 89% customer 2026-05-21
2026-03-28 91% customer 2026-05-21

Sixteen fiscal years in one series, from 47% for the year ending March 26, 2011 to 91% for the year ending March 28, 2026. Without the merge step the series would come back in two pieces, and the riskType column shows where the seam is.

Revenue vs receivables concentration: same customer, different number

Cirrus Logic's customer × receivables group does not mention Apple at all. For the balance date of March 28, 2026 it lists Foxconn at 39% of accounts receivable and Luxshare at 22%. The revenue disclosure measures the end customer that buys the chips, counted as one customer across the contract manufacturers it buys through. The receivables disclosure measures who owes Cirrus money at the balance date, and those are the contract manufacturers that place the orders and pay the invoices.

So the same economic dependence produces two different counterparties and two different numbers in one filing, both correct. The practical rules:

• Never mix benchmarks in one ranking. Filter on benchmark first. A screen for "largest customer above 30%" that also reads receivables rows would list Foxconn as a Cirrus customer at 39%.
• Revenue shares cover a fiscal year, receivables shares a single date. One is a duration, the other a balance at the period end, which is also why the quarterly view treats them differently (see below).
• Read receivables concentration as credit exposure. Some filers tag it that way: Qorvo's receivables rows, which run up to the fiscal year ending March 28, 2020, carry CreditConcentrationRiskMember, so they come back as a credit × receivables group, not customer × receivables.

Unnamed customers: "Customer A" and Skyworks' "Company"

Skyworks tags its largest revenue customer with the member swks:CompanyMember, which the API labels "Company": 67% of revenue for the fiscal year ending October 3, 2025, after 69% and 66% in the two years before (10-K accession 0000004127-25-000085, filed November 7, 2025; R75 of that filing shows the same three values). The 10-K text does mention Apple, saying that Apple, "through sales to multiple distributors and contract manufacturers", "constituted more than ten percent of our net revenue." It does not say that the 67% row is Apple, and neither do we. ASC 280 lets a filer leave the identity out, and an unnamed member is how that looks in XBRL.

This has two consequences for anyone building on the data:

• A name search undercounts. Searching counterparty names for "Apple" finds Cirrus Logic and Qorvo and misses Skyworks. A question like "which companies depend on Apple for revenue" can only be answered from the named disclosures, plus a list of unnamed large customers that you have to read the filing for.
• The label is the filer's word, not a resolved entity. The API derives name from the member and does no entity resolution, so "Apple" at Qorvo and "Apple Inc" at Cirrus are different strings. Labels can also be odd: an older Skyworks series returns a member swks:CompanyCMemberDomain with the name "Company CMember Domain". Keep member as the key and treat name as display text.

The older Skyworks history shows one more gap. Its series up to the fiscal year ending October 2, 2020 come back with benchmark: null (some with riskType: null too), because those filings tagged no benchmark axis. From the XBRL alone you cannot tell whether such a share is of revenue or of receivables, so the script above leaves them out.

Customer concentration time series: merges, renames and filing dates

A missing type axis splits the series

The endpoint groups by category, not by raw member, so when Cirrus switched its revenue benchmark between SalesMember and SalesRevenueNetMember, both landed in one group. A missing type axis is a different category, though: riskType: null means the filer tagged no type, and the API does not guess one. Cirrus's Apple revenue share therefore comes back twice: an untyped group running from March 26, 2011 to March 25, 2017, and a customer group from March 26, 2016 to March 28, 2026.

The two overlap on two fiscal years and agree on both (66% for March 26, 2016, 79% for March 25, 2017), so merging on the counterparty member and the benchmark, then deduplicating on period, is safe here. That is the drop_duplicates line in the script, keeping the row from the newer filing. Check the overlap for each company you merge; if two groups ever disagree for the same member and period, look at both filings before choosing.

Renamed counterparties: Luxsan and Luxshare

Cirrus's receivables table for March 29, 2025 appears in two filings with two different answers. The fiscal 2025 10-K (accession 0000772406-25-000014, R46) tags "Luxsan" at 21%. The fiscal 2026 10-K tags "Luxshare" at 27% for the same date. Different members, so the API returns them as two counterparties, each with the value its filing reported. The filings we read do not explain the change, and we do not guess at it. If you track a contract manufacturer over time, expect to map a few members by hand and to choose which filing's view of a date you want.

What dateFiled means

dateFiled is the filing date of the newest filing that reported a value, not the first disclosure. Cirrus's Apple share for the year ending March 30, 2024 (87%) first appeared in the 10-K filed May 24, 2024, but it carries dateFiled 2026-05-21, because the fiscal 2026 10-K repeats it in its three-year table. Gating a backtest on dateFiled never shows a value before the filing it came from, so it is conservative: no look-ahead, at the cost of a later date than strictly needed. Our guide to point-in-time data for backtesting covers why the two dates matter. If you need the first-reported date, /api/filings with type=10-K lists each 10-K with its periodEndDate and dateFiled. The first 10-K whose periodEndDate matches the period is where the value first appeared: for Cirrus, the 10-K with periodEndDate 2024-03-30 has dateFiled 2024-05-24.

Coverage limits

• Prose-only disclosures are not covered. Coverage is US GAAP filers that tag the concentration axes. A company that only describes a major customer in text returns no group.
• Custom aggregates are not served. Qorvo's R45 shows its three largest accounts at 58% and 64% of receivables, and Skyworks' R75 shows a similar three-largest figure, but they are tagged on the filers' own elements rather than ConcentrationRiskPercentage1, and the API does not return them.
• Most revenue shares are annual. period=quarter returns the shares each 10-Q tagged, and a full-year revenue share is never served as a fourth quarter. For Cirrus Logic and Qorvo, which disclose concentration in the 10-K, the quarterly view returns {"groups":[]}. Balance-date shares such as a receivables mix do appear as Q4 when a filer tags them.
• Dollar amounts are optional. When a filer also tags the revenue amount for a counterparty and period, it is attached to the point as revenue, converted with the currency parameter. Most filers tag only the percentage.

/api/footnotes/concentration is on the Professional (Pro) plan ($99/month, or $69/month billed annually), and its limit parameter accepts up to 80 points per series. For the rest of the revenue picture, /api/footnotes/revenue-segmentation splits revenue by geography and product, as our post on the revenue segmentation API shows, and /api/footnotes/business-segmentation returns revenue and operating income by reportable segment. Get a free API key to start with the financial statement endpoints, which are on every plan.

StockFit provides data, not investment advice. Nothing here is a recommendation to buy or sell any security.

FAQ