US Statutes API: The 2026 Guide to USC, CFR, and State Code Access

Short answer: there is no single official US statutes API that returns a US Code section as clean JSON by citation. You have four real options. govinfo.gov publishes annual editions of the Code free (HTML, PDF, and metadata per title), and the House Office of the Law Revision Counsel publishes USLM XML release points you parse yourself. congress.gov is built for bills as they move through Congress, while the enacted Code lives elsewhere. Cornell LII publishes a free, browsable HTML version. A commercial US statutes API (like Vaquill AI) maps a citation to a stable actId and returns structured JSON across USC, CFR, and state codes. The right pick depends on whether statute text is your product or just an input to it.

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

TL;DR

• A "US statutes API" maps to four stacks: govinfo and OLRC downloads, the congress.gov legislative API, Cornell LII's HTML reading site, and commercial per-section JSON APIs.
• govinfo and OLRC are the authoritative free sources, but you index the files or parse the XML yourself. congress.gov tracks bills and Public Laws as they move, while the integrated Code is published separately. Cornell LII is the free site most people read the Code on. Commercial APIs hand you a section as JSON for a per-call fee.
• The trade-off is the same shape every time: freshness, structure, and convenience. Pick the option whose pain matches the pain you are willing to absorb.
• The non-obvious gotcha is not retrieval. It is the lag between a Public Law landing and the OLRC integrating it into the Code, and the difference between positive-law and non-positive-law titles when you cite.
• Need the step-by-step how-to instead of the overview? See the companion USC API: how to pull US Code sections programmatically.

Part of our MCP and developer guide series.

If you are still deciding what kind of legal API you need at all, start with Legal API in 2026: what it is, what it returns, and how to pick one. The market view is in the best legal data APIs for developers, and searching US statutes and regulations with AI covers the amendment angle.

The options at a glance

Four ways to get US statutes into your code, side by side. Section counts for the commercial column are Vaquill AI's own published figures (October 2026); the federal sources are public domain.

Why this is harder than it should be

There is no first-class JSON API for the United States Code published by the federal government. There are several publishers, several formats, and several philosophies.

The Office of the Law Revision Counsel (OLRC) of the U.S. House of Representatives is the editorial authority. OLRC takes Public Laws as enacted by Congress and integrates them into the codified Code, deciding which provisions go where, what gets repealed, what gets renumbered.

OLRC publishes the result on uscode.house.gov. Its download page offers each title, or all titles in one zip, as USLM XML, XHTML, PCC (photocomposition codes) and PDF, by release point. It is a set of files, not a query endpoint.

The Government Publishing Office (GPO) runs govinfo.gov, which publishes annual editions of the Code and also exposes a developer API keyed off api.data.gov. That API is package and granule oriented, which is GPO's term for "give me a manifest of files, then download the files." It is a wonderful archive. GovInfo's search and its link service can find a section from its citation, but what comes back is a document (a PDF or HTML file) and not a record.

The Library of Congress runs congress.gov and an associated API that is genuinely good at bills and Public Laws as they move through Congress, plus committee reports and the Congressional Record. It is not really an enacted-USC API.

Cornell's Legal Information Institute takes the official data and republishes it: a free, browsable HTML version of the Code. It is a reading site without a per-citation query API.

The whole reason this post needs to exist is that "US statutes API" maps to several different stacks depending on what you actually need.

The right move is to figure out which one of those four you want before you write any code, because the wrong choice is the kind of mistake you discover after you have already shipped an integration on top of it.

A short history: why only part of the Code is law

Congress has tried to tidy its own statutes more than once, and the way those attempts stalled explains the positive-law split you keep running into.

The first big try was the Revised Statutes, enacted in 1874. It ran to 74 titles and repealed the laws that had been enacted up to December 1, 1873, so the new book simply replaced them. A second edition followed in 1878 to remedy problems in the first, but it left the underlying laws on the books and didn't pick up anything newer. Work on a reorganization into 50 titles began in 1919 and 1920, and the resulting bills passed the House in three Congresses and failed in the Senate. (These details come from the slides for a January 29, 2025 webinar, An Inside Look at the United States Code, given for the Federal Depository Library Program by the Law Revision Counsel.)

