GovInfo API vs a Legal Data API: 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 doesn't 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

Reviewed and corrected on 6 October 2026: GovInfo's rate limits and the refresh-cadence table were re-checked against GovInfo's own documentation and the live service.

• 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 isn't 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.48M 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: 222,311 Federal Regulation Sections, Refreshed Daily and Federal Register API: Querying Over 196,000 Final and Proposed Rules. For the side govinfo doesn't 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-10-04. 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 aren't 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 can't 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.

A short history: how the free archive got this good

The free archive has a long history, and knowing it explains both its strengths and its seams. According to GPO's own timeline, Congress passed the GPO Electronic Information Access Enhancement Act (Public Law 103-40) on June 8, 1993, and GPO Access launched a year later. It was subscription-only for most users until December 1995, when it became free to everyone. Its successor, the Federal Digital System, arrived as a beta on January 15, 2009. In October 2009 GPO and the National Archives converted the Federal Register into XML for bulk download, which GPO calls its first XML bulk data set. FDsys replaced GPO Access as the system of record in December 2010, and GPO Access was sunset in March 2012.

The part developers care about is newer. GPO joined GitHub in March 2015, and eCFR XML bulk data followed in August 2015. The redesigned GovInfo site launched in beta on February 3, 2016. The GovInfo API arrived in June 2018, described as allowing users "to programmatically retrieve new and updated content and metadata." The first beta USLM files, for enrolled bills, public and private laws and the Statutes at Large, followed in October 2018, and the old FDsys interface was retired that December. On June 8, 2023, the thirtieth anniversary of the Act, GPO recorded its ten billionth retrieval since the law was enacted.

So the data has a thirty-year pedigree, and the API is a little over eight years old. That helps explain why it reads as an archive first and an API second. It was a very good archive for a long time before it had an API.

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.

GovInfo does have a link service for this. A GovInfo staff member explained in a 2025 reply that a URL of the form https://www.govinfo.gov/link/uscode/{title}/{section} makes "durable links to parts of the US Code" for the latest edition or a specified year (GitHub, February 2025). That is genuinely useful for linking out. It resolves a title and section to a document you can open, and it stops short of a JSON record with the section's text, hierarchy and status.

2. There is no cross-corpus search

The federal government doesn't 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 more than 1.5 million sections across 15 corpora, of which the US Code is 60,000+ and the CFR is 222,000+. State law is more than twice 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 doesn't tell you that a CFR section your product depends on changed since your last sync, and it doesn't 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 isn't, 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 isn't 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.

What developers say

The best evidence for this post's thesis comes from GovInfo's own public issue tracker, where the staff are generous with answers.

In February 2019 a developer building a tool to download documents cited in law review articles asked for a way to retrieve a range of US Code sections, since such articles "frequently cite a range of US Code sections." The reply, from the GovInfo side, said it "would seem that you could accomplish this functionality by building a service that would take the citation (e.g. 29 U.S.C. §§ 201-219) and then programmatically create link service links for all of those sections, inclusive" (GitHub, April 2019). That is a polite, accurate way of saying the citation layer is yours to build. It is the same line this post draws.

A slower example is a 2023 request to have the granules of a title returned in sequential order. Staff replied, checked, and offered a workaround in the metadata files, then wrote in April 2024 that they were "bumping this up in priority." In March 2025 they said they would take another look "in our next release," and in April 2025 that a fix was lined up for the June release (GitHub, 2023 to 2025). The replies were courteous, and the first one came with a workaround. The issue is still marked open. Public infrastructure moves at its own pace, and that is worth budgeting for if your product's roadmap depends on a fix.

The free tier has its own arithmetic. GovInfo's own README lists the default limits for a key as 36,000 requests per hour (tracked on a rolling hourly basis), 1,200 per minute and 40 per second (usgpo/api README). The generic api.data.gov manual gives a lower default of 1,000 requests per hour and says "rate limits may vary by service", so read the service's own page. The shared demo key in documentation examples is much lower: 30 requests per hour and 50 per day per IP address (api.data.gov developer manual). At GovInfo's 1,200 per minute ceiling, ten thousand one-section requests take under ten minutes. That is comfortable for a nightly job, and you still need to handle the 429 response when you pass the limit.

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 don't 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 isn't. Hand-built ids usually 404, on purpose, because a guessable id invites a caller to construct a citation that doesn't exist and get a plausible answer back.

The difference isn't that one is possible and the other isn't. 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 56 state publishers.
• Indexing. More than 5 million distinct sections indexed as more than 19 million 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, as declared on GET /boards (read that call for the live cadence and for lastRetrievedAt):

The US Code line needs a caveat. We check the source weekly, but OLRC decides when new text exists, and a refresh schedule does not make a publisher's release schedule faster. Any vendor implying otherwise is describing their crawler rather than the law. Read the currentThrough date on the section instead: a live lookup of 42 U.S.C. 1983 on 6 October 2026 returned currentThrough 2026-09-18. 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:

• A cadence is a schedule, and it does not promise the last run worked. GET /boards returns lastRetrievedAt next to cadence, so compare the two yourself before you treat a source as current.
• Two jurisdictions have no court rules, each for a different reason. Vermont publishes its amendment stream, with consolidated text available only from a commercial licensee. Missouri's published judiciary policy doesn't permit automated access, and we honor it. The other 50 jurisdictions carry court rules.
• State insurance bulletins are a pilot, 49 jurisdictions and landing state by state, not a finished rollout.

The coverage numbers and currency dates are readable in the API itself. GET /us/statutes/coverage is free and returns per-jurisdiction counts by corpus and a measuredAt timestamp, and where a publisher states what its text is current through, that rides on each section as currentThrough. GET /boards is also free and lists every watchable source with its cadence and lastRetrievedAt.

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 doesn't 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.

Test before you buy if your real requirement is point-in-time retrieval. asOf returns a held published edition for the CFR annual editions and a reconstruction bounded by when we began capturing changes everywhere else, so run it against the dates you care about and read the asOf block on each answer.

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 56 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.48M 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?

Yes, with a caveat. A citation returns the current text by default, and asOf=YYYY-MM-DD on the section body endpoint returns an earlier one. For the CFR annual editions that is a published edition we hold, and a date between held editions comes back out of coverage. For other corpora it is a reconstruction from changes we recorded, and a date before capture can come back unavailable. Around it sit amendment history, a lastAmendedYear per section, yearFrom and yearTo currency filters, and per-section diffs on watched boards. Confirm with any vendor whether theirs is a published edition or a reconstruction.

How current is the United States Code?

Each section carries a currentThrough date taken from the OLRC release it was read from. A live lookup of 42 U.S.C. 1983 on 6 October 2026 returned currentThrough 2026-09-18, and the refresh cadence is listed on GET /boards. Enacted law that hasn't yet been codified lives in the Statutes at Large, which is why we index public and private laws as enacted separately, 425,000+ sections spanning 1789 to 2026.

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, with the reason attached, in the coverage docs.

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 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.