USC API: How to Pull US Code Sections Programmatically

How to Pull US Code Sections Programmatically

Short answer: there is no official per-section US Code API. To pull a single USC section programmatically you have two real options. Use the GovInfo API (free api.data.gov key) to fetch a section as a package granule, which returns metadata plus links to HTML, PDF, and MODS files, but not clean per-citation JSON. Or use a statutes API like Vaquill AI that maps a citation to a stable ID and returns the section as structured JSON. Both are shown below. The GovInfo requests were run on 12 October 2026; the Vaquill requests show the fields of a real response from that day.

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

A common first move is to search for "United States Code API," land on the official site at uscode.house.gov, and click Download. What you get is not an API. It is files. On 12 October 2026 the download page offered the whole Code as one zip of XML (about 109 MB compressed), with XHTML, PCC, and PDF versions beside it.

That is the moment a lot of legal-tech projects quietly change shape. You wanted a clean endpoint that returns 42 U.S.C. § 1983 as JSON. Instead you inherited an XML parser, a schema spec, and a currency problem you did not know existed.

If you searched for a "usc api" and ended up here, you are in the right place. The honest answer is that the government does not publish one, and the gap between "download the Code" and "query a section" is where most of the real engineering lives.

This post is a practical walkthrough: how to pull a single US Code section programmatically with real requests, what the response actually looks like, and why pulling the section is the easy part. Keeping that section structured, cited correctly, and current is the part everyone underestimates.

TL;DR

• There is no official per-section USC API. The Office of the Law Revision Counsel (OLRC) ships the United States Code as bulk USLM XML, XHTML, PCC, and PDF downloads, whole-Code or title-by-title, as files and not as a queryable section endpoint.
• GovInfo's developer API is the closest official option. It is package and granule oriented (collections like USCODE), so a granule request returns metadata and download links (HTML, PDF, MODS), not clean per-citation JSON. A real request and response are below.
• The hard problems are not retrieval. They are mapping a citation to the right node, handling repealed and renumbered sections, resolving cross-references, and keeping currency as Congress amends the Code.
• A purpose-built statutes API turns the workflow into three primitives: search the Code, fetch a section's metadata by a stable actId, fetch its full text. The same shape extends to the CFR and state codes.
• For how to phrase the search itself (AND, OR, NOT, proximity), see the companion guide to Boolean search for legal databases. This post is about pulling and structuring the result.

Part of our MCP and developer guide series.

The wider comparison of sources is in How to Pull US Code and Statutes Programmatically: A USC API Guide, and Legal API in 2026: What It Is, What It Returns, and How to Pick One covers what these APIs return in general.

What the Government Actually Publishes

The gap between expectation and reality is the whole story here.

The official US Code is maintained by the OLRC and distributed from uscode.house.gov as bulk downloads. You can grab the entire Code or one title at a time, in USLM XML, XHTML, PCC, or PDF, by release point. There is no GET /titles/42/sections/1983 waiting for you. (The OLRC does serve each section as a web page, at an address such as uscode.house.gov/us/usc/t42/s1983/, but that is a page for a person.) Open bulk data is not the same thing as a queryable API.

USLM stands for United States Legislative Markup. The OLRC's User Guide says it 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 is well designed.

It is also a full document model, which means a single title can be a deeply nested tree of subtitles, chapters, subchapters, parts, and sections, each with its own identifiers, notes, source credits, and cross-references. A section's identifier is a URL-style path such as /us/usc/t42/s1983.

Then there is GovInfo, run by the Government Publishing Office. GovInfo does have a developer API (you authenticate with a free api.data.gov key), and it does expose the USCODE collection. This is the closest thing to a real US Code API the government ships, so it is worth showing exactly what it returns.

Pulling a section from the GovInfo API

The GovInfo API is organized around packages and granules. A package is a US Code title for a given year (USCODE-2024-title42). A granule is one section inside it (USCODE-2024-title42-chap21-subchapI-sec1983). You ask for a granule summary, you get JSON back.

