All Posts
ComparisonComparisonXBRLSEC APIInsider Trading

StockFit API vs. sec-api.io for Financial Data Conversion

How the two products approach XBRL-to-JSON conversion, insider trading data, and developer ergonomics. Verified facts on both sides, no vendor spin.

Published April 22, 202612 min readStockFit Engineering

If you're building anything that consumes US public-company financial data, you've probably narrowed your shortlist to a handful of providers that work directly off SEC EDGAR. sec-api.io and StockFit are two of them. They overlap in places and diverge sharply in others, and the right choice depends entirely on what you're building.

This post is a deliberately even-handed comparison. Every StockFit claim below is grounded in a live API response or a specific source file in our codebase — you can verify any of them against our live playground or the Swagger docs. Every sec-api.io claim is quoted from their public documentation (sources at the top), and where we don't know something about how they work, we say so rather than guess.

Sources we used for this comparison
sec-api.io: their product page, pricing page, XBRL-to-JSON converter docs, and insider trading docs. StockFit: live calls against api.stockfit.io with a real API key, plus the codebase. If anything below is out of date, please tell us.

The fundamental positioning difference

Both products read SEC EDGAR and emit JSON. What they consider their job to be is different.

sec-api.io positions itself as a comprehensive SEC platform: “Access and analyze all 20 million SEC EDGAR filings” with full-text search, real-time websocket streaming, 500+ form-type APIs, PDF/Excel rendering, and a dedicated XBRL converter that parses on demand. The product is designed for breadth: every form type the SEC publishes, queryable in many ways.

StockFit is narrower and more opinionated. The brief is “accurate fundamentals and ETF data, ready for analysis” — financials, earnings, ownership, executives, ETF holdings, and AI-classified business model analytics. We pre-parse and pre-classify every filing into a queryable database so that consumers receive curated, fiscal-year-aware JSON without having to re-run a converter per request.

Neither posture is universally correct. If you need to stream Form ABS-EE filings or render any 8-K to PDF, sec-api.io is the better fit. If you need a normalized ten-year quarterly income statement for a backtest, StockFit is.

XBRL → JSON: two design choices

Both products convert XBRL to JSON, but they make opposite choices about what to do with the underlying concept names. This is the single most important difference for anyone building financial analytics on top.

sec-api.io: preserve concept names

Their XBRL-to-JSON Converter standardizes the structure but explicitly preserves the original taxonomy concept names. From their docs (verbatim): “GAAP items are not renamed to its parent name.” The us-gaap_ prefix is stripped (so us-gaap_SalesRevenueGoodsNet becomes SalesRevenueGoodsNet), but otherwise you receive the concepts the company chose to file.

That means if Tesla files revenue under tsla:AutomotiveSalesRevenue + tsla:ServicesAndOtherRevenue while Apple uses RevenueFromContractWithCustomerExcludingAssessedTax, your code has to know about both. You receive faithful structured XBRL — which is what you want for forensic accounting, restatement analysis, or any strategy that depends on the exact line item the issuer reported.

StockFit: a curated layer on top of as-reported

We expose both views. /api/financials/as-reported returns the raw XBRL fact set with original concept names — same posture as sec-api.io's converter. Below is a real, just-pulled response for AAPL Q1 FY2026:

json
[
  {
    "period": "2025-12-26",
    "facts": {
      "us-gaap:RevenueFromContractWithCustomerExcludingAssessedTax": 143756000000,
      "us-gaap:CostOfGoodsAndServicesSold":                            74525000000,
      "us-gaap:GrossProfit":                                            69231000000,
      "us-gaap:OperatingIncomeLoss":                                    50852000000,
      "us-gaap:NetIncomeLoss":                                          42097000000,
      "aapl:CashCashEquivalentsAndMarketableSecurities":               144795000000
      // ... 103 more concept facts in the real response (109 total for this period)
    }
  }
]

Then /api/financials/income-statement returns the same numbers under stable canonical field names — a per-company mapping translates each issuer's tags into a single vocabulary so your code can iterate across the entire universe without per-issuer special-casing:

json
[
  {
    "period": "2025-12-26",
    "facts": {
      "revenue":         143756000000,
      "costOfRevenue":    74525000000,
      "grossProfit":      69231000000,
      "operatingIncome":  50852000000,
      "netIncome":        42097000000,
      "eps":              2.85,
      "ebitda":           54066000000
      // ... ~20 more curated fields per period (operating expenses, share counts, EBIT, etc.)
    }
  }
]

On top of the curated layer we apply fiscal-year-aware period classification and read-time Q4 reconstruction (Q4 isn't reported on the 10-K; it's derived from FY - 9M with fallbacks to FY - H1 - Q3 and FY - Q1 - Q2 - Q3). For non-December fiscal year companies (Apple ends late September; Costco late August) the alignment happens server-side. You can read the full mechanics in our previous post: Converting XBRL Financials to JSON for Backtesting.

