GovInfo Is Free and Authoritative. Here Is What You Still Have to Build.

If your product is federal-only and you are willing to own a parser, govinfo.gov is usually the right answer. It is authoritative, free, well maintained, and it ships real USLM XML rather than scraped HTML. The build-versus-buy question only gets interesting when you need something the government does not publish: a per-citation JSON lookup, one search across corpora, state law, citation resolution, change detection, or a schema that stays the same shape when a publisher redesigns its site. This post lays out exactly where the free line sits, because the honest answer for a lot of teams is "use govinfo," and the honest answer for the rest is "the text is free, the plumbing is not."

TL;DR

• govinfo.gov is genuinely good. GPO publishes USLM XML for the US Code, the CFR, the Federal Register, and more, under a free api.data.gov key. If you can parse XML, you can build on it.
• The govinfo API is package and granule oriented, which means "give me a manifest, then download files." It is not a lookup that turns a citation into JSON.
• There is no federal publisher of state law. State statutes and regulations come from 52 separate publishers in 52 separate formats, and they add up to roughly 1.93M statute sections and 1.46M regulation sections.
• The work is not the text. Primary law is public domain. What costs money is normalization, indexing, citation resolution, versioning, and change detection over it.
• Nobody should treat a vendor as the authority on US law. Every result should carry the publisher's own URL so a reader can check the original. That is the test to apply to any provider, including ours.
• The sourcing is inspectable: the collection layer is published at open-us-law, so provenance is something you can read rather than a claim you have to accept.

Filed under our US primary law corpus series, which documents each federal and state source in its own post.

The two federal corpora this post keeps returning to have posts of their own: CFR API: 219,114 Federal Regulation Sections, Refreshed Daily and Federal Register API: Querying 202,526 Final and Proposed Rules. For the side govinfo does not cover at all, see State Regulations API: 1.5 Million Administrative Rules Across 52 Jurisdictions.

Disclosure and method

We build a US primary law API. That makes this post interested rather than neutral, so here is the method: every claim about a government source describes what that publisher actually ships, and every count about our own corpus is our own measured figure from 2026-08-30. Nothing here is a competitor's number we guessed at.

The frame is deliberately build-versus-buy and not a takedown. GPO, the Library of Congress, and the eCFR team maintain public infrastructure that a lot of legal tech quietly runs on, ours included.

What the government publishes, and where each one is strong

Four federal publishers cover most of what a developer wants at the federal level. They are not interchangeable.

govinfo is the one people underrate. The USLM XML is structured, versioned, and has a real schema behind it, which puts it ahead of most commercial legal data in raw fidelity. If your job is "give me Title 26 as a dataset," you are done in an afternoon.

congress.gov is the right tool for a different question. It answers "what is happening to this bill right now," which the codified Code cannot answer because codification lags enactment.

The eCFR is current in a way almost nothing else is. It reflects amendments as they take effect, which matters if you are tracking regulatory obligations rather than reading history.

The seven things the government does not publish

Every one of these is work somebody does. The question is whether it is you.

1. There is no per-citation JSON lookup

govinfo hands you a package, then granules inside it. To go from "42 U.S.C. 1983" to a JSON object with the section text, you first have to know which package and which granule holds it, then fetch, then parse, then extract.

That is fine once. It is a maintenance surface when the granule naming changes, when a section is renumbered, or when the citation arrives as free text from a user instead of as a structured tuple.

2. There is no cross-corpus search

The federal government does not publish an endpoint that searches the US Code, the CFR, the Federal Register, and agency guidance in one query with one ranking. Each publisher has its own search over its own holdings.

If your feature is "find every federal authority on this obligation," you are fanning out across four or five systems and merging rankings that were never designed to merge.

3. There is no state coverage at all

This is the big one, and it is structural rather than a gap somebody forgot to fill. No federal publisher publishes state law, because no federal body has authority over it. State law is published by 52 separate jurisdictions in 52 separate formats. The jurisdictions reference lists the codes.

The scale is the part people underestimate:

For comparison, the entire federal side we index is 618,875 sections, of which the US Code is 60,170 and the CFR is 219,114. State law is several times the size of federal law, and it is the part with no free bulk feed.

