Federal Register API: Querying Over 196,000 Final and Proposed Rules

Short answer: the Federal Register corpus is more than 196,000 agency rule documents covering 1994 to present, queryable with one search call using corpusType=FEDERAL_REGISTER and narrowed by documentType, agency, and a publication-date window. Each document carries the metadata a monitoring pipeline actually needs: docket ids, RIN, comments-close date, effective date, volume and page range, and the agency slugs that issued it. This is the corpus that tells you a rule is coming. The CFR is the corpus that tells you what the rule became. You need both, and the gap between them is the reason.

Reviewed and corrected on 12 October 2026. This is general information, not legal advice.

TL;DR

• More than 196,000 Federal Register rule documents, 1994 to present. Final rules and proposed rules, split with documentType. Presidential documents are a separate corpus (EXECUTIVE_ACTION). The refresh cadence is on GET /boards, where the Federal Register board declared daily on 12 October 2026.
• publishedFrom and publishedTo are not yearFrom and yearTo. The first pair filters when the document appeared in the Register. The second pair filters the last amendment year a publisher credits, which is a different question and drops items with no amendment credit.
• FR documents are long. One real proposed rule in the corpus runs 73,035 words across 61 Register pages. Long documents split into many retrieval passages, so a section count and a passage count are different numbers.
• The metadata is the product. RIN, docket ids, comments-close date, effective date, volume, start and end page, CFR cross-references, agency slugs, and the federalregister.gov URL all come back on a search result.
• The publisher limits automated traffic to its website, so a pull can land later than scheduled. Design your pipeline to tolerate a late refresh rather than to assume a fixed clock.
• Past text is a reconstruction. asOf=YYYY-MM-DD on the section body call rebuilds an earlier text from observed changes and flags isBounded. Alongside it: amendment history, a currency filter, and change diffs on watched boards.

One of the source-by-source posts in our US primary law corpus series.

Read next: CFR API: 222,311 Federal Regulation Sections, Refreshed Daily for the codified side, Executive Orders API: Presidential Documents, Refreshed Daily for the presidential documents that also run through the Register, and Federal Agency Guidance API: 53 Sub-Regulatory Sources in One Endpoint for the layer beneath both. If you would rather call the publisher's own free API, Federal Register API in Python: Search Rules and Notices covers it, including a paging trap past page 50.

A short history: sixteen pages to an API

The Federal Register started because the government couldn't keep track of its own rules (the oil case behind it is told in the CFR API post). Congress passed the Federal Register Act in 1935, and the first issue came out on March 14, 1936. It ran sixteen pages.

The big change came with the Administrative Procedure Act, approved on June 11, 1946. It required agencies to publish notices of proposed rulemaking in the Register and let the public comment before final rules took effect. The Register's own history says that moved it from a source of authoritative information about regulations to "an integral part of the democratic, quasi-legislative process by which those regulations were formed." The issue of January 1, 1947 was the first with a Proposed Rule category, which is the same final-versus-proposed split you filter on today with documentType. In 1947, in Federal Crop Insurance Corp. v. Merrill, the Supreme Court held that publication in the Register gives legal notice of a rule's contents, whether or not you ever read it.

Then it went online. The first electronic version appeared in 1994 on GPO's newly started GPO Access service, with the full text of the daily issues going back to January 3, 1994. Two years later, on September 19, 1996, the Administrative Committee of the Federal Register gave the online version the status of an official edition. And on July 26, 2010, the 75th anniversary of the original Act, the National Archives and GPO launched Federal Register 2.0 on federalregister.gov, as an unofficial prototype built on the bulk XML from GPO's digital system and on open source code.

Size has been a running theme. The same history notes that the largest single document ever published in the Register was a 6,653-page report on the Justice Department's proposed antitrust settlement with Microsoft, in the issue of May 3, 2002. Keep that in mind the next time a 73,000-word proposal feels long. Everything above comes from the Office of the Federal Register's brief history and a National Archives press release about the 2010 launch.

The lifecycle, and why one corpus is not enough

A federal regulation has a life story, and the two corpora catch it at different moments.

