Sector & Industry-Specific Metrics: StockFit API vs. financialmodelingprep.com

A bank does not report a gross margin. An insurance company does not have inventory to turn over. A REIT's GAAP earnings-per-share understates the cash it actually generates — the industry compares REITs on FFO/share instead. Most general-purpose financial-data APIs return a single, identically-shaped key-metrics response for every company in the universe, and the mismatch shows up as null in the rows that matter most.

This post compares how StockFit and financialmodelingprep.com (FMP) handle sector- and industry-specific metrics. Every StockFit response below is a real, just-pulled call against our production API. Every FMP claim links back to their published documentation; where their docs don't cover something, we say so rather than guess.

The problem with one-shape-fits-all metrics

Run this thought experiment. You write a Node.js screen that ranks the entire S&P 500 by grossMargin using whatever financial-data API you have. You expect 500 rows. Instead you get ~430. The missing 70 are the banks, insurers, and REITs — the financial sector and real estate are 30% of the index by count, and they all return null for gross margin. Same for current ratio, inventory turnover, days sales outstanding, and most balance-sheet leverage metrics designed for industrial companies.

That isn't a bug in the data. JPMorgan's 10-K doesn't report a cost-of-revenue line because banks don't sell goods — they take deposits and make loans. The right operating metric for a bank is net interest margin, the spread between interest earned on assets and interest paid on liabilities. But if your API returns the same set of fields for a bank as for a software company, you never see it.

Below is a real call against StockFit's key-metrics endpoint for JPMorgan (JPM). The general-purpose ratios mostly come back null — banks don't use them — but the sector-specific tier returns the metrics that actually matter for a bank:

{
  "period":     "2025-12-31",
  "sector":     "Finance/Insurance/Real Estate",
  "sectorId":   "banking",
  "industry":   "National Commercial Banks",
  "general": {
    "revenue":          182447000000,
    "netIncome":         57048000000,
    "grossMargin":       null,            // banks don't report cost-of-revenue (interest expense lives in a different framework)
    "currentRatio":      null,            // banks present an unclassified balance sheet under ASC 942
    "inventoryTurnover": null,            // banks carry trading securities and loans, not merchandise inventory
    "roa":               1.354,
    "roe":              16.134,
    "eps":              20.05
    // ... ~30 more general fields
  },
  "sectorMetrics": {
    "netInterestIncome":  28032000000,
    "interestIncome":     28032000000,
    "nim":                  0.665,        // net interest margin %
    "loanToDeposit":        0.573,
    "efficiencyRatio":     83.139,
    "provisionToLoans":     1.018
  },
  "industryMetrics": {}
}

That's the actual response shape: three tiers stacked in the same JSON. general for the metrics every company has, sectorMetrics for the ones tied to the company's broad business model, and industryMetrics for granular industry KPIs (more on that below).

The three-tier metric model

/api/financials/key-metrics classifies every company by SIC code into a sector and (for specialized industries) an industry. Three layers of metrics get computed and returned in a single response:

Sectors with dedicated metric sets

Mapped from SIC codes. Every sector below has a complete sectorMetrics implementation in our codebase that we've verified end-to-end against real filings:

Industries with extra granular metrics

Layered on top of the sector tier when the company maps to a specialized industry. A semiconductor company gets manufacturing's sectorMetrics plus semiconductor's industryMetrics:

How it's calculated

Three pieces fit together:

