edgarkit

SEC EDGAR rate limits, in practice

The SEC publishes a 10-requests-per-second cap on EDGAR access. In practice the constraint is broader than that single number suggests, and a few production realities are worth knowing before you build a real-time pipeline on EDGAR.

Want this data via API instead of reading about it? Get a free API key →

The published rule

The SEC's official guidance for programmatic EDGAR access:

  • Maximum 10 requests per second per IP address.
  • Identify yourself with a descriptive User-Agent header that includes your name and email or a company name and a contact email.
  • Heavy use should be performed off-peak when possible.

The User-Agent requirement is not optional. Requests without a proper UA are throttled or blocked.

A compliant UA looks like:

User-Agent: Acme Trading research@acme.example.com

What "10 per second" actually means

The cap is enforced as a sustained rate, not a hard per-second window. Bursts above 10 req/sec for a few seconds typically don't trip anything. Sustained bursts over a few minutes do.

The SEC throttles aggressive crawlers by:

  1. Returning HTTP 403 Forbidden responses for a cool-down period (commonly 5-15 minutes).
  2. Silently delaying responses to slow you down before returning anything.
  3. Returning partial or stale content if your origin IP has been flagged.

The 403 path is the one most people hit. It looks like a permanent block but resolves on its own once you back off.

Beyond 10 req/sec, the hidden limits

Several other constraints affect production usage even though they're not documented as "rate limits":

  • Concurrent connection ceiling. Holding 50+ persistent connections from one IP triggers throttling regardless of request rate.
  • Same-document repeat requests. Pulling the same document URL 20 times in 60 seconds is treated as a misbehaving crawler even if your overall rate is low.
  • EFTS full-text search has a separate, stricter limit. EFTS (the search infrastructure) gets unhappy faster than the document servers do.
  • Daily index downloads count too. Pulling the daily index file every minute looks like polling and gets flagged.

The realtime feed and why it matters

The EDGAR Atom/RSS feeds at https://www.sec.gov/cgi-bin/browse-edgar return the most recent filings (no time-of-day batching). Polling these every few seconds is the practical realtime path. Most production EDGAR ingestion pipelines look like:

  1. Poll the Atom feed every 5-10 seconds.
  2. For each new accession number, fetch the filing index document.
  3. From the index, identify the actual content document (Form 4 XML, 13F XML, 8-K HTML).
  4. Fetch the content document.
  5. Parse and store.

If you're handling all major form types, that's roughly 3-5 requests per filing. A heavy filing day produces 10,000+ filings. The math forces you to be careful with your request rate, sometimes shard across multiple workers with distinct IPs, and add retries with backoff for the inevitable 403 bursts.

How EdgarKit handles this for you

EdgarKit runs the polling infrastructure on your behalf. The benefits versus building your own:

  • No SEC rate limits to manage. Your application talks to api.edgarkit.com, not sec.gov.
  • Better rate limits on EdgarKit's side. Free tier is 10 requests per minute, Basic is 60, Pro is 300, all per-API-key. Bursts are softer than the SEC's 403 hammer.
  • No User-Agent requirement. EdgarKit handles the SEC's UA conventions internally.
  • No 403 cool-downs. EdgarKit absorbs SEC rate limits with retry queues and presents a normal HTTP 429 (with a Retry-After header) when your API-key limit is hit.
curl "https://api.edgarkit.com/v1/filings?form_type=4&since=2026-06-19&limit=100" \
  -H "Authorization: Bearer YOUR_API_KEY"

Returns the most recent 100 Form 4 filings since the start of today, fetched and parsed already, no SEC rate-limit risk on your side.

When the SEC limits are fine

You can comfortably run on EDGAR direct when:

  • You're polling for one specific issuer's filings (a few requests per day).
  • You're doing one-shot historical bulk loads (parallelize across IPs, respect the limit, and you're done in hours).
  • You're a research project that doesn't need real-time delivery.

You should consider a third-party API when:

  • You're doing real-time event detection (Form 4 alerts, 8-K monitoring).
  • You're running a product where 403 cool-downs would degrade user-visible behavior.
  • You don't want to operate the polling, parsing, deduping, and amendment-tracking infrastructure.

Designing for EDGAR rate limits if you go direct

If you're building on EDGAR directly, these patterns help:

  • Add retry-with-exponential-backoff for 403 and 5xx responses. Start at 30 seconds, double up to 15 minutes.
  • Maintain a request log so you can verify you're under 10 req/sec at all times (not just on average).
  • Identify with a UA that includes a real email. If the SEC flags you, they sometimes reach out by email before block escalation.
  • Use If-Modified-Since headers on the daily indexes to avoid refetching stale content.
  • Shard by form type or filer prefix so each worker stays well under the cap on its own.

FAQ

What's the SEC EDGAR rate limit?

10 requests per second per IP address, enforced as a sustained rate. Bursts above this for a few seconds are usually OK; sustained excess is not.

Do I have to include a User-Agent header?

Yes. The SEC requires a User-Agent identifying the requestor. Requests without a proper UA are throttled or blocked.

What happens if I exceed the rate limit?

The SEC returns HTTP 403 Forbidden for a cool-down period (typically 5-15 minutes) and may flag your IP for repeated offenses.

Is the 10/sec limit per IP or per User-Agent?

Per IP. Cycling User-Agents from the same IP does not increase your effective rate.

Does EdgarKit have rate limits?

Yes, but they're per-API-key (not per-IP) and the response semantics are friendlier: HTTP 429 with a Retry-After header, no multi-minute cool-down. Free tier is 10 requests per minute, Basic is 60, Pro is 300.

Can I get whitelisted for higher SEC limits?

Generally no. The SEC does not run a commercial enterprise tier for EDGAR. The whitelisting that does exist is reserved for specific institutional partners.