An agency publishes a Notice of Proposed Rulemaking in the Federal Register. Comments open for a fixed window. The agency reads them, revises, and publishes a final rule with an effective date. Only later does the codified text land in the Code of Federal Regulations.

That lag is the whole argument. If you monitor only the CFR, you learn about a rule after it is already binding. If you monitor only the Federal Register, you have the news but not the consolidated law your customers actually have to comply with.

The two corpora carry different volumes and different refresh cadences, which follows from what each one is.

CFR API: 222,311 Federal Regulation Sections, Refreshed Daily covers the codified side in the same detail: title and part navigation, the daily refresh, and the FAR and DFARS chapter splits. Read that one if your question is what the rule says today rather than what is about to change.

The filters that matter

Everything below is a parameter on POST /us/statutes/search. Every value corpusType accepts is listed in the corpus types reference.

agency takes a slug. The agency's full name or its Federal Register acronym (such as EPA) resolves to the same slug, but a name that fits no agency in the corpus, or an acronym shared by several agencies, is rejected with a 422 and is not charged. Results carry both forms. The 2008 proposal below returns agencies: ["Federal Reserve System", "Treasury Department", ...] alongside agencySlugs: ["federal-reserve-system", "national-credit-union-administration", ...]. Read the slugs off a first result and pin them.

Multi-agency rules are common and the slug array reflects that. The 2008 unfair-practices proposal below lists four agency names.

publishedFrom is not yearFrom

This is the trap that will cost you a day if nobody tells you.

publishedFrom and publishedTo filter when the document appeared in the Federal Register. That is a fact about the Register.

yearFrom and yearTo filter the last amendment year the publisher credits on the item. That is a fact about the law. It exists so a currency filter tracks the statute or rule rather than our rebuild date, which is the right default for statutes and codes.

For a Federal Register document, publication date is almost always the question you mean. A rule published 2026-01-14 is a January 2026 event no matter what amendment credits appear inside it.

A real result, field by field

Here is an actual call, and an actual record from the corpus, not a schema sketch. On 12 October 2026 this query returned a run of PHMSA burden-reduction final rules from 2026; the record below is one of them, fetched by its actId with GET /us/statutes/section/FR_RULE_2026-00578, because search rankings move and a record fetched by id does not.

curl -s -X POST https://api.vaquill.ai/api/v1/us/statutes/search \
  -H "Authorization: Bearer vq_key_..." \
  -H "Content-Type: application/json" \
  -d '{
    "query": "hazardous materials transportation safety requirements",
    "corpusType": "FEDERAL_REGISTER",
    "documentType": "final",
    "publishedFrom": "2026-01-01",
    "limit": 3
  }'

The record, trimmed to the fields that carry weight:

Read that as a monitoring event and it is already complete. A DOT and PHMSA rule, effective 30 days after publication, touching six CFR parts, tracked under RIN 2137-AF41 and docket PHMSA-2018-0080. No second call needed to decide whether it matters to you.

The same query with documentType=proposed behaves differently in one useful way. A proposal carries frCommentsCloseOn instead of frEffectiveOn, plus a datesText string in the agency's own words.

Two RINs, three docket ids, four agency names, one document. The abstract names three regulators (the Board, OTS and NCUA); the Federal Register also lists the Treasury Department as a parent of OTS. That is normal for a joint rulemaking, and it is why the metadata fields are arrays rather than strings. The record's frRelatedDocuments links this proposal to the later final rules that followed it (for example 74 FR 5498 in January 2009 and 75 FR 6558 in February 2010), and its actStatus is proposed.

Other fields on the FR shape worth knowing: frSignificant (whether the document is flagged significant), frCorrectionOf and frCorrections (correction chains in both directions), frRelatedDocuments, frRegulationsDotGovUrl where the agency published one, topics (the Register's own subject terms), and abstract (the agency's summary paragraph). Fields the publisher didn't supply come back null rather than as an invented value.

Sections versus passages

A "section" here means one citable item with a stable actId. For the Federal Register, that is one document: one final rule, one proposal.

A "passage" is a retrieval unit. Long documents get split so that semantic search can hit the paragraph that answers your question rather than returning a 73,000-word blob.