1. SIC → sector and industry classification. Every company filed with the SEC has a SIC code in their submissions metadata. We map ranges to sector IDs (banking, insurance, REIT, etc.) and prefix-match a smaller set of high-value SIC codes to industry IDs (semiconductor, software, pharma, etc.). The classifier is deterministic and inspectable — it's a pure function in shared/src/utils/sector.ts.
2. Per-fact applicability tagging. Each curated fact in our catalogue is annotated with the sectors/industries it applies to. premiumsEarned is tagged [insurance]; noninterestIncome is tagged [banking]; provisionForCreditLosses is tagged [banking]. This drives both fact mapping during ingest and the optional includeMissingFacts flag on /api/financials/income-statement — you only get N/A keys for facts your company's sector actually uses.
3. Per-sector metric formulas. Each sector has a registered “view” with a list of metric definitions. A view's formula references curated fact names (netIncome, operatingCashFlow, capitalExpenditure, etc.) and produces a numeric output. For a REIT, the FFO formula is netIncome + D&A; for a bank, NIM is netInterestIncome / averageLoans. The formulas are visible in the codebase under shared/src/types/performance-views.ts.

Real responses across business models

To make this concrete, here's what the same endpoint returns for four very different companies. Every value below is a live API response, just-pulled.

Insurance: Progressive (PGR)

{
  "period":     "2025-12-31",
  "sector":     "Finance/Insurance/Real Estate",
  "sectorId":   "insurance",
  "industry":   "Direct Property and Casualty Insurance Carriers",
  "general":    { "revenue": 87671000000, "netIncome": 11308000000, "eps": 19.29, "...": "..." },
  "sectorMetrics": {
    "lossRatio":         53.04,           // claims / earned premiums
    "expenseRatio":       7.47,           // underwriting opex / earned premiums
    "combinedRatio":     60.50,           // < 100% = underwriting profit
    "underwritingIncome": 32255000000,
    "investmentIncome":    3549000000,
    "premiumGrowth":      15.34,          // YoY
    "floatYield":          4.00,          // investment income / float
    "floatSize":         43310000000,     // investable capital between premium and claim
    "dacRatio":            2.50,
    "reserveRatio":        0.53,
    "bookValueGrowth":    18.49
  },
  "industryMetrics": {}
}

A combined ratio of 60.5% means Progressive is making 39.5 cents of underwriting profit on every premium dollar — before they even invest the float. That's why PGR has compounded book value at 18%/year. None of this would be visible from a generic key-metrics shape that only returns ROE and debt/equity.

REIT: Prologis (PLD)

{
  "period":     "2025-12-31",
  "sector":     "Finance/Insurance/Real Estate",
  "sectorId":   "reit",
  "industry":   "Real Estate Investment Trusts",
  "general":    { "revenue": 8790127000, "netIncome": 3328231000, "eps": 3.58, "...": "..." },
  "sectorMetrics": {
    "ffo":              5954259000,       // FFO = Net Income + D&A
    "affo":             5954259000,       // AFFO = FFO + capex (capex null here)
    "ffoPerShare":            6.41,       // REIT-equivalent of EPS
    "payoutRatio":          63.23,        // dividends / FFO (REITs must pay 90%+ of taxable income)
    "debtToAssets":         36.04,
    "interestCoverage":      4.35
  },
  "industryMetrics": {}
}

PLD's GAAP EPS of $3.58 dramatically understates cash generation because of $2.6B in real-estate D&A that isn't a real cash cost. FFO/share of $6.41 is the right figure to compare across REITs. AMT, EQIX, CCI, SPG, AVB, and the rest of the major US REIT universe all return the same set of fields.

Semiconductor: NVIDIA (NVDA) — sector + industry tiers

{
  "period":     "2026-01-31",
  "sector":     "Manufacturing",
  "sectorId":   "manufacturing",
  "industry":   "Semiconductor and Related Device Mfg.",
  "industryId": "semiconductor",
  "general":    { "revenue": 215938000000, "netIncome": 120067000000, "eps": 4.93, "...": "..." },
  "sectorMetrics": {
    "inventoryTurnover":     3.97,
    "daysInventory":        91.97,
    "grossMargin":          71.07,
    "operatingMargin":      60.38,
    "dso":                  52.00,
    "dpo":                  47.10,
    "ccc":                  96.87,        // cash conversion cycle, days
    "capexRevenue":          5.92,
    "capexDepreciation":     4.50,
    "assetTurnover":         1.36
  },
  "industryMetrics": {
    "rdToRevenue":           8.57,        // % of revenue spent on R&D
    "sbcToRevenue":          2.96,        // stock-based comp as % revenue
    "fcfConversion":         0.75,        // free cash flow / net income
    "fcfMargin":            41.65
  }
}