It is also the part where the formats diverge. Some states ship clean bulk exports. Some publish only paginated HTML behind a session-bound table of contents. Some publish PDF prints of a bound volume.

4. There is no citation resolution

A citation in the wild is messy. A state abbreviation like O.C.G.A., a code-and-chapter form like Tex. Prop. Code, and a bare "section 1983" all have to land on the right section in the right code, and getting it wrong is worse than returning nothing. The citation formats reference lists the forms we parse.

We learned that the hard way. A live sweep found that one state's own published citation abbreviation was missing from our abbreviation map, so the corpus resolved zero percent of a form that state prints on its own pages. Round-tripping every published abbreviation is now a test rather than a hope. Legal Citation Resolution: Turning a Cite Into the Right Section, Every Time walks the rest of that surface.

5. There is no change detection or webhooks

govinfo tells you what it currently holds. It does not tell you that a CFR section your product depends on changed since your last sync, and it does not push you a diff.

Building this means keeping your own prior state, re-pulling on a cadence per corpus, diffing at section granularity, and suppressing the enormous amount of noise that comes from a publisher restyling a page. In our own change-capture audit, a large share of raw "amendment" signals turned out to be false: stacked live generations of the same document rather than real substantive edits. Detection is easy. Detection you can trust is not, as How We Know a Law Changed: Boards, Diffs, and the False Positives Nobody Talks About sets out.

6. There is no normalized schema across corpora

A US Code section, a CFR section, a Federal Register final rule, an executive order, and a state insurance bulletin have almost nothing in common in their native formats. If you want one code path over all of them, you invent a schema and map five sources into it. Ours settles on one section shape per token in the corpusType reference.

Then you maintain that map. Forever. Through site redesigns.

7. There is no stable identifier that survives renumbering

Position in a document tree is not an identity. Sections get renumbered, moved between chapters, and repealed with their numbers reused.

Anything keyed on "title 42, chapter 21, the fourth section" breaks quietly on the next release. You need an identifier that is assigned once and stays put, and no government publisher issues one across corpora.

A worked example: the same section, two ways

Take 42 U.S.C. 1983, the civil rights cause of action.

The govinfo path. Identify the USCODE package for the right edition, request the granule map, find the granule for Title 42 chapter 21 section 1983, fetch the USLM XML, parse the section node, strip the notes you do not want, and keep the source citation credit if you want the amendment history.

The API path. Search or resolve, take the actId off the response, and fetch it:

GET /api/v1/us/statutes/section/USC_T42_C21_S1983
Authorization: Bearer vq_key_...

USC_T42_C21_S1983 is a real identifier in our corpus, and so is SAL_PL116-136_DVA_TII_S1109, which is section 1109 of the CARES Act as enacted. The pattern looks guessable and is not. Hand-built ids usually 404, on purpose, because a guessable id invites a caller to construct a citation that does not exist and get a plausible answer back.

The difference is not that one is possible and the other is not. Both work. The difference is which one you want to still be maintaining in eighteen months.

What you are actually paying for

Strip the marketing and the value is five things, none of which is the text.

• Normalization. One schema over the US Code, the CFR, the Federal Register, session laws, agency guidance, and 52 state publishers.
• Indexing. 4,150,839 distinct sections indexed as 12,003,716 retrieval passages, because long documents split into several passages for retrieval and a section is still one citable item.
• Citation resolution. Messy human citation strings mapped to a specific section, with a published failure mode instead of a guess.
• Versioning. Amendment history and a lastAmendedYear per section, plus yearFrom and yearTo filters that track the publisher's own amendment credit rather than a vendor's rebuild date.
• Change detection. A per-corpus refresh cadence, change events captured per refresh, and per-section diffs on watched boards.

Refresh cadence is the part you cannot fake

Cadence is where "we have the data" and "we have current data" separate. Ours, per federal corpus:

The US Code line is the honest one. The 2024 edition is current through 2025-01-06, because that is what OLRC has published. A weekly check does not make an annual publication weekly, and any vendor implying otherwise is describing their crawler rather than the law. The status and currency reference defines currentThrough and goodLawStatus.

Where we carry gaps, and say so

A provider that reports 100 percent coverage of American primary law is either not measuring or not telling you. Ours:

