13F Holdings API: Query Funds, Stocks, Quarters

Name: Arkolith
Brand: Arkolith

The short version

A 13F holdings API lets you query institutional ownership from SEC Form 13F filings by fund, stock, quarter, or point-in-time date. The filings are public, but a useful API adds the hard parts: parsing EDGAR, resolving CUSIPs to tickers, handling amendments, computing quarter changes, and keeping every row tied to the source filing. Use it when you need repeatable ownership research, agent workflows, or a first call such as "which funds own NVDA?"

What is a 13F holdings API?

A 13F holdings API is a structured data layer over SEC Form 13F. Instead of downloading filings one by one from EDGAR, you call an endpoint or MCP tool and ask for a manager's holdings, a stock's owners, a quarter's changes, or the portfolio view known on a past date.

The primary source is still the SEC. The SEC Form 13F FAQ says Form 13F is filed by institutional investment managers under Section 13(f), and that managers with investment discretion over at least $100 million in Section 13(f) securities must file. The Form 13F instructions define the report itself.

The API product is the processing around those filings. A serious 13F API should answer four questions without manual cleanup: who filed, what securities were reported, what changed from the prior comparable filing, and which source filing proves each row.

What Form 13F shows and what it misses

Form 13F is useful because it is one of the few broad public views of institutional U.S. equity ownership. It is also narrow. It is a quarterly, lagged disclosure of reportable long positions. It is not a live portfolio, a short-position feed, a cash book, or a full hedge-fund risk model.

Need	Form 13F can support it?	API requirement
Who owns a stock	Yes, after resolving reported securities	Ticker, CUSIP, issuer, and filer resolution
What a manager reported	Yes	Fund or manager lookup by CIK and filing period
What changed quarter to quarter	Derived, not directly filed	Comparable filing selection and share-based diffs
What was known on a past date	Derived from filing acceptance times	Point-in-time query semantics
Short exposure or swaps	No	Clear limitation, not an invented field

If the API does not surface those limits, it will make confident but wrong research easy. For the filing-level mechanics, start with how to read a 13F filing and 13F vs 13D vs 13G vs Form 4.

Why raw EDGAR is not enough for agents

Raw EDGAR is the legal source and should remain the audit trail. The SEC's EDGAR search is the right place to inspect filings directly. But an agent or backend needs more than a filing page.

First, securities arrive as filing rows, not as clean current tickers. You need identifier resolution, which is why CUSIP mapping and entity resolution matter. Second, amendments can replace or add to prior filings, so a simple "latest file wins" rule is unsafe. Third, the signal is usually the delta, not the snapshot: new, added, reduced, held, and exited positions require comparable-quarter logic.

The fourth problem is provenance. If an AI agent says "Fund X owned NVDA," the next question is "according to which filing?" A 13F API for serious work should preserve filing accession, accepted date, period, filer identity, and row-level source context so a human can inspect the claim later.

The first workflow: ask who owns a stock

The fastest way to test a 13F API is not a large integration. It is one ownership question. Pick a stock, ask who owns it, then drill into one holder and one source filing.

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://arkolith.com/api/v1/stocks/NVDA"

Then resolve a manager and pull its holdings:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://arkolith.com/api/v1/search?q=berkshire"

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://arkolith.com/api/v1/funds/1067983/holdings"

The same workflow has a human page and a Build path. Open NVDA owners, browse the 13F data layer, then connect the API through the quickstart. The point is to make the first useful call before debating a bigger architecture.

REST versus MCP for 13F data

REST is the right interface when your code controls the workflow: dashboards, notebooks, scheduled jobs, and internal tools. MCP is better when the agent should decide which lookup to run. The Model Context Protocol docs describe MCP as an open standard that connects AI applications to external systems, including data sources and tools.

For Arkolith, both surfaces use the same underlying ownership spine. REST gives you predictable endpoints. MCP gives Claude, Codex, or another client a tool surface for questions like:

Use Arkolith to show which funds own NVDA,
which funds added it last quarter,
and link each claim to the source filing.

That is the practical line between content and product. The article explains the dataset. The API or MCP call proves whether the data helps your actual workflow. Start at /connect if you want a key, or compare fit against other providers in the 13F holdings API comparison.

What to require before you trust a vendor

Use this checklist before you buy or build:

Requirement	Why it matters
Filer identity by CIK	Names change and brands split across legal entities
Security resolution	Raw filings use identifiers that are not enough for ticker workflows
Amendment handling	13F/A filings can change the quarter's best current view
Share-based diffs	Dollar changes mix trading decisions with price movement
Point-in-time reads	Backtests should not see a filing before EDGAR accepted it
Row provenance	Agents and analysts need a filing to cite
Clear limits	No shorts, cash, swaps, or live positions should be implied

Arkolith's lane is the ownership cluster: funds, institutional investors, stock-owner pages, REST, MCP, and filing provenance in one model. Broad market-data vendors can be better when you need prices, fundamentals, estimates, options chains, or a terminal UI. EDGAR direct is best when you only need the source document.

How this connects to pricing and activation

The best commercial test is a free, specific workflow. Do not start by pricing the whole dataset. Start by asking one question your team already cares about: who owns a stock, what changed last quarter, and what filing proves it?

If that call is useful, the next step is a repeatable job: screen a watchlist, rebuild a portfolio view, or let an agent draft a sourced ownership note. The stock-owner workflow is built for that path. Pricing only matters after the first useful answer exists, which is why Arkolith keeps the first key path low-friction through /connect and publishes plan detail on pricing.

This article explains public filings and data infrastructure. It is not investment advice, legal advice, tax advice, or a recommendation to trade any security.

Frequently asked questions about 13F holdings APIs

Is 13F data real-time?

No. Form 13F is a quarterly filing, generally due within 45 days after quarter end. A 13F API should make the lag visible and should never market the feed as live positions.

Does a 13F API show shorts?

No. Form 13F is primarily a long-position disclosure for reportable securities. Short positions, cash, swaps, and most non-U.S. assets are outside the filing, so an API should not imply complete portfolio exposure.

Why use an API instead of SEC EDGAR?

Use EDGAR when you need the primary filing. Use an API when you need parsing, identifier resolution, amendment handling, quarter diffs, point-in-time reads, and source links inside a repeatable workflow.

What is the best first API call?

Ask who owns one stock, then verify one row against the source filing. That single workflow tests resolution, provenance, latency, and whether the answer is useful enough to automate.

How does MCP change 13F research?

MCP lets an AI client call a data tool instead of guessing from memory. For 13F research, that means the agent can fetch ownership rows, compare quarters, and cite filings directly.