What we don't know about sec-api.io
Their public docs describe the converter's output structure and concept handling but don't state how (or whether) they handle Q4 reconstruction, non-December fiscal calendars, or 52/53-week alignment. We aren't going to claim they don't — we don't know. If you're evaluating both, asking each provider to return a discrete Q4 income statement for a 52/53-week filer like Apple is a useful concrete test.

Insider trading: forms covered and deduplication

Insider trading data on EDGAR comes from Forms 3 (initial ownership), 4 (transaction reports), and 5 (annual catch-up). Both products parse all three at the ingest layer, but they expose them slightly differently.

sec-api.io

Their Insider Trading Data API covers “all insider trades reported in SEC form 3, 4, and 5” and amended versions, with coverage from 2009 to present. They report new transactions are indexed within an “average of 300 milliseconds” after publication. Queries use Lucene syntax with up to 50 transactions per request and pagination via a from offset.

StockFit

/api/insider-transactions returns Form 4 and Form 5 transactions (Form 3 is initial-ownership holdings, not transactions, so it's separate). What it adds on top of raw parsing:

  • Cross-filer deduplication. When several insiders co-own the same shares (e.g. an executive and a family trust), each physical trade gets reported on multiple Form 4s. The endpoint deduplicates by (transaction_date, security, code, shares, price, direction) and keeps the most senior filer (officer > director > 10% owner). You can verify the SQL in our codebase.
  • Form 5 deduplication against Form 4. Form 5 sometimes restates transactions already reported on a Form 4 earlier in the year. The query suppresses those duplicates.
  • Built-in filters. filter=significant returns only open-market purchases (P) and sales (S), excluding option exercises and grants. filter=voluntary-sells excludes sales paired with same-filing exercises (i.e. compensation liquidation, not a discretionary sale).

Below is a real response for AAPL with filter=significant:

json
{
  "page": 1, "pageSize": 3, "totalPages": 54, "totalResults": 161,
  "data": [
    {
      "ownerName":          "KONDO CHRIS",
      "ownerCik":           1631982,
      "isOfficer":          true,
      "officerTitle":       "Principal Accounting Officer",
      "documentType":       "4",
      "securityTitle":      "Common Stock",
      "transactionDate":    "2025-11-07",
      "transactionCode":    "S",
      "shares":             3752,
      "pricePerShare":      271.23,
      "acquiredDisposed":   "D",
      "sharesAfter":        15098,
      "directIndirect":     "D",
      "isDerivative":       false,
      "accessionNumber":    "0001631982-25-000011",
      "filingUrl":          "https://www.sec.gov/Archives/edgar/data/.../wk-form4_1762990206.xml",
      "transactionValue":   1017654.96,
      "filingDate":         "2025-11-12 00:00:00"
    }
  ]
}

For aggregates, /api/insider-transactions/summary returns rolling 3, 6, and 12-month buy/sell counts, share volumes, dollar values, net shares, and unique buyer/seller counts in a single call. Useful for screens like “companies with multiple insider buys in the last quarter”. For per-insider history use /api/insider-transactions/by-insider, and for the full set of officers/directors per company use /api/insider-transactions/roster.

Coverage window — be honest
sec-api.io publishes 2009 as their insider-trading coverage start, which is broader than ours. StockFit ingests Form 4/5 on a trailing 5-year rolling window by design — currently ~2021 to present, with full density. The rationale: most insider-trading-as-signal strategies look at the recent past, not the deep past. The cutoff is a single config knob in our ingest pipeline, not a parser limitation: we can extend the window to a longer history (or run a one-off historical backfill) when there's real demand. If your use case needs pre-2021 insider data today, sec-api.io is the better choice; if it would be useful but not blocking, tell us — that's how we prioritize what to backfill next.

JSON output speed: what we can actually measure

“Fast” is the most overloaded word in API marketing. There are two distinct kinds of latency that matter here, and they have very different answers.

1. Per-request response time for financials

sec-api.io's converter description says it converts XBRL to JSON “in seconds” — that's their public marketing claim. They likely cache results, but we can't verify that from public docs.

StockFit's curated and as-reported endpoints serve from a pre-parsed columnar store (DuckDB). There is no per-request XBRL parse. Below are real server-side processing times from our production logs (the time the API spent computing the response, not including network round-trip to the client):

text
income-statement   (curated, 40 quarters):  cold 138ms     cached 14–29ms
balance-sheet      (curated, 4 quarters):   cold 138ms     cached  ~15ms
cash-flow          (curated, 4 quarters):   cold 167ms     cached  ~15ms
filings            (10-Q list, page=20):    cold 103ms     cached  ~15ms
insider-tx         (50 txns, deduped):      cold 716ms     cached  ~15ms
as-reported        (raw XBRL, 40 quarters): cold 1992ms    cached  ~45ms

Cached responses (the common case for any popular symbol) come back in 15–45ms server-side. Cold responses for curated endpoints are typically 100–170ms; the only outliers are as-reported (cold ~2s — it's pulling 100+ raw XBRL concept facts per period across 40 periods) and insider-transactions with deduplication (cold ~700ms — the cross-filer dedup SQL is non-trivial). Add typical network RTT for your real wall-clock latency (e.g. ~60–80ms cross-country in the US, sub-millisecond if you're in us-east-2). The API is in Ohio.

How to reproduce yourself:

bash
curl -H "Authorization: Bearer $KEY" \
  "https://api.stockfit.io/v1/api/financials/income-statement?\
symbol=AAPL&period=quarter&limit=40" \
  -o /dev/null -w "%{time_total}s\n"

2. Time from filing acceptance to data availability

sec-api.io publishes a strong number for new filings: insider transactions “available within an average of 300 milliseconds” via their websocket stream, and N-PORT in under 300ms. If you need to act on filings the moment they hit EDGAR, that's their lane.

StockFit doesn't offer a websocket stream today. Our incremental ingester runs on a schedule and most filings show up within hours of acceptance, which is the right fit for analytical and backtesting workflows but not for real-time event-driven trading.

CapabilityStockFit APIsec-api.io
Streaming/realtimeNot offered today.Websocket stream. Insider tx and N-PORT cited as “under 300ms”.
Per-request curated financialsServer-side: ~14–30ms cached, 100–170ms cold (40 quarters). Add network RTT.Public claim is “in seconds” for XBRL conversion. Per-request latency under load not published.

Pricing

Pricing is the easiest dimension to compare because both publish their tiers. Numbers below are from the providers' pricing pages as of writing.

CapabilityStockFit APIsec-api.io
Free tierFree plan, no credit card. Includes financials, filings, ownership basics; rate-limited. Sign up at /signup.100 API calls (one-time), per their pricing page.
Entry paid plan$15/mo Starter for prototypes and side projects.$49/mo annual or $55/mo monthly (Personal & Startups).
Mid plan$39/mo Stock or ETF — pick one focus area.$199/mo annual or $239/mo monthly (Business Internal Use).
Top published plan$69/mo Professional — all endpoints.Enterprise: contact sales.
AI / MCP integrationNative MCP server. Same API key works for REST and for Claude/Cursor/VS Code as AI tools.Not advertised on the pricing or product page as of writing.

StockFit's pricing is structured around access tiers (Free, Starter, Stock, ETF, Pro — full breakdown on the pricing page). sec-api.io's is structured around request-rate caps. Different mental models — neither is wrong.

When sec-api.io is the better fit

Based on what each product publishes about itself, sec-api.io is the better choice when:

  • You need real-time event-driven workflows (websocket streaming).
  • You need full-text search across the body of EDGAR filings since 2001.
  • You need long-tail form types like Form ADV, Form 144, Form D, ABS-EE, NCSR — anything beyond mainstream financials and ownership.
  • You want PDF / Word / Excel / Google Sheets rendering of filings.
  • You want the raw XBRL preserved verbatim with original concept names and don't need a curated mapping layer.

When StockFit is the better fit

  • You're building screens, factor models, or backtests over US stock fundamentals and want canonical field names that work across the entire universe without per-issuer special-casing — see our backtesting walk-through.
  • You need discrete Q4 income statements reconstructed correctly from FY and Q3 cumulative facts — the /api/financials/income-statement endpoint does this server-side.
  • You're working with non-December fiscal year companies and want the API to handle alignment.
  • You need deduplicated insider transactions across co-owners with sensible filters — /api/insider-transactions with filter=significant, voluntary-sells, or executives.
  • You want ETF-specific analytics beyond holdings: holdings, overlap, fee analysis, AI-classified exposure models, and fund flows. Real example: our ARKK deep dive was built entirely on these endpoints.
  • You want an AI-native developer experience: connect once via our MCP integration and the same API key becomes an AI tool inside Claude, Cursor, or VS Code.
  • You want a lower entry price — see /pricing.

Closing thought

These products solve overlapping but distinct problems. The honest version of this comparison: pick sec-api.io when the value is in the breadth of EDGAR coverage and real-time streaming; pick StockFit when the value is in pre-curated, fiscal-year-aware fundamentals and ETF analytics that you can query without writing a normalization layer.

Run the comparison yourself in three steps:

  1. Try the live playground — no signup needed.
  2. Get a free API key (no credit card) and hit every endpoint mentioned above.
  3. For AI workflows, point your client at our MCP server.

Full API reference: api.stockfit.io/docs. More technical writing on the developer blog; live examples in Insights. If we've got a fact wrong about sec-api.io and you can point us at where their docs say otherwise, drop us a note at info@stockfit.io and we'll update the post.

Ready to build?

Free API key, no credit card. Every endpoint mentioned in this post is available on the free tier.

Get Your Free API Key