SEC submissions JSON: filings.recent holds 1,000 rows, the rest is in filings.files

Checked 2026-09-08 · Filings and registries: SEC JSON and XBRL

The submissions JSON for a company puts only the most recent 1,000 filings in filings.recent. Everything older sits in a separate file named in filings.files, which you have to fetch yourself. For Apple that means recent stops at 2015-07-22 and 19 of its 10-K filings — every one before 2015 — are in the overflow file, not the main document.

What we saw

filings.recent is exactly 1,000 rows and covers 2026-09-03 back to 2015-07-22. Source (filings.recent, 2026-09-08).

recent lens: {'accessionNumber': 1000, 'filingDate': 1000, 'reportDate': 1000, 'acceptanceDateTime': 1000, 'act': 1000}
date range: 2026-09-03 -> 2015-07-22

filings.files names one overflow file holding 1,246 more filings back to 1994. Source (filings.files, 2026-09-08).

[
 {
  "name": "CIK0000320193-submissions-001.json",
  "filingCount": 1246,
  "filingFrom": "1994-01-26",
  "filingTo": "2015-07-20"
 }
]

The overflow file is a bare object of parallel arrays with the same 16 keys — no filings or recent wrapper — so the parsing code differs from the main file. Source (top level, 2026-09-08).

keys: ['accessionNumber', 'filingDate', 'reportDate', 'acceptanceDateTime', 'act', 'form', 'fileNumber', 'filmNumber', 'items', 'core_type', 'size', 'isXBRL', 'isInlineXBRL', 'isXBRLNumeric', 'primaryDocument', 'primaryDocDescription']
len 1246
range 2015-07-21 1994-01-26

19 Apple 10-K filings live only in the overflow file, from 2014-10-27 back to 1994-12-13. Source (form == '10-K', 2026-09-08).

10-K count in overflow 19 [('2014-10-27', '0001193125-14-383437'), ('2013-10-30', '0001193125-13-416534')] [('1994-12-13', '0000320193-94-000016')]

Both files are column-oriented: each key is an array and row n is the nth element of every array. There is no list of filing objects to iterate. Source (filings.recent row 0 assembled by index, 2026-09-08).

row0: {'accessionNumber': '0001140361-26-035636', 'filingDate': '2026-09-03', 'form': '4', 'primaryDocument': 'xslF345X06/form4.xml', 'reportDate': '2026-09-01'}

To build the document URL you strip the dashes from accessionNumber and use the unpadded CIK. The dashed form 404s; the padded CIK 301-redirects. Source (HTTP status of three URL spellings, 2026-09-08).

dashes http=404
nodash http=200
paddedcik http=301

The cik field inside the JSON is the zero-padded 10-character form, which is the wrong spelling for the Archives path. Source (cik, 2026-09-08).

cik field: '0000320193' name Apple Inc.

The command

UA='opendatanotes.org maintainer@opendatanotes.org'; curl -sS -A "$UA" 'https://data.sec.gov/submissions/CIK0000320193.json' -o aapl.json; python3 -c "import json;d=json.load(open('aapl.json'));r=d['filings']['recent'];print({k:len(v) for k,v in list(r.items())[:5]});print(r['filingDate'][0],'->',r['filingDate'][-1]);print(json.dumps(d['filings']['files']))"

{'accessionNumber': 1000, 'filingDate': 1000, 'reportDate': 1000, 'acceptanceDateTime': 1000, 'act': 1000}
2026-09-03 -> 2015-07-22
[{"name": "CIK0000320193-submissions-001.json", "filingCount": 1246, "filingFrom": "1994-01-26", "filingTo": "2015-07-20"}]

Checked 2026-09-08.

curl -sS -A "$UA" 'https://data.sec.gov/submissions/CIK0000320193-submissions-001.json' -o aapl001.json; python3 -c "import json;d=json.load(open('aapl001.json'));print(list(d.keys()));print(len(d['form']), d['filingDate'][0], d['filingDate'][-1]);print(sum(1 for f in d['form'] if f=='10-K'))"

keys: ['accessionNumber', 'filingDate', 'reportDate', 'acceptanceDateTime', 'act', 'form', 'fileNumber', 'filmNumber', 'items', 'core_type', 'size', 'isXBRL', 'isInlineXBRL', 'isXBRLNumeric', 'primaryDocument', 'primaryDocDescription']
len 1246
range 2015-07-21 1994-01-26
10-K count in overflow 19

Checked 2026-09-08.

curl -sS -A "$UA" -o /dev/null -w 'dashes http=%{http_code}\n' 'https://www.sec.gov/Archives/edgar/data/320193/0001140361-26-035636/'; curl -sS -A "$UA" -o /dev/null -w 'nodash http=%{http_code}\n' 'https://www.sec.gov/Archives/edgar/data/320193/000114036126035636/'; curl -sS -A "$UA" -o /dev/null -w 'paddedcik http=%{http_code}\n' 'https://www.sec.gov/Archives/edgar/data/0000320193/000114036126035636/'

dashes http=404
nodash http=200
paddedcik http=301

Checked 2026-09-08.

where	file	filings	date range
filings.recent	CIK0000320193.json	1000	2015-07-22 to 2026-09-03
filings.files[0]	CIK0000320193-submissions-001.json	1246	1994-01-26 to 2015-07-20

Limits

Measured on one filer. A company that files rarely will have all its history in recent and an empty files array; a heavy filer may have several overflow files rather than one. I only saw the one-file case.
data.sec.gov rejects a request with no User-Agent or a default library User-Agent with HTTP 403, so every command here sends one.
recent held exactly 1,000 rows for this filer, covering eleven years. SEC's API page describes the rule as one year or 1,000 filings, whichever is more; I did not find a filer heavy enough to test the one-year half of it.

Open question

SEC's own API page says recent holds one year of filings or 1,000, whichever is more. Apple's is exactly 1,000 covering eleven years. What does a filer with more than 1,000 filings inside twelve months get — a longer recent, or a second overflow file?

Plain text