Across the whole corpus the split runs at several passages per section: more than 5.3 million sections index as more than 20 million passages. Federal Register documents split into more passages than most, because a preamble plus response-to-comments plus regulatory text is one of the longest document shapes in American law. The 73,035-word proposal above is one section and many passages.

Three consequences for your integration:

• Count sections, not passages, when you report coverage. They answer different questions and the numbers differ by a lot.
• A search returns sections. You get one hit per document with the best-matching excerpt attached, not one hit per paragraph.
• Paging is cut from a single ranking, so results never repeat or go missing between pages, and page 3 costs the same as page 1. The pagination rules carry the limit and offset ceilings.

Building the monitoring pipeline

Refresh runs on the board's cadence, so build for lateness rather than for a fixed clock. Here is the shape that survives contact with production.

1. Define your watch set as agency slugs plus CFR parts. Slugs catch everything an agency issues. crossReferencesCfr catches rules from other agencies that touch parts you care about. Use both, because a rule that amends 49 CFR 173 matters to you regardless of who wrote it.
2. Pull with publishedFrom set to your last successful run, not to a fixed calendar week. If a run is late, the next one backfills instead of skipping.
3. Key on actId. Ids are stable across refreshes. Titles get corrected and page paths move.
4. Branch on documentType. A proposal goes into a comment-deadline queue keyed on frCommentsCloseOn. A final rule goes into a compliance-date queue keyed on frEffectiveOn.
5. Follow the RIN to connect the two. A proposal and its final rule usually share a RIN, which is how you close the loop and tell a reviewer that the thing they commented on in March became binding in September.
6. Check the CFR corpus after the effective date passes, to pick up the codified text. That is a separate query on corpusType=CFR.
7. Or skip steps 2 and 3 and subscribe a watch on the Federal Register board. A free GET /boards call enumerates the watchable sources and hands back lastRetrievedAt and cadence for each. A Federal Register watch covers the whole board, because a document is not a section of a code and has no title or part to narrow by; to follow one document, scope the watch to its actId. See Law Change Alerts, and Law Change Alerts API: Webhooks for When a Statute or Rule Actually Moves for the delivery contract.

What developers say

Developers who build on the Register have had a mixed relationship with it, and both halves are worth hearing.

The praise comes early. A Hacker News commenter who disclosed working for 18F called federalregister.gov "a favorite of mine in the federal government, and an inspiration (they launched with a full JSON REST API in 2010!)" (konklone, Hacker News, February 2015). In 2024, another commenter listed what you can download for any single document: JSON, XML, and a standardized government metadata format called MODS (avs733, Hacker News, April 2024). The publisher's own API documentation says its endpoints do not require API keys, so a proof of concept takes one HTTP client.

The complaint is about access. In August 2022 a commenter quoted the site's notice that, because of "aggressive automated scraping," programmatic access was limited to its developer APIs, and then reported: "Then a captcha and a button to request access, which if you complete, returns a 500 Internal Server Error." (deathanatos, Hacker News, August 2022). That is one comment about one moment. It does show that limiting automated traffic on this site isn't new, which is why the late-refresh advice below isn't paranoia.

What to design around

The publisher limits automated traffic. How much automated traffic its website accepts is the publisher's call. In our October 2026 tests of the publisher's own API, the API kept answering while the website's HTML pages started returning HTTP 429 after a burst of requests; Federal Register API in Python: Search Rules and Notices has the details. The practical effect for a pipeline is that a pull can land later than scheduled. Treat a late refresh as normal and alert on a stalled board (a lastRetrievedAt that has drifted past the declared cadence) rather than on a missed clock tick.

Coverage starts in 1994. Documents older than that aren't in the corpus. The proposal example above is from 2008 and is present; a 1987 rule isn't.

Past text here is a reconstruction. A citation maps to one stored text, the live one, and Federal Register documents are not among the corpora where we hold published editions. Add asOf=YYYY-MM-DD to the section body call and the earlier text is rebuilt from the before-side of the first change we observed after your date (engine: observed_change). Read asOf.isBounded before you cite it: true means we saw no change affecting your date, which is not the same as there having been none, because capture began after the corpus did, and a section we know changed but cannot rebuild comes back unavailable. Alongside it you get amendment history where the publisher prints it, a lastAmendedYear per item, the yearFrom and yearTo currency filter, and per-item diffs through the changes endpoint of a watch. Amendment History and Point-in-Time Law: What a Legal API Can and Cannot Tell You works through the design consequences.