The compromise arrived in 1926. The Code was adopted rather than enacted: the underlying statutes were not repealed, the Code counted as prima facie evidence of the law, and Congress said titles would be enacted into positive law one at a time. GovInfo says the Code was first published in 1926, that the next main edition came in 1934, and that main editions have followed every six years since, with annual supplements in between. Its help page, last updated in February 2025, lists the titles that have made the jump: 27 of them. Everything else is, in GovInfo's words, "only prima facie evidence of the law," and "the Statutes at Large still govern." The same webinar slides add that the 27 positive-law titles account for only about 25% of the Code's content.

Then there's the office itself. The old Committee on Revision of Laws, which ran from 1868 to 1946, was folded into the House Judiciary Committee in 1946. In 1974 Congress created the Office of the Law Revision Counsel, which is where the modern Code comes from. The statute that governs it, 2 U.S.C. § 285a (Public Law 93-554, December 27, 1974), says: "The principal purpose of the Office shall be to develop and keep current an official and positive codification of the laws of the United States." In January 2025 the office described itself as a team of 17, with 7 attorneys who maintain the Code and 4 who prepare positive-law codification bills.

The rule you can quote comes from 1 U.S.C. § 204(a). The Code establishes the law prima facie, "Provided, however, That whenever titles of such Code shall have been enacted into positive law the text thereof shall be legal evidence of the laws therein contained." Two tiers, one proviso.

A quick story: the appeal that wasn't there

What does "prima facie" cost in practice? In 1943 a man named Stephan, convicted of treason and sentenced to death, asked the Supreme Court for a direct appeal. He pointed to a section printed in the 1940 edition of the Code as 18 U.S.C. § 681. The trouble was that, as the Court put it, "since 1911 the statutes have not authorized a direct appeal to this Court in capital cases." The section had stuck around in the Code anyway. The Court wrote that "the words of 18 U. S. C. § 681 have lingered on in the successive editions of the United States Code" and that this was "immaterial," because "the very meaning of 'prima facie' is that the Code cannot prevail over the Statutes at Large when the two are inconsistent." The application was denied on June 1, 1943. You can read the per curiam opinion in Stephan v. United States, 319 U.S. 423.

More than eighty years on, the lesson for a developer is the same. A stale or wrong section in the Code is still a bug in the Code, and the session law is where you check.

In their words

Developers have been arguing about this for a while, and the better comments are precise about it. In 2014 a Hacker News commenter put the split this way: "Only half of the US Code is authoritative (so called 'positive law titles'). For the rest, the original statutes are authoritative." The same comment added that Congress had "recently converted the US Code into very good XML," and that anyone could "run it through diff to see changes" (joshdata, Hacker News, October 2014).

Terminology trips people up too. In April 2026 someone reading a project's readme corrected it with the statute open: "It is the positively enacted titles which are 'legal evidence of the laws'. The other titles merely 'establish prima facie' what the law is" (cvoss, Hacker News, April 2026). Read the proviso above again and you'll see why the correction is fair. "Evidence of law" sounds like the weak option and is actually the strong one.

What happens between signing and the Code

The lag is easier to live with once you know what OLRC does with a new law. By its own account, a team of attorneys reads each enrolled bill start to finish, and a lead classifier makes the final decisions, typically before the public law number is even issued. The webinar slides name four steps from there: classification, text preparation, text execution and publication. OLRC's classification tables show where recently enacted laws will appear in the Code, and its online Code is updated through a congressional session as a series of release points.

One detail matters for parsers. Not everything lands in a numbered section. OLRC's FAQ says that when a Code section or an amendment takes effect on a date other than its date of enactment, "the Code will almost always include an effective date note under the section," and that placing a provision as a statutory note "has no effect on the validity or legal force of the provision." If you only ingest the sections, you can miss binding text.

Option 1: govinfo.gov and OLRC USC downloads

This is the official, free option, and it is the one most academic and government projects end up on.