curl "https://api.govinfo.gov/packages/USCODE-2024-title42/granules/\
USCODE-2024-title42-chap21-subchapI-sec1983/summary?api_key=DEMO_KEY"

That request returned 200 on 12 October 2026 with the public DEMO_KEY. The summary, trimmed to the fields that matter:

{
  "title": "Civil action for deprivation of rights",
  "granuleId": "USCODE-2024-title42-chap21-subchapI-sec1983",
  "dateIssued": "2024-12-31",
  "download": {
    "txtLink": "https://api.govinfo.gov/packages/USCODE-2024-title42/granules/USCODE-2024-title42-chap21-subchapI-sec1983/htm",
    "pdfLink": "https://api.govinfo.gov/packages/USCODE-2024-title42/granules/USCODE-2024-title42-chap21-subchapI-sec1983/pdf",
    "modsLink": "https://api.govinfo.gov/packages/USCODE-2024-title42/granules/USCODE-2024-title42-chap21-subchapI-sec1983/mods"
  }
}

DEMO_KEY is shared and allows only a handful of requests per hour (the response headers said x-ratelimit-limit: 10, and an earlier attempt that day returned 429). Get your own free key for anything real.

Two things jump out. First, the section text is not in the JSON. You get download links, and the text comes as HTML, PDF, or MODS metadata, not as a parsed field you can index. Second, the granule ID builds in the chapter and subchapter (chap21-subchapI), so you need to know it or find it. You can find it. GovInfo's search service takes a citation: a POST to /search with the query collection:uscode citation:"42 U.S.C. 1983" returned that one granule when we ran it. GovInfo also has a link service that turns a title and section into a link to the document, but that hands you a file and not a record. Either way you still fetch and parse the file. The alternative is to browse the granule list for a title (the 2024 edition of Title 42 lists 10,273 granules) or keep your own citation-to-granuleId map.

GovInfo is excellent for archival and bulk ingestion. It is not built to answer "give me the current text of 17 U.S.C. § 107 as structured JSON." You still do the text parsing yourself, and the newest edition it holds is a dated, published one (2024 on 12 October 2026).

So when someone says "I'll just hit the USC API," what they are really signing up for is: resolve the granule ID, fetch the granule, parse the HTML, model the hierarchy, and maintain all of it. The maintenance is the part that hurts.

What developers say about the GovInfo route

The public issue tracker for GovInfo's API on GitHub is a good place to see what people actually run into, and the questions look a lot like this post. In January 2025 a developer opened an issue titled "how to get to USC title / section / chapter via API ?", asking how to "get the list of titles, chapters, sections" and "call for a specific section within title / chapter" (legaltextai, GitHub, January 2025). The reply, from the GovInfo side, was a recipe: list the USCODE packages, then use the package's MODS metadata, the granules list or the search service to reach a section, since "descriptive MODS metadata at the package-level contains information about each chapter, section, or other logical division within the given title." That's a real answer. It also confirms the shape of the job: you assemble the lookup yourself.

Another developer asked about freshness: "How often USCODE is updated? Is it annually? Or there is any schedule." The answer was "The USCODE has main editions published every six years, with annual supplements" (GitHub, March 2025). The replies are quick. That one came back in about twenty minutes.

The sharpest question is from July 2026. A developer noted that the House's own site shows provisions "that are in effect but not in the last published codex" through its "prelim" edition, and asked whether the API could return them. GovInfo's answer, in September 2026, was direct: "we only have official published documents that have been added to the system" (GitHub, July to September 2026). Neither side is wrong. A dated, published edition is something you can cite in a brief. A fresher compilation is something you can act on. They are different products, and a statute pipeline has to say which one it is holding.

A short history: how the Code became data

You could read the Code online long before you could get it as data. The people who first closed that gap were open-government developers working outside Congress.