Sourcing is the government's own. Federal Register documents here come from the government publisher's data, and a commercial aggregator isn't used as a source or as a fallback. The parsers are open source at open-us-law if you want to check the work rather than take our word for it.

FAQ

What is the difference between the Federal Register and the CFR?

The Federal Register is the daily journal where agencies publish proposals, final rules, and notices as events. The CFR is the codified, subject-organized compilation of rules currently in force. A rule appears in the Register first and is codified into the CFR later, which is why regulatory monitoring needs both.

How far back does the Federal Register corpus go?

1994 to present, holding more than 196,000 rule documents. Presidential documents are served separately under corpusType=EXECUTIVE_ACTION covering 2015 to present with a daily refresh. Read the Federal Register board's own cadence and lastRetrievedAt from GET /boards.

How do I filter Federal Register results by agency?

Pass agency with the agency slug, for example transportation-department or federal-reserve-system. The full agency name or its Federal Register acronym also resolves to the slug. Results return both agencies (display names) and agencySlugs, so read a slug off a first result. Joint rulemakings carry several slugs on one document.

What is a RIN and why does it matter?

A Regulation Identifier Number tracks a rulemaking across its whole life. It comes back in frRegulationIdNumbers as an array, because a joint rulemaking carries one RIN per participating agency. Matching on RIN is how you connect a proposal you tracked to the final rule it became.

Can I search only proposed rules that are still open for comment?

Filter with documentType=proposed and a recent publishedFrom window, then check frCommentsCloseOn on each result against today. The API doesn't have an is-open flag, because open status is a function of the current date rather than a stored property. A deadline can also move: extensions and reopenings are published as Federal Register notices, and the curated FEDERAL_REGISTER_NOTICE corpus holds those that act on a rulemaking.

Why does the corpus report a section count lower than the passage count?

A section is one citable document with a stable actId. A passage is a retrieval unit, and long documents split into several so search can return the relevant paragraph. Corpus-wide, more than 5.3 million sections index as more than 20 million passages, and Federal Register documents split into more passages than most because they are long.

Does the API return the full text of a Federal Register document?

A search returns identity, metadata, and a matching excerpt. Use GET /us/statutes/section/{actId} and the /body variant to retrieve the full item. Every result also carries externalUrl pointing at the publisher's own page.

Can I get alerts when a new rule is published instead of polling?

Yes. GET /boards lists every watchable source for free with its cadence and last-retrieved timestamp, and a watch tells you which items changed, with a per-item diff available through the diff endpoint (4 credits per diff). Polling still works; the watch just moves the diffing off your side. The alerts guide covers creating and testing a watch.

Does this support point-in-time queries of an old rule text?

Yes, with limits. asOf=YYYY-MM-DD on the section body call rebuilds an earlier text from changes observed after your date, and isBounded tells you when the answer rests on when change capture began rather than on the law. If the wording of a codified rule on a past date is what you need, the CFR annual editions are the stored, published alternative. Amendment history, a last-amended year, a currency filter, and change diffs on watched boards sit alongside it.

Where to start

Run GET /us/statutes/coverage first, documented in the coverage reference. It is free and self-describing: it returns a legend of every corpus type, per-jurisdiction counts, a status breakdown and a measuredAt timestamp. It reports what we hold, not how recently it was refreshed; GET /boards carries the age. That is the honest starting point for a coverage decision, better than any number in a blog post including this one.

Vaquill AI serves the Federal Register alongside the CFR, the US Code, Statutes at Large, federal agency guidance, and state statutory codes for 56 jurisdictions behind one key. Before you rely on any board for same-day alerting, read its cadence and lastRetrievedAt on GET /boards.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill AI: the pipelines that pull statutes, regulations and court rules from every US jurisdiction's official publisher, and the REST API, MCP server and open dataset that serve them.