govinfo publishes the Code as annual editions in its USCODE collection, one package per title, named like USCODE-2024-title42. Each package downloads through the govinfo API (free api.data.gov key) as a zip of per-section HTML and PDF files plus MODS metadata. The newest edition on GovInfo on 12 October 2026 is 2024. The old govinfo.gov/bulkdata/USCODE/ directory no longer exists (it returns a 404), and the bulk repository's collections do not include the Code, so anything that builds a URL from that path will fail.

For XML, go to the editorial source. OLRC publishes the Code as USLM XML release points under uscode.house.gov/download.html, wrapped in a USLM document with a deep tree of subtitles, chapters, subchapters, parts, and sections. Each section carries an identifier attribute holding a URL-style path such as /us/usc/t42/s1983 (the OLRC's USLM User Guide describes it as a URL-based path reference, and GPO's USLM repository holds later schema versions). On 12 October 2026 the site carried a notice that it is "currently operating in a temporary format", with the Code online current through Public Law 119-120 (October 7, 2026), so check the download page before you plan around it. Our guide to parsing the XML runs a parser on that release point.

What you get is genuinely good data: section text, source credits, amendment notes, and cross-references to other sections. The mapping from a new public law to its place in the Code is published separately, as OLRC's classification tables.

What you pay for it is process.

Update cadence. OLRC's download page says, "Each update of the United States Code is a release point," with every file current through a stated public law (the 119-120 file was posted on 11 October 2026; the download page we read the same day still listed 119-118, so check which release point you are getting). The printed main editions come on a much slower rhythm.

That cadence is slower than federal law actually moves. A Public Law signed yesterday will not be in the USC XML you download today.

Format. If you take the OLRC XML, USLM is well designed but it is a full document model. You will parse a tree, model the hierarchy, hold every section's identifier in a lookup, and write the logic that resolves a citation like 42 U.S.C. § 1983 to the right node. None of this is hard. It is just labor you have to do once and then maintain.

No per-section freshness. Bulk XML is a snapshot. The download page marks the titles that changed since the last release point in bold, which tells you which title files to fetch again. To know whether one section's text changed, you diff your snapshots.

The honest pros and cons. Pros: it is the source of truth, it is free, and you own the data. Cons: you own the data, which means you also own the parser, the storage, the search, the diffing, the alerting when OLRC ships a new release.

If your product is USC ingestion, this is correct. If your product uses USC ingestion, this is a tax.

Option 2: congress.gov / Library of Congress API

The Congress.gov API requires a free key (you sign up on api.congress.gov, no sales call) and is the right answer for one specific question: what is happening in Congress right now. Its documentation sets the rate limit at 5,000 requests per hour.

If you want to watch a bill as it moves from introduction through committee through floor vote through Public Law, this API is excellent. Endpoints exist for bills, amendments, committee reports, the Congressional Record, hearings, nominations, treaties, and members. The data is fresh because it is tied to legislative activity, not to OLRC's editorial cycle.

If you want enacted USC sections specifically, this API is the wrong tool. It follows bills and the laws they become, which means you get the text of a public law such as Pub. L. 118-XXX rather than the integrated USC section that text amended.

The two are not the same. A Public Law often touches a dozen scattered USC sections across multiple titles, and you would have to do OLRC's editorial integration yourself to land back at "give me the current text of 42 U.S.C. § 1983."

The split is worth being precise about, because plenty of developers reach for the congress.gov API thinking it will give them current USC and end up confused.

Congress.gov is for the legislative process. OLRC and govinfo are for the codified result. Use both if you need both. Do not substitute one for the other.

Option 3: Cornell LII

Cornell's Legal Information Institute is the free site most people already read the Code on. For developers, it is best treated as a reference for checking what a section says rather than as a data feed.

What you get is a clean, deeply linked HTML reading experience at predictable addresses such as law.cornell.edu/uscode/text/42/1983. The pages are made for readers, and LII is run from Cornell Law School, so treat it as a free reading source rather than a data vendor.

LII's annotations and cross-linking are excellent for humans. For a machine pipeline, start from govinfo or OLRC and keep LII as the page you point a person at.

If you are choosing for a bulk job, govinfo's dated annual editions and OLRC's release points are easier to cite in a paper, and LII is easier to point a human at. None of the three turns 42 U.S.C. § 1983 into a JSON record on demand.