In October 2012 the Open Knowledge Foundation's blog reported that Eric Mill of the Sunlight Foundation, Josh Tauberer of GovTrack.us and Derek Willis had put a public-domain scraper and dataset for congressional bills on GitHub, in an organization called unitedstates. Mill added that a colleague, Thom Neale, had "an in-progress parser for the US Code, to convert it from binary typesetting codes into JSON" (Open Knowledge Foundation blog, October 9, 2012). Binary typesetting codes. That is how far the source sat from anything an API would want.

Two months later Mill told O'Reilly Radar: "It would be fantastic if the relevant bodies published this data themselves and made these datasets and scrapers unnecessary." Publishing it, he added, "would certainly save us a lot of work!" He was talking about congressional bill data, though the same wish applied to the Code (O'Reilly Radar, December 6, 2012, archived copy).

The change came on July 30, 2013. House Speaker John Boehner and Majority Leader Eric Cantor announced that the House was making the United States Code available for download in XML, compiled, updated and published by the Office of the Law Revision Counsel, with individual titles or the full Code in bulk (Library Journal's infoDOCKET, July 30, 2013). House Democratic Whip Steny Hoyer said the office "has taken an important step towards making our federal laws more open and transparent" (as quoted by E Pluribus Unum). Mill, then at Sunlight, gave the developer's verdict: "Historically, the U.S. Code has been extremely difficult to reliably and accurately use as data. These new XML files are sensibly designed, thoroughly documented, and easy to use." He said Tauberer had updated the public-domain parser that same morning, and that the XML's consistent design meant "we could fix bugs and inaccuracies" (E Pluribus Unum, July 30, 2013).

The volunteer parser has since been shelved. The unitedstates/uscode repository was archived by its owner on May 30, 2025 and is read-only. By then the official XML had been out for almost twelve years.

Why Structured Statute Data Is Harder Than It Looks

Pulling raw statute text is trivial. Pulling trustworthy, structured statute text is a real systems problem, and it is the part most teams underestimate. Four things turn an afternoon project into a quarter.

Citations do not map cleanly to nodes. A human reads 42 U.S.C. § 1983 and knows exactly what they mean. Your parser sees a tree of XML elements with identifier attributes, and you have to write the logic that turns "title 42, section 1983" into the correct node, while handling the fact that the same section number appears in every title.

A bare "Section 1983" is meaningless without its title. This is the same ambiguity that bites people in Boolean search, where 5 U.S.C. § 706 is APA review and a freestanding "706" is noise.

Sections get repealed, renumbered, and reserved. The Code is not a static document. Sections are struck, moved, and renumbered as Congress acts. A section can be marked "Repealed" or "Omitted" or "Reserved" while still occupying its slot in the hierarchy.

If your parser does not model these states, you will confidently return text for a section that no longer has operative effect, which in legal research is worse than returning nothing.

Cross-references are everywhere and they are load-bearing. Statutes refer to other statutes constantly. "As defined in section 2 of this title," "notwithstanding section 1331 of title 28." A flat text dump strips the structure that makes those references resolvable. To do anything useful, you need to preserve and ideally resolve them.

Currency is a moving target. The OLRC updates the online Code through each session of Congress, and every update is a release point. The Code you parsed last month is not the Code today. Anyone shipping statute data has to answer a deceptively hard question: as of what date is this text correct?

If you cannot answer that, you do not have a legal-research data source. You have a snapshot of unknown vintage.

None of this is exotic. It is just unglamorous, and it is precisely the work that an API layer exists to absorb. You build the parser, the hierarchy model, the citation resolver, and the currency pipeline once (we walked through every layer a legal corpus passes through separately), then expose three clean endpoints so nobody has to rebuild that XML parser again.

(Plenty of teams do rebuild it. It is one of those wheels the industry keeps reinventing, each parser slightly different, each one drifting out of date on its own schedule.)

The Three Primitives You Actually Need

Strip away the ceremony and there are only three operations a developer wants against the US Code:

1. Search the Code for a concept or phrase.
2. Fetch a section's metadata (citation, where it sits in the hierarchy, what it links to) by a stable identifier.
3. Fetch the section's full text, cleanly.

The examples below run against the Vaquill AI statutes API, because it is built for exactly this shape. It serves primary law: the US Code, the CFR, state codes for 56 jurisdictions, constitutions, court rules, agency guidance, session laws and more. Court opinions are a different kind of source.

A fourth call is worth knowing about. If you already have a citation string such as 42 U.S.C. 1983, GET /api/v1/us/statutes/resolve?cite=... returns the exact section, and POST on the same path resolves a list of citations in one request.

A note on what was and was not run. The fields and values below come from real responses pulled on 12 October 2026, trimmed for length (the API returns en dashes inside public law citations, and the examples show plain hyphens). The Python needs an API key, so we did not run it end to end; the request shapes were checked against the live OpenAPI document at https://api.vaquill.ai/external/openapi.json.

Authentication

Every request carries a bearer token.

Authorization: Bearer vq_key_your_key_here
Content-Type: application/json

Keys are issued from the platform dashboard.

Primitive 1: Search the Code

POST /api/v1/us/statutes/search. The body takes a query plus optional scoping: corpusType (one of USC, CFR, STATE, CONSTITUTION, FEDERAL_RULES, and others), state, titleNumber (an integer), and limit.

import requests

BASE = "https://api.vaquill.ai/api/v1/us"
HEADERS = {
    "Authorization": "Bearer vq_key_your_key_here",
    "Content-Type": "application/json",
}

payload = {
    "query": "civil action color of law",
    "corpusType": "USC",
    "titleNumber": 42,
    "limit": 5,
}

resp = requests.post(f"{BASE}/statutes/search", json=payload, headers=HEADERS)
resp.raise_for_status()
results = resp.json()["results"]

The first result of that query on 12 October 2026, trimmed:

{
  "actId": "USC_T42_C21_S1983",
  "citation": "42 U.S.C. § 1983 (2026)",
  "title": "Civil action for deprivation of rights",
  "titleNumber": "42",
  "corpusType": "USC",
  "breadcrumb": [
    { "type": "title", "num": "42", "label": "Title 42", "name": "THE PUBLIC HEALTH AND WELFARE" },
    { "type": "chapter", "num": "21", "label": "Chapter 21", "name": "CIVIL RIGHTS" },
    { "type": "subchapter", "num": "I", "label": "Subchapter I", "name": "GENERALLY" },
    { "type": "section", "num": "1983", "label": "Section 1983", "name": "Civil action for deprivation of rights" }
  ],
  "excerpt": "Every person who, under color of any statute, ordinance, regulation, custom, or usage, of any State or Territory or the...",
  "actStatus": "in_force",
  "currentThrough": "2026-09-18"
}

The field that matters most here is actId. That is the identifier you carry into the next two calls. The ids are readable, USC_T42_C21_S1983 is title 42, chapter 21, section 1983, but take the id from the response and do not hand-build it: the chapter is not derivable from a citation, and hand-built ids usually return 404. The response also carries a per-section currentThrough date, which answers the "as of what date" question from the previous section for that section.

You do not have to reverse-engineer an opaque node path out of an XML tree. The hierarchy comes back as a breadcrumb list.

For the syntax inside the query string itself (quoting phrases, combining terms with AND/OR/NOT, proximity), the Boolean search guide is the companion piece. This post assumes you already know what to search for and focuses on what you do with the result.

Primitive 2: Fetch Section Metadata

GET /api/v1/us/statutes/section/{actId}. Hand it the actId and you get back the section's identity and its place in the Code. The record is wrapped in a section key.

act_id = "USC_T42_C21_S1983"
resp = requests.get(f"{BASE}/statutes/section/{act_id}", headers=HEADERS)
section = resp.json()["section"]

Trimmed to some of the fields it returns:

{
  "actId": "USC_T42_C21_S1983",
  "citation": "42 U.S.C. § 1983 (2026)",
  "citationShort": "42 U.S.C. § 1983",
  "title": "Civil action for deprivation of rights",
  "titleNumber": "42",
  "titleName": "THE PUBLIC HEALTH AND WELFARE",
  "chapter": "21",
  "chapterName": "CIVIL RIGHTS",
  "sectionNumber": "1983",
  "actStatus": "in_force",
  "sourceCredit": "(R.S. § 1979; Pub. L. 96-170, § 1, Dec. 29, 1979, 93 Stat. 1284; Pub. L. 104-317, title III, § 309(c), Oct. 19, 1996, 110 Stat. 3853.)",
  "lastAmendedYear": 1996,
  "publicLaws": ["Pub. L. 104-317", "Pub. L. 96-170"],
  "currentThrough": "2026-09-18"
}

This is the payload that the bulk XML download makes you compute yourself. The titles, the chapter heading, the source credit and the public laws behind the current text have to be assembled by walking the USLM tree from the section node. Here it arrives resolved, and the full set of metadata fields a section can carry goes well past these.

Primitive 3: Fetch the Full Text

GET /api/v1/us/statutes/section/{actId}/body. Same identifier, the actual statutory text. By default you get both rendered HTML and plain text.

resp = requests.get(f"{BASE}/statutes/section/{act_id}/body", headers=HEADERS)
body = resp.json()

print(body["plain"])  # plain text for ingestion / embeddings
# body["html"] keeps structure for display

{
  "actId": "USC_T42_C21_S1983",
  "html": "...",
  "plain": "Every person who, under color of any statute, ordinance, regulation, custom, or usage, of any State or Territory or the District of Columbia, subjects, or causes to be subjected... shall be liable to the party injured in an action at law...",
  "sourceCredit": "(R.S. § 1979; Pub. L. 96-170, § 1, Dec. 29, 1979, 93 Stat. 1284; ...)",
  "available": true
}

The two formats exist for two jobs. The HTML preserves subsection structure for display in your UI. The plain text is what you feed into a retrieval pipeline, embeddings, or an LLM prompt. A format parameter narrows the payload: format=operative returns just the section's text (content) and sourceCredit, without the notes, which on a note-heavy section is a much smaller response.

If you are building retrieval-augmented generation over statutes, the plain-text body is the unit you chunk and index. We walk through that retrieval layer in how AI legal research actually works.

That is the entire happy path: search to find the actId, fetch metadata for the hierarchy, fetch the body for the text.

Browsing and Coverage

Two inexpensive calls round things out, and they matter more than they look: coverage is free and divisions costs 1 credit per call.

GET /api/v1/us/statutes/coverage returns every corpus type with per-jurisdiction counts, so you can build a jurisdiction picker, validate user input before a search, or audit coverage before you commit to a data source. GET /api/v1/us/statutes/divisions walks the hierarchy (titles, chapters, parts, sections) for a corpus, and takes corpusType, state, titleNumber and similar parameters. The older /statutes/states and /statutes/codes routes are deprecated in favor of these two.

coverage = requests.get(f"{BASE}/statutes/coverage", headers=HEADERS).json()
ca_codes = requests.get(
    f"{BASE}/statutes/divisions",
    params={"corpusType": "STATE", "state": "ca"},
    headers=HEADERS,
).json()

Coverage is the question every serious buyer asks, so here are the figures we publish for our own corpus: 60,494 USC sections, 222,311 CFR sections, more than 196,000 Federal Register agency rules, state codes for 56 jurisdictions (2M+ sections), state regulations across those same 56 (1.56M+ rules), the Constitution (74 sections), federal rules (1,130), and executive orders (3,674). That is over 5.3 million sections behind one consistent schema, refreshed on a per-source schedule from daily to monthly.

These are product numbers and not a third-party benchmark, but they make the point: the value is not any single section, it is the joined, currency-managed whole. Joining USC, CFR, and state codes under one citation model is the work.

Build vs. Buy: An Honest Take

Should you parse the USLM XML yourself or hit an API? It depends, and I will not pretend the answer is always "buy."

Parse it yourself if statute text is your core product, you have the engineering to own a parser and a currency pipeline indefinitely, and you need control over every edge case. The data is open and free. That is a real and legitimate path. A handful of civic-tech efforts have done exactly this in the open, and the ecosystem is better for it.

Reach for an API if statutes are an input to your product rather than the product itself. If you are building a contract-review tool, a compliance checker, or a research assistant, you do not want to spend a quarter on a USLM parser and then own its maintenance forever. You want three endpoints and a stable actId.

The build-it-yourself cost is rarely the initial parse. It is the second year, when the schema shifts, a title gets renumbered, and your snapshot silently goes stale while you are busy shipping features.

A common trap is a quick scraper that conflates full text with structure. A scraped HTML page or a PDF is not queryable structured data with stable citation IDs.

It looks like data until the day a lawyer asks "is this current, and how do you know," and you have no answer.

A Note on Trust

Everything above is about plumbing, but the reason any of it matters is trust. The 2023 Mata v. Avianca sanctions, where lawyers filed a brief full of cases a chatbot invented, made the cost of unverifiable legal data concrete and public.

Statutes are lower-drama than fabricated case citations, but the principle is identical: if your system surfaces "42 U.S.C. § 1983 says X," a lawyer needs to click through to the verbatim text and confirm it, as of a known date.

That is why the three primitives matter in that exact order. Search gets you a candidate. The actId and metadata pin it to a real place in the Code. The body gives you the words to verify. No step asks the reader to trust a summary.

That is the whole reason an API layer over the US Code exists. Not because the data is secret (it is gloriously open), but because making it structured, cited, current, and joinable across jurisdictions is genuine work that should be done once and done well.

FAQ

Is there an official US Code API? No. The Office of the Law Revision Counsel publishes the United States Code as bulk USLM XML, XHTML, PCC, and PDF downloads at uscode.house.gov, whole-Code or title-by-title. The pages we read describe no official endpoint that returns a single section by citation as JSON.

How do I pull a US Code section programmatically? Two practical routes. The GovInfo API lets you fetch a section as a package granule (for example USCODE-2024-title42-chap21-subchapI-sec1983) with a free api.data.gov key, but it returns download links to HTML, PDF, and MODS rather than parsed JSON. A statutes API like Vaquill AI maps a citation to a stable actId and returns the section as structured JSON with hierarchy and full text.

Is the GovInfo API free? Yes. You sign up for an api.data.gov key at no cost. The public DEMO_KEY works for a quick test but is shared and tightly limited (it returned 429 on our first attempt on 12 October 2026). GovInfo's README gives the default limits for a registered key as 36,000 requests per hour, 1,200 per minute and 40 per second. The data itself is public domain.

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.

How do I get the current text of a US Code section? Currency is the catch. The Code changes as Congress acts, so the answer depends on the edition. GovInfo packages are dated by year (the USCODE-2024-... prefix, the newest on 12 October 2026). Whatever source you use, confirm the "as of" date before you treat a section as operative, because repealed and renumbered sections still occupy their slots.

What is the difference between the GovInfo API and a statutes API? GovInfo is a bulk and archival API organized around packages and granules; you resolve the granule ID and parse the content yourself. A statutes API is built for per-citation retrieval: it absorbs the parsing, hierarchy modeling, citation resolution, and currency, then exposes search, metadata, and body as clean JSON.

Can I get every state and territory code from one API? Not from the government. Each state publishes its code on its own terms, in its own format. Aggregators like Vaquill AI join federal and state statutory codes (56 state-level jurisdictions) under one schema and one citation model, which is the part you would otherwise build and maintain per jurisdiction.

For more on the statutes API surface and what it covers, see the US primary law API, or email contact@vaquill.ai.

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.