Notice both tiers populated. sectorMetrics handles the “NVIDIA-as-manufacturer” lens (working capital, capex). industryMetrics adds the semi-specific signals (R&D intensity, SBC, FCF conversion). Generic key-metrics endpoints typically expose neither.

Comparison: StockFit vs financialmodelingprep.com

What we know about FMP comes from their public docs. They have well-documented endpoints for general key metrics and ratios; we couldn't find public documentation for sector-specific endpoints (NIM for banks, combined ratio for insurers, FFO for REITs). If they exist and we missed them, please point us at the URL.

What problems this solves

1. Bank-only quality screen

You want to rank US banks by “quality”: high NIM, low efficiency ratio, low provision/loans. With a generic API you'd have to compute these yourself by reverse-engineering the income statement. With StockFit you fetch key-metrics and read sectorMetrics.nim, sectorMetrics.efficiencyRatio, sectorMetrics.provisionToLoans directly.

2. Insurance underwriting screen

P&C insurers are profitable iff combined ratio is below 100%. Sort by trailing combined ratio, exclude any insurer above 100%, rank by float yield. Three reads from one API call per company.

3. REIT comparable-company analysis

Comparing REITs on EPS is wrong because of large non-cash D&A on real estate. Compare on ffoPerShare and payoutRatio. The full US REIT universe (~190 companies in our data) is comparable on these fields out of the box.

4. Software-business cohort tracking

For SaaS-style businesses, pull industryMetrics.deferredRevenueGrowth as a forward-demand signal alongside trailing industryMetrics.billings. These don't exist for non-software companies and aren't in a generic ratios endpoint.

Tutorial: build a sector-aware screen in Node.js

The example below pulls a small universe, fetches sector-aware key metrics for each, and produces three separate ranked lists: best banks by efficiency, best insurers by combined ratio, best REITs by FFO yield. About 60 lines.

Step 1 — auth boilerplate

# Get a free API key (no credit card)
open https://developer.stockfit.io/signup
export STOCKFIT_KEY="your_token"

Step 2 — the screen

const KEY = process.env.STOCKFIT_KEY;
const BASE = 'https://api.stockfit.io/v1/api';
const headers = { Authorization: `Bearer ${KEY}` };

const get = async (path, params = {}) => {
  const url = new URL(BASE + path);
  for (const [k, v] of Object.entries(params)) url.searchParams.set(k, v);
  const r = await fetch(url, { headers });
  if (!r.ok) throw new Error(`${r.status} ${url}`);
  return r.json();
};

// Pull most recent annual key-metrics for one symbol
async function metrics(symbol) {
  const rows = await get('/financials/key-metrics', {
    symbol, period: 'annual', limit: 1,
  });
  return rows[0]; // { period, sector, sectorId, industry, industryId, general, sectorMetrics, industryMetrics }
}

const universe = [
  // Banks
  'JPM', 'BAC', 'WFC', 'C', 'GS', 'MS', 'USB', 'PNC', 'TFC', 'COF',
  // Insurers
  'PGR', 'TRV', 'ALL', 'AIG', 'CB', 'HIG', 'WRB', 'CINF', 'AFG', 'MKL',
  // REITs
  'PLD', 'AMT', 'EQIX', 'WELL', 'CCI', 'SPG', 'O', 'AVB', 'EQR', 'PSA',
];

const data = await Promise.all(universe.map(async s => {
  try { return { symbol: s, ...(await metrics(s)) }; }
  catch (e) { return { symbol: s, error: e.message }; }
}));

// Helper: real-world filter — values must be present and within sensible bounds
const within = (v, lo, hi) => v != null && v >= lo && v <= hi;