Option 4: a commercial statutes API

The fourth path is to let somebody else absorb the parsing, hierarchy modeling, search, and currency, and pay for structured JSON delivered by citation. This is the only option that returns a section by citation as a record.

A representative commercial option covers the full US Code (60,494 sections) and the Code of Federal Regulations (222,311 sections), plus state statutory codes for 56 jurisdictions (the 50 states, DC, Puerto Rico, Guam, the Northern Mariana Islands, the US Virgin Islands and American Samoa). Refresh is set per source: the CFR, executive orders and the Federal Register daily, the US Code weekly, and state regulations, court rules and constitutions monthly.

The weekly check for the US Code fits the source, because each OLRC release point is labeled with the public law it is current through. How the cadence works across sources is covered in Why Legal Data Cannot Refresh Faster Than Its Publisher.

This API is self-serve: you sign up and see current rates in your dashboard, no sales call. Its public surface is built around primary law found by citation: search, section metadata, section text, citation resolving and a set of related lookups, across statutes, regulations, court rules, constitutions, agency guidance and session laws.

The framing is not "this is better than govinfo." Govinfo is the source. The framing is that if you would rather not maintain a USLM parser forever, somebody already maintains one.

Code examples

Two side-by-side flows, both in Node/TypeScript. The first downloads a govinfo title edition; the second hits a structured statutes API. We ran the govinfo summary request on 12 October 2026 with the shared DEMO_KEY (it returned 200 with the fields the snippet reads). The zip download was not run, and neither was the Vaquill snippet end to end, because it needs an API key. The Vaquill field names below come from the live OpenAPI document and a real response pulled on 12 October 2026.

Govinfo: download a USC title edition

import { writeFile } from "node:fs/promises";

const TITLE = 42;
const EDITION = "2024";
const KEY = process.env.GOVINFO_API_KEY!; // free api.data.gov key

// Annual editions of the Code are govinfo packages named USCODE-<year>-title<N>.
const pkg = `USCODE-${EDITION}-title${TITLE}`;

// 1) Confirm the package exists and see what it offers.
const summary = await fetch(
  `https://api.govinfo.gov/packages/${pkg}/summary?api_key=${KEY}`,
);
if (!summary.ok) throw new Error(`govinfo summary failed: ${summary.status}`);
const { title, dateIssued, download } = await summary.json();
console.log(title, dateIssued, Object.keys(download));

// 2) Download the whole title as a zip: HTML and PDF per section plus metadata.
const zip = await fetch(
  `https://api.govinfo.gov/packages/${pkg}/zip?api_key=${KEY}`,
);
if (!zip.ok) throw new Error(`govinfo zip failed: ${zip.status}`);
await writeFile(`${pkg}.zip`, Buffer.from(await zip.arrayBuffer()));

That snippet gets you one official annual edition of one title, and it leaves out the realistic parts: the zip is large for a title like 42 (its package summary lists 9,364 pages), the sections inside are individual HTML files named by chapter and section rather than by citation, and the year in the package name is the edition, so you need your own index from a citation like 42 U.S.C. § 1983 to a file, and your own plan for the time between editions. Check the USCODE collection for the newest edition before you hard-code a year (on 12 October 2026 the newest on GovInfo was 2024). DEMO_KEY is shared and tightly limited, and the first attempt that day came back with a 429 (OVER_RATE_LIMIT), so get your own free key. Treat the snippet as the shape, not the production code.

Statutes API: search and fetch a section

const API = "https://api.vaquill.ai/api/v1/us";
const KEY = process.env.VAQUILL_API_KEY!;

// 1) Search the US Code for a concept.
const search = await fetch(`${API}/statutes/search`, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ query: "wire fraud", corpusType: "USC" }),
});
const { results } = await search.json();
const top = results[0];
// top has actId, citation, title, titleNumber, corpusType, breadcrumb (a list), excerpt
// e.g. actId: "USC_T18_C63_S1343", citation: "18 U.S.C. § 1343 (2026)"

