SEC EDGAR Rate Limits and the Fair Access Policy

If you write code that pulls filings directly from SEC.gov, you are bound by the SEC's fair access policy whether you have read it or not. It is short, it is enforced automatically, and ignoring it is the single most common way a scraping script gets itself blocked.

This guide covers what the policy actually says, how to set the header it asks for, and how to design a client that never bumps into the limit in the first place.

What the fair access policy covers

SEC.gov publishes its access rules on the "Accessing EDGAR Data" page. The policy exists to keep EDGAR responsive for everyone, since the same servers answer a human clicking through a filing in a browser and a script pulling thousands of documents overnight. Two requirements come up in almost every automated project:

• A rate limit. Automated tools should keep their request rate at or below 10 requests per second.
• A declared User-Agent. Requests should carry a User-Agent header identifying the requester, typically a company or individual name plus a contact email address, rather than a generic or empty value.

The limit is per user, not per endpoint and not per machine. Running the same script from five servers at 10 requests per second each does not give you 50 requests per second; it just makes you five times more likely to get flagged.

The policy in short

Why a browser does not need to worry about this

A person clicking around EDGAR in a browser sends requests far slower than 10 per second and already carries a normal browser User-Agent string, so the policy is invisible to them. It only becomes relevant once you write a loop: downloading every 10-K for a sector, polling for new filings, or backfilling years of history.

What happens if you go over the limit

If a client sends sustained bursts above the documented rate, the SEC can slow down or temporarily block further requests from that source. Because the SEC does not offer support for automated clients, there is no appeals desk to call. The practical fix is always the same: lower your request rate, add a delay between requests, and make sure you are not retrying failed requests in a tight loop, which multiplies the problem instead of solving it.

Designing a client that respects the limit

A few habits keep a script well inside the policy without you having to think about it on every request:

1. Throttle centrally. Put the delay between requests in one place, such as a wrapper around your HTTP calls, instead of scattering sleep calls through business logic.
2. Cache what you already fetched. Filings on EDGAR do not change once published, so there is no reason to re-download the same document twice.
3. Fetch only what you need. Prefer an endpoint that returns the structured fields you want over downloading a full filing and parsing it yourself.
4. Back off on errors. Treat a failed request as a signal to slow down, not as a reason to retry immediately.

import time
import urllib.request

HEADERS = {"User-Agent": "Example Research Project contact@example.com"}
last_request = 0.0

def fetch(url):
    global last_request
    elapsed = time.monotonic()-last_request
    wait = 0.11-elapsed
    if wait > 0:
        time.sleep(wait)
    req = urllib.request.Request(url, headers=HEADERS)
    last_request = time.monotonic()
    with urllib.request.urlopen(req) as resp:
        return resp.read()

That loop keeps requests comfortably under 10 per second (a little slower, in practice, since real network latency adds its own gaps) and always sends an identifying User-Agent.

Where a filings API changes the calculation

Once you move past a handful of companies, hand-rolled throttling starts costing more engineering time than the data is worth. An API that has already fetched, parsed and indexed EDGAR filings lets you ask for exactly the rows you need, such as every 8-K with a given item number in a date range, instead of re-deriving that filter from raw filings yourself.

curl "https://secfeedapi.com/v1/filings?query=formType:\"8-K\"&size=5" \
  -H "Authorization: Bearer YOUR_API_KEY"

In Python with the SecFeed SDK:

from secfeed import Client

sf = Client("YOUR_API_KEY")
filings = sf.filings('formType:"8-K" AND filedAt:[2026-10-01 TO 2026-10-17]')
for f in filings:
    print(f["companyName"], f["formType"], f["filedAt"])

See the full filing search reference at /docs/#v1-filings.

Frequently asked questions

What is the SEC's rate limit for EDGAR?

SEC.gov documents a limit of 10 requests per second for automated access to its site, which includes the EDGAR filing pages and full text search. The limit applies per user rather than per machine.

Do I need a special API key to use SEC.gov directly?

No. SEC.gov does not require registration or an API key. It does ask that automated requests carry a descriptive User-Agent header with contact information, which costs nothing to add.

Can I get around the rate limit by using multiple servers?

The policy is written to apply per user, so splitting requests across machines to exceed 10 requests per second goes against its intent and risks having all of those sources rate limited together.

Does the fair access policy apply to third party APIs like SecFeed?

Any service that fetches filings from SEC.gov on your behalf is responsible for following the policy on its own infrastructure. See how to download filings politely in Python for the same principles applied directly against EDGAR.

Where is the official policy published?

On the "Accessing EDGAR Data" page on sec.gov, which is the authoritative source for the current rate limit and User-Agent requirement.