• Paused corpora are declared, with reasons. A paused corpus is complete and officially sourced but not currently re-pulling, most often because the publisher's own access rules require it.
• Six jurisdictions have no court rules, each for a different reason. Arkansas and Vermont publish only the amendment stream, with consolidated text available from a commercial licensee. Colorado publishes only rule-change orders, and its last government compilation is 2023, so ingesting it would serve superseded procedure as current law. Oklahoma and South Dakota codify their rules into the statute book, so they are already served. Missouri's published judiciary policy does not permit automated access, and we honor it.
• State insurance bulletins are a pilot, 49 jurisdictions and landing state by state, not a finished rollout.

Every one of those pauses is declared in the API response itself. GET /us/statutes/coverage is free and returns per-jurisdiction counts, a freshness array with each pause and its reason, a currency block describing what each corpus is current through in the publisher's own words, and a measuredAt timestamp. GET /boards is also free and lists every watchable source with its lastRetrievedAt and retrievalStatus.

The middle path: run the pipeline yourself

The parsers, scrapers, and JSONL schema behind this corpus are open source at github.com/Vaquill-AI/open-us-law under a permissive license, with a summary at open-us-law.

That exists for a specific reason. A vendor should not be the authority on what the law says. If you want the ingestion without the API, take it. If you want to check how a particular state's text was extracted before you trust a result, read the parser.

Every result we serve also carries the official source URL for the publisher's own copy, so the last step of any verification is a link back to the government, not to us.

The honest verdict

Use govinfo if you are federal-only, comfortable with XML, and your dataset does not need to be current to the day.

Use the eCFR directly if regulations are your whole product and you want the amended-to-date text from the office that publishes it.

Buy an API if you need state law, if you need one query across corpora, if you need arbitrary citations resolved, or if change detection is a feature your customers see. Those four are where the free path turns into a team.

Buy nothing yet if your real requirement is point-in-time retrieval, because that is a different product than any of the above.

FAQ

Is govinfo.gov free to use commercially?

Yes. Federal primary law is in the public domain, and govinfo publishes it under a free api.data.gov key. The cost is engineering time, not licensing.

Does govinfo have an API that returns a statute section as JSON?

Not by citation. The govinfo API is package and granule oriented, so you request a manifest of files and then the files, which are USLM XML rather than JSON objects keyed by citation. Turning that into a per-section JSON lookup is work you do on your side.

Where do I get state statutes in bulk?

There is no single source, because there is no federal publisher of state law. You go to each of the 52 jurisdictions separately, and formats range from clean bulk exports to paginated HTML to PDF prints of bound volumes. That is roughly 1.93M statutory sections and another 1.46M regulatory sections to normalize.

What is the difference between the eCFR and the annual CFR on govinfo?

The eCFR is the CFR as amended to date and updates continuously. The annual CFR edition on govinfo is a snapshot as of a fixed revision date per title. Use the eCFR for current obligations and the annual edition when you need the official printed edition.

Can I ask a legal data API for the text of a statute as it read on a past date?

Versioning here runs off the amendment record rather than a date parameter. One citation returns one text, the current one, with amendment history, a lastAmendedYear per section, yearFrom and yearTo currency filters, and per-section diffs on watched boards around it. An as_of=DATE historical query does not exist, and you should confirm with any vendor whether theirs is real or reconstructed.

How current is the United States Code?

The edition we serve is the 2024 edition, current through 2025-01-06, which is what OLRC has published. Enacted law that has not yet been codified lives in the Statutes at Large, which is why we index public and private laws as enacted separately, 5,256 laws across the 113th to 119th Congresses.

Why would a legal data provider have gaps if the law is public?

Because some publishers opt out of automated access, some publish only through a commercial licensee, and some publish only a change stream rather than consolidated text. A provider can fill those gaps from an aggregator or declare them. We declare them, in the coverage response, with the reason attached.

What should I check before making a legal data API a dependency?

Five things: where each source comes from and whether the publisher's own URL travels with the result, how often each corpus refreshes and what it is current through, whether citation resolution has a published failure mode, whether the schema is stable across corpora, and whether change detection is real diffing or just a re-crawl timestamp. Coverage size is the least informative number on the page.

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.