// 2) Fetch the full text of the section by its stable actId.
const body = await fetch(
  `${API}/statutes/section/${top.actId}/body`,
  { headers: { Authorization: `Bearer ${KEY}` } },
);
const section = await body.json();
console.log(top.citation, "\n", section.plain);

The actId is the stable key. Take it from the search response (the convention is USC_T<title>_C<chapter>_S<section>); never hand-build it.

The shape difference is the whole point. The govinfo path gives you files to index; the commercial path gives you a record. Both end at "I have the section text in memory."

The cost is what differs: the download is free in dollars and expensive in engineering, the API call is the inverse.

Decision framework

The decision is not "which is best." It is "which pain matches the pain you are willing to absorb."

Congress.gov is for the legislative process. OLRC and govinfo are for the codified result. Use both if you need both.

Building a research product. Commercial API. You are going to ship features on top of the statutes layer, and you do not want to spend a quarter on a parser before you ship anything. Our roundup of the best legal data APIs for developers lists the vendors in this category.

Building a one-shot academic dataset. Govinfo or OLRC downloads. You need a dated snapshot you can cite in a paper, you do not need ongoing freshness, and you do not want to pay for what you can download. OLRC's release notes are your citation.

Tracking bills as they move through Congress. Congress.gov. The Library of Congress API is built for legislative activity and is genuinely good at it.

Tracking enacted updates over time. Either govinfo plus your own diffing pipeline, or a commercial API that already tracks amendment state per section.

The govinfo path requires you to fetch each release, diff against the prior, classify what changed, and surface that to your users. That is real ongoing engineering. If it is not your product, buy the layer.

Doing all three at once. Most production systems end up here. They pull bills from congress.gov for the watch-list, lean on a commercial statutes API for the codified read path, and keep a periodic govinfo snapshot around for audit and provenance.

The 50-state problem nobody warns you about

Federal is the easy part. The moment your product needs state statutes, the four-option picture collapses to one.

There is no government API for the 50 states. Each state publishes (or does not publish) its own code on its own terms, in its own format, on its own schedule. Some ship clean XML. Some ship a search box over a vendor platform. Some ship PDFs. None of them agree on a citation model.

So if you need, say, California Penal Code and Texas Business and Commerce Code in the same query layer as the USC, govinfo, OLRC, congress.gov and Cornell LII all stop short. They are federal. You either build 50 scrapers and maintain 50 currency pipelines, or you buy a layer that already joined them under one schema.

This is where the commercial option stops being a convenience and starts being the only realistic path. A representative aggregator covers state codes for 56 jurisdictions (the 50 states, DC, Puerto Rico, Guam, the Northern Mariana Islands, the US Virgin Islands and American Samoa) behind the same corpusType=STATE search and the same actId lookup you use for federal. You discover what is covered with one free call: GET /us/statutes/coverage lists every jurisdiction with its per-corpus counts.

Gotchas the docs do not lead with

Four things bite people. Knowing them in advance turns each from a bug into a design decision.

Positive-law versus non-positive-law titles. The USC is split into titles Congress has enacted as positive law (Title 1, Title 4, Title 11, Title 17, and a couple of dozen others) and titles that remain a prima facie codification of underlying Public Laws.

For positive-law titles, you cite the USC directly. For non-positive-law titles, the USC is technically a convenient reorganization of the Statutes at Large, and in rigorous practice the underlying Statutes at Large language controls.

Practically every brief still cites the USC, but it matters when you are building a verification path for citations, and any serious statutes layer should surface which side of the line a title sits on. The OLRC keeps a positive law codification table at uscode.house.gov/codification/legislation.html that is the canonical reference.

Sections get renumbered, transferred and repealed. It is rare but real. A reorganization act can move a chapter, leaving the old section marked repealed, omitted, transferred or renumbered. The Code's status values are an attribute you have to read, not something you can infer from the text.

If your parser models sections by their slot in the hierarchy rather than by an identifier, your old citations will silently break after a release point. Key records on the identifier path (such as /us/usc/t42/s1983) together with the release point they came from. Each section also carries a separate id, which the USLM User Guide describes as an unchanging identifier assigned when the element is created. We have not checked how stable those values are across release points.

