Guide

The SEC EDGAR API: rules, rate limit and what trips people up

The User-Agent rule that stops most first attempts, the ten-per-second limit, and why starting from a ticker instead of a CIK causes silent mismatches.

There is an API, and it has rules

Unlike most of the sources on this site, the SEC does publish machine-readable data and wants you to use it. Company filings, financial statements and the full submission history are all available as JSON from their servers. No key, no account, no quota form.

What there is instead is an access policy, and it has teeth. Two things in it decide whether your script works next month.

The User-Agent rule that stops most first attempts

The SEC requires every automated request to declare itself in the User-Agent header, with the name of the party and a contact address, in the shape Company Name AdminContact@domain.com. Send nothing and you get an "Undeclared Automated Tool" error rather than data.

From our own implementation: a declared agent naming the party and linking a profile page is accepted today and returns 200, even without an address in it. That is not literally what the policy asks for, so it is worth treating as borrowed time rather than a loophole. If you are building something that has to keep working, put a real contact address in.

The rate limit

Ten requests per second is the published maximum. That is generous compared to most sources and it is also a hard number rather than a vague ask, which makes it easy to respect. We run well under it deliberately, because a source that publishes a limit is a source that watches it, and being throttled here means the filing you needed is missing from a report that already went out.

Where the data actually lives

Three things people mix up, and getting them straight saves an afternoon.

  • CIK, not ticker. The SEC keys everything on a Central Index Key. Tickers change, get reused and do not exist for private filers. Any pipeline that starts from a ticker needs a resolution step, and that step is where the mismatches creep in.
  • Submissions and facts are different endpoints. One gives you the list of what a company filed and when. The other gives you the numbers inside those filings. People reach for the wrong one and conclude the data is missing.
  • Amendments. A filing can be superseded by an amended version. If you take the first match you may be reporting a number the company has since corrected.

What it is used for

Tracking when a company files, which is a timing signal in itself. Pulling reported figures from the source rather than a reseller, because a reseller adds a lag and sometimes a transcription error. And watching a set of companies for specific form types, which is a standing job rather than a one-off pull.

Doing it without maintaining it

The work here is not the download. It is the resolution from ticker to CIK, the amendment handling, the paging, the retries and the header that has to stay compliant. That is a small amount of code that has to keep being right for years, which is the kind of code that quietly rots in a repository nobody owns.

Our filings dataset is billed per filing listed, at $1.00 per 1,000, so a tenth of a cent each. Companies that return nothing, and lookups that fail, come back as records and are not charged. It reads the SEC's own JSON, declares itself in the header, and stays well under the published rate limit.

If you need one company's filings once, the SEC's own site will tell you in a minute and you should use it. This is for the case where you are watching a list, every week, and want the result in a table rather than a browser tab.

The datasets behind this