Federal Register API: Querying 202,526 Final and Proposed Rules

Short answer: the Federal Register corpus is 202,526 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.

TL;DR

• 202,526 Federal Register documents, 1994 to present, refreshed weekly. Final rules, proposed rules, and presidential documents, split with documentType.
• 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 will silently drop 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.
• federalregister.gov has been throttling traffic in 2026, which can push a weekly pull later than scheduled. Design your pipeline to tolerate a late refresh rather than to assume a fixed clock.
• Versioning here is the amendment record, not a date parameter. One current text per citation, plus amendment history, a currency filter, and forward-looking change diffs on watched boards.

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

Read next: CFR API: 219,114 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: 34 Sub-Regulatory Sources in One Endpoint for the layer beneath both.

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: 219,114 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, not a display name. Results carry both. The example below returns agencies: ["Federal Reserve System", "Treasury Department", ...] alongside agencySlugs: ["federal-reserve-system", "treasury-department", ...]. Read the slugs off a first result and pin them; do not guess.

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

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 result, not a schema sketch.

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
  }'

Top result, 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 agencies, one document. That is normal for a joint rulemaking, and it is why the metadata fields are arrays rather than strings.

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 did not 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 roughly three passages per section: 4,150,839 sections index as 12,003,716 passages. Federal Register documents sit far above that average, 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

A weekly refresh sets the rhythm. 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 entirely and subscribe a watch. A free GET /boards call enumerates the watchable sources and hands back lastRetrievedAt, cadence, and retrievalStatus for each. See Law Change Alerts, and Law Change Alerts API: Webhooks for When a Statute or Rule Actually Moves for the delivery contract.

What to design around

federalregister.gov has been throttling traffic in 2026. That is the publisher's call and we honor it rather than routing around it. The practical effect is that a weekly pull can land later than scheduled. Build a pipeline that treats a late refresh as normal and alerts on a stalled board rather than on a missed clock tick.

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

Versioning here is the amendment record, not a date parameter. A citation maps to exactly one stored text, the live one. What you get in its place: amendment history where the publisher prints it, a lastAmendedYear per item, the yearFrom and yearTo currency filter, and forward-looking per-item diffs on watched boards. Design point-in-time reconstruction as its own feature, sourced from the amendment record, rather than as a query parameter. Amendment History and Point-in-Time Law: What a Legal API Can and Cannot Tell You works through the design consequences.

Sourcing is the publisher's own, always. Every Federal Register document here was taken from the government publisher's own site. A commercial aggregator is not used, not even as a fallback when the publisher is slow. 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 202,526 documents refreshed weekly. Presidential documents are served separately under corpusType=EXECUTIVE_ACTION covering 2015 to present with a daily refresh.

How do I filter Federal Register results by agency?

Pass agency with the agency slug, for example transportation-department or federal-reserve-system. Results return both agencies (display names) and agencySlugs, so read a slug off a first result rather than guessing its spelling. 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 does not have an is-open flag, because open status is a function of the current date rather than a stored property.

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, 4,150,839 sections index as 12,003,716 passages, and Federal Register documents split more than average 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 delivers per-item change diffs. 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?

Versioning here runs off the amendment record rather than a date parameter. There is one current text per citation, with amendment history, a last-amended year, a currency filter, and change diffs going forward on watched boards. There is no as_of=DATE parameter that reconstructs superseded text.

Where to start

Run GET /us/statutes/coverage first, documented in the coverage reference. It is free, self-describing, and it returns per-corpus counts, a currency array in the publisher's own words, declared pauses with reasons, and a measuredAt timestamp. 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 all 52 state statutory jurisdictions behind one key. The tradeoff worth naming: the weekly cadence on this corpus means it is built for compliance-calendar work, not for same-day newsroom alerting on a rule published this morning.

Priyansh Khodiyar

Co-Founder & CTO

Priyansh leads engineering and AI at Vaquill, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.