Binding text can sit in notes. As the OLRC FAQ says, a provision placed as a statutory note has the same validity and legal force as one classified as a section. A pipeline that keeps only numbered sections will drop effective-date notes.

Public Laws lag USC integration. If a section looks out of date right after a new law, check this first. A Public Law was signed three weeks ago, a user expects the USC text to reflect it, but OLRC has not yet published the release point that integrates the amendment.

This is not an API bug. It is the federal codification cycle. The fix is to surface "amended by Pub. L. XXX-YY, not yet integrated" alongside the section, drawing from the congress.gov side of the stack. Whichever option you pick, model this lag explicitly.

The throughline of those four: structured statute data is harder than the file downloads suggest, the cliff is the editorial cycle rather than the format, and the value of paying for a statutes layer is mostly that somebody else watches that cliff for you.

Which option should you pick?

If statute text is your product, run your own pipeline over govinfo or OLRC downloads and own it forever. If you are tracking the legislative process, use congress.gov. If statutes are an input to your product (a contract tool, a compliance checker, a research assistant), reach for a commercial US statutes API so you get a section by citation as JSON and skip the parser.

We build the Vaquill AI statutes API, which is the structured-JSON option in the table above: search, fetch metadata, fetch body across USC, CFR, and state codes, with a stable actId per section. It is self-serve, so you sign up and see current pricing in your dashboard, or email contact@vaquill.ai. It is scoped to primary law found by citation (statutes, regulations, court rules, agency guidance), so court opinions come from a different kind of source.

If you want the step-by-step requests, the USC API how-to walks through every call. For the broader market, see the best legal data APIs for developers and the longer API call versus RAG pipeline cost comparison.

FAQ

Is there an official US statutes API? No. The federal government publishes the United States Code as USLM XML, XHTML, and PDF (OLRC) and as annual-edition HTML and PDF (govinfo) and exposes a legislative API at congress.gov for bills, but there is no official endpoint that returns a USC or state-code section by citation as JSON. Commercial APIs fill that gap.

What is the best API for the US Code? It depends on the job. For a free, authoritative download, govinfo.gov or OLRC. For bills moving through Congress, the congress.gov API. For per-section JSON you can query by citation without maintaining a parser, a commercial statutes API such as Vaquill AI.

Is the govinfo API free? Yes. You sign up for a free api.data.gov key, and the data itself is public domain. The catch is format: govinfo is organized around packages and granules and returns download links to HTML, PDF, and MODS rather than parsed per-citation JSON.

Can I get all 50 state statutes from one API? Not from the government. Each state publishes its own code in its own format, so there is no federal 50-state endpoint. Commercial aggregators join state codes under one schema. Vaquill AI, for example, covers state codes for 56 jurisdictions (the 50 states, DC and five territories) behind one corpusType=STATE search.

What format is the US Code published in? USLM (United States Legislative Markup) XML, plus XHTML, PCC and PDF. The OLRC's USLM User Guide says USLM is not defined as a derivative or subset of Akoma Ntoso, the international LegalDocML standard, but is designed to be consistent with it where practicable. It models the full document hierarchy, so a single title is a deeply nested tree of subtitles, chapters, parts, and sections.

What is the difference between congress.gov and a USC API? Congress.gov is for the legislative process: bills, amendments, Public Laws, the Congressional Record. A USC or statutes API is for the codified result: the current, integrated text of a section by citation. A single Public Law touches scattered USC sections, so you cannot substitute one for the other.

How do I get the current text of a US Code section? Currency is the catch. The Code changes as Congress acts, and OLRC integrates Public Laws on its own editorial cycle, so a Public Law signed last month may not be in the published text yet. Whatever source you use, confirm the "as of" date and surface any pending, not-yet-integrated amendments.

Do I need a stable ID to fetch a section? With OLRC's USLM XML, you key off the identifier path (not the node's position in the tree, which can shift on renumbering) and record the release point. With a commercial API, you key off the provider's stable id (Vaquill AI calls it actId, formatted like USC_T42_C21_S1983). Take the id from a prior response; never hand-build it.

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.