Free EDGAR API
for SEC Filings and XBRL
Build directly on free SEC EDGAR data without confusing a filing index, an archived document, and an XBRL fact. This guide maps the official JSON endpoints, archive identifiers, bulk files, access controls, and validation steps needed for a source-traceable ingestion pipeline.
TL;DR
The SEC exposes public submissions and XBRL facts as JSON on data.sec.gov; no API key is required. Complete filings and exhibits remain in the EDGAR archives.
Use a zero-padded CIK for issuer data and accession number for a filing version. Preserve form, accepted time, report period, primary document, and source URL.
Submissions list filings, archive paths hold filed documents, and XBRL endpoints expose tagged facts. Each layer answers a different question and needs a different parser.
Use a descriptive User-Agent, centralized pacing, caching, checkpoints, bounded retries, and source reconciliation. Keyless access is public infrastructure, not an unlimited feed.
Free EDGAR API endpoints, fields, and access rules
The official SEC EDGAR interfaces are a collection of source-oriented data products, not one universal “filings API.” The submissions endpoint is an issuer filing index; archive URLs resolve a specific filing and its exhibits; XBRL endpoints organize tagged facts; and bulk ZIP files support large backfills. A robust client chooses the layer that matches the question instead of forcing every task through one response schema.
Use submissions JSON as a filing index
Query by ten-digit, zero-padded CIK. The recent arrays include form, filing and report dates, acceptance time, accession number, primary document, file number, film number, and other metadata. Older history can be referenced through additional submissions files, so stopping at the recent array creates a silent history gap.
Resolve filed documents through archive identifiers
Use CIK, accession number, and primary-document name to construct or retain the exact archive location. The filing index page can enumerate the main document and exhibits. Store the original HTML or XML, content hash, retrieval time, and HTTP metadata before extracting sections so derived text can be reproduced later.
Retrieve XBRL facts with their full context
Company Facts aggregates concepts for one issuer; Company Concept narrows to one taxonomy and tag; Frames aligns facts across reporting entities for a stated period. A numeric value is incomplete without taxonomy, concept, unit, start and end dates, fiscal period, form, filed date, accession number, and dimensional context.
Use bulk data for backfills, APIs for increments
Bulk submissions and company-facts archives can reduce request overhead for an initial corpus. Record the archive version and ingestion checkpoint, then use issuer or filing-level endpoints for subsequent updates. Reconcile overlap by accession number rather than inserting duplicate rows.
Respect SEC automated-access rules
Send a descriptive User-Agent, coordinate request pacing across all workers, cache stable responses, honor throttling signals, and apply bounded retries with jitter. Monitor 403, 429, and 5xx rates; do not respond to errors by increasing concurrency or rotating anonymous identities.
Compare free SEC EDGAR API access options
| Option | What you get | Check first | Best use |
|---|---|---|---|
| SEC data.sec.gov | Public submissions JSON, Company Facts, Company Concept, and bulk ZIP archives. | User-Agent policy, CIK formatting, taxonomy context, and update process. | Auditable source-first pipelines. |
| Free vendor plan | Normalized JSON, ticker lookup, pagination, and sometimes historical quarters. | Request quota, history, licensing, amendment handling, and attribution. | Prototypes and small research tools. |
| Sandbox or evaluation | Limited institutions, quarters, or sample responses for integration testing. | Whether production use and complete coverage require payment. | Schema and client validation. |
| SEC bulk archives | Large snapshots of submissions or company facts for local ingestion. | Archive date, decompression size, schema drift, checkpointing, and overlap with incremental pulls. | Initial backfills and reproducible research datasets. |
| Self-hosted normalized layer | Your own issuer mapping, parsed documents, facts, search index, and change feed. | Parser maintenance, taxonomy changes, amendments, source storage, and operational cost. | Products needing control, custom semantics, and stable audit trails. |
How to integrate a free EDGAR API
Normalize one row from the SEC submissions response into a filing record like the example below. The values are placeholders; the important point is that all fields originate from the same array index and retain the issuer CIK.
{
"cik": "CIK_PLACEHOLDER",
"accession_number": "ACCESSION_PLACEHOLDER",
"form": "10-K",
"filed_date": "YYYY-MM-DD",
"accepted_at": "YYYY-MM-DDThh:mm:ss-04:00",
"report_period": "YYYY-MM-DD",
"primary_document": "PRIMARY_DOCUMENT.htm",
"filing_index_url": "SEC_FILING_INDEX_URL",
"retrieved_at": "YYYY-MM-DDThh:mm:ssZ"
}Preserve row alignment in filings.recent. Fields such as form, accessionNumber, filingDate, and primaryDocument are parallel arrays. Read them with the same index, create the complete record, and only then apply form or date filters. Filtering each array independently can pair a form with the wrong accession or document while still producing valid-looking JSON.
Step 1: define one EDGAR data contract
Specify the unit of output before choosing an endpoint: filing metadata, an immutable source document, a list of exhibits, a normalized XBRL fact, or a cross-company frame. Define required identifiers, expected history, freshness, null behavior, and evidence links. “Get SEC data” is too vague to test.
Step 2: build stable issuer and filing keys
Resolve ticker or company name to CIK but store the CIK as the durable issuer identifier. Store accession number as a string and retain form variants such as 10-K/A rather than collapsing them into the original. Separate filing date, accepted timestamp, and report period because each supports a different time-based query.
Step 3: operate a compliant fetch layer
Identify your application and contact in the User-Agent, use connection and read timeouts, centralize concurrency controls, cache immutable documents, and implement bounded retries for transient responses. Record URL, status, headers, bytes, retrieval time, attempt count, and content hash for diagnosis.
Step 4: normalize without erasing evidence
Keep raw payloads beside parsed tables. For XBRL, preserve taxonomy, concept, unit, dates, form, fiscal fields, accession number, and dimensions. For narrative text, retain document URL, item boundary method, parser version, and character offsets or anchors. An extracted answer should always point back to what was filed.
Step 5: validate backfill and incremental behavior
Reconcile a sample of issuer filing counts against EDGAR, include older submission files, test amendments and exhibit-heavy filings, and verify duplicates by accession number. Then simulate a failed run: resume from a checkpoint, replay a date window, and prove that the result is complete and idempotent.
How QVeris helps find EDGAR data capabilities
QVeris helps agents discover and inspect callable financial-data capabilities. For an EDGAR task, define whether the input is a company CIK, ticker, form type, accession number, XBRL concept, or date window; then inspect the required fields, returned identifiers, freshness, source links, and provider constraints before calling it. An agent should not silently substitute Company Facts for a full filing or a ticker for an unresolved CIK.
- Open the QVeris tool details to inspect the required inputs.
- Use the related free 13F API guide when the task is specifically institutional holdings rather than general EDGAR access.
- Verify provider coverage, pricing, licensing, and data accuracy against current documentation and the original SEC filing.
FAQ
Is the official EDGAR API free and keyless?
Yes. The SEC provides public submissions and XBRL data endpoints without an API key. That does not remove the obligation to identify the client, follow current access guidance, cache responsibly, and build the parsing and monitoring layers your application needs.
What is the difference between submissions JSON and a filing?
Submissions JSON is an index of filing metadata. The actual filed HTML, XML, text, and exhibits live in the EDGAR archives. Use accession number and primary-document metadata to connect the index record to the exact source documents.
Which EDGAR endpoint should I use for financial values?
Use Company Facts for many concepts reported by one issuer, Company Concept for one taxonomy tag, or Frames for facts aligned to a period across entities. Preserve units, dates, form, accession number, and dimensions; do not treat similarly named tags as automatically equivalent.
How do I retrieve older filing history?
Read the additional submissions files referenced by the issuer response and use archive paths for the source documents. For large initial loads, evaluate SEC bulk archives, record their version, and reconcile later incremental results by accession number.
How should an EDGAR crawler handle rate controls?
Follow the SEC's current published guidance, identify the application, coordinate pacing across workers, cache immutable documents, honor Retry-After, and use bounded backoff. Monitor error rates and pause when access responses indicate that traffic should be reduced.
What makes an EDGAR pipeline auditable?
Store raw source payloads, official URLs, CIK, accession number, form, accepted time, filing and report dates, retrieval time, content hash, and parser version. Derived facts or sections should retain enough source location information to reproduce the transformation.
Authoritative EDGAR references and related guides
Use the SEC sources to verify filing obligations, timing, and original records. Vendor free plans and limits can change, so confirm them in current provider documentation.