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 ships free, authoritative USLM XML 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 bulk XML mirror. 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.

TL;DR

• A "US statutes API" maps to four stacks: govinfo bulk USLM XML, the congress.gov legislative API, Cornell LII's bulk XML mirror, and commercial per-section JSON APIs.
• govinfo is the authoritative free source, but you parse and stitch the XML yourself. congress.gov tracks bills and Public Laws as they move, while the integrated Code is published separately. Cornell LII mirrors the Code in XML for download. 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.

For related coverage, see Legal API in 2026: what it is, what it returns, and how to pick one and the best legal data APIs for developers, and searching US statutes and regulations with AI.

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 (June 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 as bulk USLM XML, XHTML, and PDF. It does not publish a query API. The reason is institutional: OLRC's job is editorial, not developer relations.

The Government Publishing Office (GPO) runs govinfo.gov, which mirrors OLRC's outputs 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. It is not a clean per-citation lookup.

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, plus a bulk XML mirror derived from the GPO locator data. It is a reading and download 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 three 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.

Option 1: govinfo.gov USC bulk data

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

Bulk USC downloads live at https://www.govinfo.gov/bulkdata/USCODE/. The directory tree is organized by year of release, then by title.

A typical artifact is usc{title}.xml (for example, usc42.xml for Title 42), wrapped in a USLM document with a deep tree of subtitles, chapters, subchapters, parts, and sections. Each node carries an identifier attribute that follows the URN:LEX convention OLRC uses (documented in the USLM schema at uslm.house.gov).

What you get is genuinely good data: section text, source credits ("Pub. L. 99-372"), amendment notes, cross-references to other titles, and the editorial classification table that maps Public Law sections to their Code home.

What you pay for it is process.

Update cadence. OLRC ships a full Code refresh a few times per year, typically tied to a release point (a stated cutoff date of laws integrated through that day). Between full refreshes you get point-in-time updates as titles are individually republished, often after a major Public Law is integrated.

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. 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-call freshness. Bulk XML is a snapshot. If you want to know whether section text changed between releases, you diff your snapshots. There is no If-Modified-Since story for individual sections.

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 Library of Congress API requires a free api.data.gov key (sign up takes a minute, no sales call) and is the right answer for one specific question: what is happening in Congress right now.

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, 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 exposes Public Laws as enacted, which means you get the slip-law text of 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 bulk XML

Cornell's Legal Information Institute is the free site most people already read the Code on. For developers, it also publishes a bulk XML mirror of the Code derived from GPO locator data, which has been a community fixture for years.

What you get is a clean, deeply linked HTML reading experience and a downloadable dataset. What you do not get is a per-citation query API or a service-level guarantee. LII is a public-service nonprofit at Cornell Law School, so treat it as a free source rather than a data vendor with an SLA.

Treat LII the way you treat govinfo: a free, authoritative-ish source you can download and parse, with the same ongoing currency and structure work on your side. The main difference is presentation. LII's annotations and cross-linking are excellent for humans; the parsing burden for machines is similar.

If you are choosing between govinfo and LII for a bulk job, govinfo's release-point dating is easier to cite in a paper, and LII is easier to point a human at. Neither one 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 (54,855 sections) and the Code of Federal Regulations (219,745 sections), plus state statutory codes for 49 states along with DC and Puerto Rico. Federal Register material that changes daily, like Executive Orders and proclamations, refreshes daily.

The statutory codes refresh on a slower cycle that mirrors federal cadence, because re-ingesting USC every day would be theater rather than freshness: OLRC does not republish that often.

Pricing in this category is typically self-serve: you sign up and see current rates in your dashboard, no sales call. The public surface is statutes and legislation only: search, fetch section metadata, fetch section text.

There is no public case-law endpoint and no public ask-a-question endpoint behind any of the commercial APIs I have audited in this segment. In-app, an AI Q&A surface often exists on top of the same corpus, but it is a product feature, not a REST endpoint.

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 hits govinfo bulk XML; the second hits a structured statutes API.

Create an API keyBook a demo

Govinfo: download a USC title XML and parse a section

import { writeFile } from "node:fs/promises";
import { XMLParser } from "fast-xml-parser";

const TITLE = 42;
const RELEASE = "2025";

// Bulk path follows the published USC release layout.
const url =
  `https://www.govinfo.gov/bulkdata/USCODE/${RELEASE}/usc${TITLE}.xml`;

const res = await fetch(url);
if (!res.ok) throw new Error(`govinfo fetch failed: ${res.status}`);
const xml = await res.text();
await writeFile(`/tmp/usc${TITLE}.xml`, xml);

const parser = new XMLParser({
  ignoreAttributes: false,
  attributeNamePrefix: "@_",
});
const doc = parser.parse(xml);

// Walk the USLM tree looking for the section identifier we want.
// The identifier convention is /us/usc/t42/s1983 for 42 U.S.C. § 1983.
function findSection(node: any, target: string): any | null {
  if (!node || typeof node !== "object") return null;
  if (node["@_identifier"] === target) return node;
  for (const v of Object.values(node)) {
    const found = Array.isArray(v)
      ? v.map((c) => findSection(c, target)).find(Boolean)
      : findSection(v as any, target);
    if (found) return found;
  }
  return null;
}

const section = findSection(doc, "/us/usc/t42/s1983");
console.log(section?.heading, "\n", section?.content);

That snippet leaves out the realistic parts: the file is multi-megabyte per title, you will want to stream rather than load it whole, and you will want to cache the parsed index in something like SQLite or a search engine so you are not re-walking the tree on every lookup. Treat it as the shape, not the production code.

Statutes API: search and fetch a section

const API = "https://api.vaquill.ai/api/v1";
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 = { actId, citation, title, titleNumber, corpusType, breadcrumb, excerpt }
// e.g. actId: "USC_T18_C63_S1343", citation: "18 U.S.C. § 1343"

// 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(section.citation, "\n", section.text);

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 a tree to walk; the commercial path gives you a record. Both end at "I have the section text in memory."

The cost is what differs: bulk XML 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. vLex (now part of Clio) and a handful of newer statutes APIs sit in this category.

Building a one-shot academic dataset. Govinfo or Cornell LII bulk. 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 and 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 49 states plus DC and Puerto Rico behind the same corpusType=STATE search and the same actId lookup you use for federal. You discover what is covered with two free calls: /statutes/states lists every jurisdiction with its section count, and /statutes/codes?state=ca lists the codes inside one state.

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.shtml that is the canonical reference.

Sections get renumbered. It is rare but real. A reorganization act can move a chapter, leaving the old section either repealed, reserved, or pointing to a new home.

If your parser models sections by their slot in the hierarchy rather than by a stable identifier, your old citations will silently break after the next OLRC release. Use the USLM identifier attribute as your key, not the position in the tree.

Section text can include strike-throughs. When a recent amendment has taken effect but OLRC has not yet integrated it into the running text, the published XML may carry strike-through or insert markup so a reader can see what changed. Naive text extraction will return the pre-amendment text. You want a markup-aware extractor that knows about the USLM change elements.

Public Laws lag USC integration. The single biggest source of "the API is wrong" support tickets. A Public Law was signed three weeks ago, a user expects the USC text to reflect it, but OLRC has not yet shipped the release 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 parser over govinfo or Cornell LII bulk XML 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. The honest tradeoff is that it is statutes and legislation only. There is no public case-law or ask-a-question endpoint, so if you need court opinions, you will need a separate 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 bulk USLM XML, XHTML, and PDF (via OLRC and 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 bulk download, govinfo.gov or Cornell LII. 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 like Vaquill AI, vLex, or OpenLaws.

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 49 states plus DC and Puerto Rico behind one corpusType=STATE search.

What format is the US Code published in? USLM (United States Legislative Markup) XML, plus XHTML and PDF. USLM is a second-generation schema derived from Akoma Ntoso, the international LegalDocML standard, and 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 bulk XML, you key off the USLM identifier attribute (not the node's position in the tree, which can shift on renumbering). 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, from the matter workbench to drafting, document comparison, document matrix, and citation-verified research.