// 1. Banks by efficiency ratio (lower is better; sensible band 30–90%)
const banks = data
  .filter(d => d.sectorId === 'banking' && within(d.sectorMetrics?.efficiencyRatio, 30, 90))
  .sort((a, b) => a.sectorMetrics.efficiencyRatio - b.sectorMetrics.efficiencyRatio)
  .slice(0, 5)
  .map(d => ({
    symbol: d.symbol,
    nim: d.sectorMetrics.nim?.toFixed(2),
    efficiency: d.sectorMetrics.efficiencyRatio?.toFixed(1),
    loanToDeposit: d.sectorMetrics.loanToDeposit?.toFixed(2),
  }));
console.log('\nTop banks by efficiency ratio:');
console.table(banks);

// 2. Insurers by combined ratio (sensible band 40–110%; below 100% = underwriting profit)
const insurers = data
  .filter(d => d.sectorId === 'insurance' && within(d.sectorMetrics?.combinedRatio, 40, 110))
  .sort((a, b) => a.sectorMetrics.combinedRatio - b.sectorMetrics.combinedRatio)
  .slice(0, 5)
  .map(d => ({
    symbol: d.symbol,
    combined: d.sectorMetrics.combinedRatio?.toFixed(2),
    loss: d.sectorMetrics.lossRatio?.toFixed(2),
    floatYield: d.sectorMetrics.floatYield?.toFixed(2),
  }));
console.log('\nTop insurers by combined ratio:');
console.table(insurers);

// 3. REITs by payout ratio (sensible band 50–110%; lowest = most retained for growth)
const reits = data
  .filter(d => d.sectorId === 'reit'
    && d.sectorMetrics?.ffoPerShare != null
    && within(d.sectorMetrics?.payoutRatio, 50, 110))
  .sort((a, b) => a.sectorMetrics.payoutRatio - b.sectorMetrics.payoutRatio)
  .slice(0, 5)
  .map(d => ({
    symbol: d.symbol,
    ffoPerShare: d.sectorMetrics.ffoPerShare?.toFixed(2),
    payoutRatio: d.sectorMetrics.payoutRatio?.toFixed(1),
    debtToAssets: d.sectorMetrics.debtToAssets?.toFixed(1),
  }));
console.log('\nTop REITs by retained-FFO (lowest payout):');
console.table(reits);

The within(v, lo, hi) helper exists for one reason: real-world data has gaps and edge cases. A small subset of XBRL filings tag concepts in unusual ways, leading to nonsensical computed values for some companies. Filter for sensible bands as a hygiene step — it's good practice with any fundamentals API regardless of provider.

Step 3 — run it

node screen.mjs

Actual output from running the snippet against our production API (your numbers will reflect whichever fiscal years are most recent at the time you run):

Top banks by efficiency ratio

Top insurers by combined ratio

Top REITs by retained-FFO (lowest payout)

Each table is ranked by the metric that actually matters for that business model. With a generic API you'd have to compute NIM, combined ratio, and FFO yourself from raw line items. Here it's three field reads. Note: not every company in the universe survives the sanity-band filter — that's the data quality reality of working with XBRL filings, and a key reason to apply hygiene filters before ranking.

Closing thought

Generic financial-data APIs solve the easy 70% of the universe (industrials, software, consumer) and silently fail on the other 30% (banks, insurers, REITs, specialty industries). StockFit's key-metrics endpoint returns three layered tiers so the right metric for the right business model is one field-read away — no per-issuer if-statements, no manual calculations from raw XBRL.

Run it yourself:

1. Try the playground — no signup needed.
2. Get a free API key and run the screen above.
3. For AI workflows, point your MCP-capable client at our MCP server — same key works.

More technical writing on the developer blog; live examples in Insights. Full API reference at api.stockfit.io/docs. Caught a fact wrong about FMP? info@stockfit.io and we'll update.