The SEC EDGAR API rate limit in 2026 is 10 requests per second per requester, the same fair-access ceiling in force since July 2021, and the only hard requirement beyond it is a descriptive User-Agent header on every request. The data.sec.gov REST APIs (submissions, company facts, company concept, frames) and the EFTS full-text search are free, with no API key, no registration, and no paid tier. Exceed 10 req/s and the SEC may limit further requests from your IP for a brief period; it publishes no block duration. For an LLM filing pipeline this is plenty for ingestion but means you build the throttle, not the vendor. Model the call budget with the Finance MCP Directory read-only servers that wrap EDGAR.
TL;DR
| Fact | Verified value |
|---|---|
| Rate limit | 10 requests/second per requester |
| Auth | None, no API key, no registration |
| Required header | User-Agent identifying you (name + email) |
| Cost | Free for all endpoints |
| Endpoints | submissions, companyfacts, companyconcept, frames, full-text search |
| Over-limit penalty | further requests from the IP limited for a brief period (no duration published) |
The rate limit and the User-Agent requirement are the two facts that break most first pipelines. Everything else is a question of which endpoint answers your query.
The 10 requests/second fair-access limit
The SEC limits each requester to no more than 10 requests per second, "regardless of the number of machines used to submit requests."1 The policy has been in place since July 27, 2021, when the SEC began rate-controlling automated access to EDGAR. It is a fair-access rule, not a tiered quota: there is no paid tier that lifts it, and no key that exempts you.
In practice, a request loop with a sleep(0.1) between calls keeps you under the line. Production pipelines target 8 req/s to leave headroom for jitter and retries. Exceed it and the SEC "may limit further requests from the relevant IP address(es) for a brief period"; access resumes once your rate drops back under the threshold. The SEC publishes no block duration, so build backoff that waits and retries rather than assuming a fixed lockout.2
For a batch filing-ingestion job, 8 req/s is roughly 28,800 requests/hour. A full-text search sweep plus targeted submissions and company-facts pulls for a few thousand tickers fits comfortably inside an overnight window at that rate.
The User-Agent requirement
The single mandatory header is User-Agent. The SEC requires automated tools to declare a descriptive User-Agent string identifying the requester; the documented format is a name and contact email, for example Sample Company [email protected].1 A missing or empty User-Agent is the most common cause of a 403 on an otherwise valid request: it is not the rate limit biting, it is the identification requirement.
The bare default User-Agent that urllib, requests, or a stock HTTP client sends is treated as an unclassified bot. Set the header explicitly on every request.
The endpoints that matter for an LLM pipeline
All structured EDGAR data is served from https://data.sec.gov/. The older full-text search runs separately on efts.sec.gov.3
| Endpoint | Path shape | Returns |
|---|---|---|
| Submissions | /submissions/CIK{10-digit}.json |
Filing history + metadata for a company |
| Company Facts | /api/xbrl/companyfacts/CIK{10-digit}.json |
All XBRL facts a company has reported |
| Company Concept | /api/xbrl/companyconcept/CIK{10-digit}/us-gaap/{Concept}.json |
One concept (e.g. Revenues) across periods |
| Frames | /api/xbrl/frames/us-gaap/{Concept}/{Unit}/CY{Year}.json |
One concept across all companies for a period |
| Full-text search | efts.sec.gov query API |
Keyword search across filing bodies |
The CIK in the path is zero-padded to 10 digits. Company Facts is the workhorse for fundamentals extraction: it returns every XBRL-tagged number a company has filed, which is the structured complement to running an LLM over the unstructured 10-K narrative. Frames flips the axis: one financial concept across every filer for a given period, useful for peer screens.
Real-time filings: polling, not push
EDGAR does not publish a true push API for new filings. The real-time mechanism is the filing-index RSS/Atom feeds plus the full-text search, both of which you poll. For a near-real-time 8-K monitor, poll the latest-filings feed on a fixed interval inside the 10 req/s budget. There is no webhook, and no SLA on feed latency: treat it as best-effort, not a guaranteed event stream.
Bulk data: when polling is the wrong tool
For large-scale historical work, the SEC publishes bulk data dumps rather than expecting you to crawl the API. The SEC rebuilds bulk ZIPs of every submissions and company-facts JSON nightly (submissions.zip and companyfacts.zip), and quarterly full-index archives list every filing, which is the correct path for a one-time corpus build (e.g. every 10-K body since 2010).4 Crawling that volume request-by-request at 8 req/s would take days and risk the block; the bulk files are a single large download.
What EDGAR does and does not give you
EDGAR gives you, free: every filing every US public company has submitted, the XBRL-tagged financials, and full-text search across filing bodies. That is the entire raw-data foundation for an LLM filings pipeline at zero data cost.
It does not give you: cleaned/normalized fundamentals (you get raw XBRL tags, which require mapping), sentiment or insights, news, real-time push, or any non-US coverage. For normalized fundamentals or news you pair EDGAR with a commercial vendor: see Polygon.io Pricing 2026 and the budget-data comparison in Tiingo vs Polygon vs Finnhub.
Verified engine output
The block below runs the Finance MCP Directory engine filtered to read-only MCP servers: the safe category for an EDGAR-style ingestion pipeline, where no execution surface should exist. The Massive (formerly Polygon.io) read-only server is the highest-graded read-only option the engine tracks; the engine output is computed live from the shipped bundle, not typed by hand.
Decision guidance
- Building a filings RAG corpus once? Use the bulk data dumps, not the API.
- Monitoring new filings? Poll the index feeds + full-text search inside 8 req/s.
- Extracting one company's fundamentals? Company Facts in one call.
- Screening one metric across the market? Frames.
- Need normalized fundamentals or news? EDGAR is the free base; layer a paid vendor on top.
Connects to
- Finance MCP Directory: read-only MCP servers that wrap EDGAR and other data sources.
- Tiingo vs Polygon vs Finnhub 2026: the normalized-fundamentals vendors that complement raw EDGAR.
References
Footnotes
-
U.S. Securities and Exchange Commission. "Webmaster Frequently Asked Questions" (current maximum access rate 10 requests per second; declare a User-Agent such as "Sample Company Name AdminContact@
.com"). sec.gov, verified 2026-10-18. https://www.sec.gov/about/webmaster-frequently-asked-questions ↩ ↩2 -
U.S. Securities and Exchange Commission. "SEC to apply new rate control limits to EDGAR websites" (no more than 10 requests per second regardless of the number of machines; the SEC may limit further requests from the IP for a brief period). sec.gov, verified 2026-10-18. https://www.sec.gov/filergroup/announcements-old/new-rate-control-limits ↩
-
U.S. Securities and Exchange Commission. "Accessing EDGAR Data" / "Developer Resources." sec.gov, verified 2026-10-18. https://www.sec.gov/about/developer-resources ↩
-
U.S. Securities and Exchange Commission. "EDGAR Application Programming Interfaces" (no authentication or API keys; submissions, companyfacts, companyconcept and frames endpoints; bulk submissions.zip and companyfacts.zip rebuilt nightly). sec.gov, verified 2026-10-18. https://www.sec.gov/search-filings/edgar-application-programming-interfaces ↩
Verified engine output
Show the recompute-verified inputs and outputs
| scope | read-only |
|---|
| total | 11 |
|---|---|
| filtered | 4 |
| servers › row 1 › id | polygon-mcp |
| servers › row 1 › name | Massive (formerly Polygon.io) MCP Server |
| servers › row 1 › vendor | polygon |
| servers › row 1 › official | true |
| servers › row 1 › url | https://github.com/massive-com/mcp_massive |
| servers › row 1 › description | Official Massive (formerly Polygon.io) MCP server, self-hosted from the mcp_massive repo with an API key. Read-only access to Massive's stocks, options, futures, indices, forex and crypto endpoints within your plan. Massive also runs a hosted OAuth version at mcp.massive.com (since 2026-09-15). |
| servers › row 1 › scope | read-only |
| servers › row 1 › auth | api-key |
| servers › row 1 › idempotency supported | false |
| servers › row 1 › transport | stdio+http |
| servers › row 1 › schema quality | A |
| servers › row 1 › license | MIT |
| servers › row 1 › last commit | 2026-10-08 |
| servers › row 1 › capabilities › row 1 | stocks aggregates (daily / minute / sec / tick) |
| servers › row 1 › capabilities › row 2 | options chains |
| servers › row 1 › capabilities › row 3 | crypto trades + quotes |
| servers › row 1 › capabilities › row 4 | forex rates |
| servers › row 1 › capabilities › row 5 | news API |
| servers › row 1 › capabilities › row 6 | reference data |
| servers › row 1 › security notes › row 1 | Read-only scope — no trade execution surface |
| servers › row 1 › security notes › row 2 | API key required; safe to scope tightly |
| servers › row 1 › security notes › row 3 | No idempotency concern (no writes) |
| servers › row 1 › overall grade | A |
| servers › row 2 › id | ibkr-connector |
| servers › row 2 › name | IBKR Connector (official AI Integration) |
| servers › row 2 › vendor | ibkr |
| servers › row 2 › official | true |
| servers › row 2 › url | https://www.interactivebrokers.com/en/general/about/mediaRelations/7-28-26.php |
| servers › row 2 › description | Interactive Brokers' official AI Integration, a hosted remote MCP at api.ibkr.com/v1/api/mcp-public. Analyzes portfolios, researches investments and drafts trade instructions; you convert each instruction into an order on an IBKR platform. |
| servers › row 2 › scope | read-only |
| servers › row 2 › auth | oauth-2.0 |
| servers › row 2 › idempotency supported | false |
| servers › row 2 › transport | http-stream |
| servers › row 2 › schema quality | C |
| servers › row 2 › license | proprietary (hosted) |
| servers › row 2 › last commit | 2026-07-28 |
| servers › row 2 › capabilities › row 1 | portfolio analysis |
| servers › row 2 › capabilities › row 2 | market data lookups (implied volatility, 52-week range) |
| servers › row 2 › capabilities › row 3 | risk scenarios |
| servers › row 2 › capabilities › row 4 | draft trade instructions |
| servers › row 2 › security notes › row 1 | Hosted by IBKR — no self-hosted code to audit |
| servers › row 2 › security notes › row 2 | Sign-in on IBKR's own screen; each connection authorizes a single account |
| servers › row 2 › security notes › row 3 | Drafts instructions only: the client submits every order on an IBKR platform |
| servers › row 2 › security notes › row 4 | Tool schemas not published — schema quality graded C until inspectable |
| servers › row 2 › overall grade | C |
| servers › row 3 › id | databento-mcp |
| servers › row 3 › name | Databento MCP Server (community) |
| servers › row 3 › vendor | databento |
| servers › row 3 › official | false |
| servers › row 3 › url | https://github.com/Nice-Wolf-Studio/databento-mcp-server |
| servers › row 3 › description | Community-maintained Databento MCP server focused on ES/NQ futures: real-time quotes, historical bars and session detection. Not endorsed by Databento; verify schemas against docs. |
| servers › row 3 › scope | read-only |
| servers › row 3 › auth | api-key |
| servers › row 3 › idempotency supported | false |
| servers › row 3 › transport | stdio |
| servers › row 3 › schema quality | B |
| servers › row 3 › license | none declared |
| servers › row 3 › last commit | 2025-11-25 |
| servers › row 3 › capabilities › row 1 | ES/NQ futures quotes |
| servers › row 3 › capabilities › row 2 | historical bars |
| servers › row 3 › capabilities › row 3 | session detection |
| servers › row 3 › security notes › row 1 | Unofficial — review schema fidelity before production use |
| servers › row 3 › security notes › row 2 | No licence declared in the repository — confirm terms before reuse |
| servers › row 3 › security notes › row 3 | Does not rate-limit; relies on Databento's server-side meter |
| servers › row 3 › security notes › row 4 | Billing tracked via Databento meter — test runs cost money |
| servers › row 3 › overall grade | D |
| servers › row 4 › id | tiingo-mcp |
| servers › row 4 › name | Tiingo MCP (community) |
| servers › row 4 › vendor | tiingo |
| servers › row 4 › official | false |
| servers › row 4 › url | https://github.com/matteoantoci/mcp-tiingo |
| servers › row 4 › description | Community Tiingo MCP. Read-only access to EOD equities, news API, fundamentals, crypto. |
| servers › row 4 › scope | read-only |
| servers › row 4 › auth | api-key |
| servers › row 4 › idempotency supported | false |
| servers › row 4 › transport | stdio |
| servers › row 4 › schema quality | B |
| servers › row 4 › license | unclear (NOASSERTION) |
| servers › row 4 › last commit | 2025-09-10 |
| servers › row 4 › capabilities › row 1 | EOD equities |
| servers › row 4 › capabilities › row 2 | intraday (limited tiers) |
| servers › row 4 › capabilities › row 3 | news |
| servers › row 4 › capabilities › row 4 | fundamentals |
| servers › row 4 › capabilities › row 5 | crypto |
| servers › row 4 › security notes › row 1 | Read-only — no execution risk |
| servers › row 4 › security notes › row 2 | Does not expose API key in responses |
| servers › row 4 › security notes › row 3 | Licence file not recognised by GitHub (NOASSERTION) — confirm terms before reuse |
| servers › row 4 › overall grade | D |
Computed live at build time.
Frequently asked questions
- Is the SEC EDGAR API free in 2026?
- Yes. The data.sec.gov REST APIs and full-text search are free with no API key, no registration, and no paid tier.
- What is the EDGAR API rate limit?
- 10 requests per second per requester, counted across all machines you use. It has been the policy since July 2021.
- Do I need an API key for EDGAR?
- No. The only requirement is a descriptive User-Agent header identifying you by name and email. A missing User-Agent is the most common cause of a 403.
- Does EDGAR push new filings in real time?
- No. There is no webhook or push API. You poll the filing-index feeds and full-text search; latency is best-effort with no SLA.
- Should I crawl the API or use bulk data for a full historical corpus?
- Use the bulk data dumps. Crawling the full archive request-by-request at the rate limit would take days and risk an IP block.