Congress.gov API Guide: What It Covers and What It Doesn't

Short answer: the Congress.gov API is the Library of Congress's machine-readable feed of what Congress produces: bills, amendments, laws, members, committees, hearings, votes, nominations, treaties and the Congressional Record. You need an API key, it allows 5,000 requests an hour, and it returns JSON or XML. It does not give you the current, integrated text of a US Code section by citation. For that you pair it with a statutes source. Use Congress.gov to find out what Congress did, and a statutes source to read the law as it now stands.

TL;DR

• The Congress.gov API (version 3) serves the collections on Congress.gov. Its spec lists about 20 collections, from bill and member to treaty and crsreport.
• The Congress.gov API key comes from a sign-up form at api.congress.gov. Pass it in the X-Api-Key header or as an api_key query parameter.
• The documented rate limit is 5,000 requests per hour. A page returns 20 records by default and 250 at most.
• Responses default to XML. Add format=json if you want JSON.
• It tracks the legislative process. The spec has no endpoint that returns a section of the US Code by citation, so you pair it with a statutes source for current text.

Part of our MCP and developer guide series.

Once you have a Public Law number from this API, three posts cover the other half: the US statutes API guide, pulling US Code sections by citation, and Statutes at Large lookups.

What the Congress.gov API covers

The API is run by the Library of Congress. Its GitHub repository describes it as a way for Congress and the public to view, retrieve and re-use machine-readable data from the collections on Congress.gov. The current version is v3, at https://api.congress.gov/v3.

I read the repository's OpenAPI file on 4 October 2026. It defines 108 paths across these collections:

Bill types follow the usual codes: HR, S, HJRES, SJRES, HCONRES, SCONRES, HRES and SRES. Coverage depends on the collection. The documentation points to Congress.gov's coverage-dates page for each one, so check it before you assume a collection goes back as far as you need.

Two coverage notes from the bill documentation are worth knowing. Records for some bills from 1799 to 1873 are in the API, but they have text, titles and some actions, and not sponsors, cosponsors, summaries or committees. And the summaries endpoint returns only summaries published in the last day unless you pass fromDateTime or toDateTime.

A short history of Congress.gov data

The Library of Congress launched a site called THOMAS on 5 January 1995. It introduced Congress.gov on 19 September 2012 as the eventual replacement, took the beta label off in September 2014, and switched THOMAS off on 5 July 2016. Andrew Weber of the Library of Congress put the reason plainly: "Congress.gov is the system that we wished THOMAS could be, but could not because of its older, fragile infrastructure." (Time to Turn off THOMAS, April 2016)

For the next six years, developers who wanted the data in bulk scraped the site or used the Government Publishing Office's bulk downloads. The Library's own announcement of the API, in September 2022, says as much: "Certain entities or persons have 'scraped' the website over the years and the Government Publishing Office (GPO) has also offered bulk data downloads for some collections, but these have all been somewhat imperfect measures." (The Signal, September 2022) So the API exists because people were going to take the data anyway, and the Library chose to make that easier.

The hourly limit has its own small history. Developers asked for a higher cap on the public tracker in 2023. One wrote that they were "challenged to keep up on the flood of records from Congress, using only 1000 calls per hour." (c4lliope, GitHub issue 88, June 2023) In March 2024 the Library raised it to the 5,000 per hour you see today, and recorded the change in the changelog under "March 2024, Part 1."

How the API key works

An API key is required. You request one on the sign-up page, and the key is issued through api.data.gov, the federal service that fronts many agency APIs. The api.data.gov developer manual describes two ways to send it:

• A header. Send X-Api-Key: YOUR_KEY.
• A query parameter. Add api_key=YOUR_KEY to the URL.

The Congress.gov OpenAPI file declares the query parameter form. The header form is the one the api.data.gov manual shows first, and it keeps your key out of server logs and browser history, so use it in code. The manual also describes a shared DEMO_KEY for trying things out, with much lower limits than a personal key.

Treat the key like a password. Do not commit it, and do not ship it in browser code.

Rate limits and paging

The README says the rate limit is set to 5,000 requests per hour. The api.data.gov manual adds that exceeding a limit gets your key temporarily blocked, that the block lifts after an hour, and that every response carries X-RateLimit-Limit and X-RateLimit-Remaining headers. Read those headers in your client and back off before you reach zero:

import os, time, requests

r = requests.get(
    "https://api.congress.gov/v3/bill/117/hr/3076",
    headers={"X-Api-Key": os.environ["CONGRESS_API_KEY"]},
    params={"format": "json"},
)
remaining = int(r.headers.get("X-RateLimit-Remaining", 1))
if remaining < 50:
    time.sleep(60)  # slow down before the hourly window runs out

Paging uses limit and offset. The default page is 20 results. You can raise limit up to 250, and a larger value still returns 250. The README says list responses have three parts: a request element describing the call, a pagination element with the count and a next-page URL, and a data element named for the collection, such as bills.

One gotcha trips up first-time users. The default format is XML. If your code expects JSON, add format=json to every call.

A working request

Here is a request for one bill, H.R. 3076 of the 117th Congress, using the header form of the key:

curl -H "X-Api-Key: $CONGRESS_API_KEY" \
  "https://api.congress.gov/v3/bill/117/hr/3076?format=json"

The path is /bill/{congress}/{billType}/{billNumber}, and the bill type is lowercase in the path (hr) even though the record returns HR. The response is a bill object. When I ran this on 4 October 2026 it returned, among other fields, the title "Postal Service Reform Act of 2022", the sponsor, the introduced date, a latestAction of "Became Public Law No: 117-108." and a laws array:

{
  "bill": {
    "congress": 117,
    "type": "HR",
    "number": "3076",
    "title": "Postal Service Reform Act of 2022",
    "introducedDate": "2021-05-11",
    "latestAction": {
      "actionDate": "2022-04-06",
      "text": "Became Public Law No: 117-108."
    },
    "laws": [{ "number": "117-108", "type": "Public Law" }]
  }
}

That is a trimmed copy. The real response also has counts and URLs for actions, amendments, cosponsors, committees, subjects, summaries and text versions, so you can walk from the bill to each one. The text endpoint lists the bill's text versions, each with links in up to three formats: Formatted Text, PDF and Formatted XML.

To go from a Public Law number to its bill, use the law endpoints. The path is /law/{congress}/{lawType}/{lawNumber}, where lawType is pub or priv, and the documentation says to use the law number NARA assigns.

Where Congress.gov stops and statutes sources start

The Congress.gov API is organized around the lawmaking process. It records bills, amendments and laws as they are introduced and enacted. Nothing in its 108 paths takes a citation like 42 U.S.C. § 1983 and returns the current text of that section.

That gap matters because the Code and the laws are different things. A Public Law is the text Congress enacted. The US Code is the Office of the Law Revision Counsel's organized, integrated version of the general and permanent laws, which folds each new Public Law into the right titles and sections. One Public Law can touch many sections, and one section can carry the marks of dozens of Public Laws.

So there are questions Congress.gov answers well and questions it leaves to another source.

The data in the API is what the House and Senate deliver to Congress.gov. The README says reports of missing or inaccurate data are triaged by Congress.gov staff and passed to the chambers as needed. Plan for the same lag you see on the website.

Why the Code lags the laws

Three layers of text are in play, and people mix them up. A bill becomes a law when it is enacted, and the law gets a Public Law number. The laws are then published in the Statutes at Large. The Code then rearranges the general and permanent laws by subject, which is the layer most readers want.

The Code is a more recent idea than you might expect. The Office of the Law Revision Counsel says the US 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 cumulative supplements in between (govinfo). Not every title has the same standing. For titles Congress has enacted as positive law, the Code text is legal evidence of the law. For the others, govinfo says they "are only prima facie evidence of the law. In that case, the Statutes at Large still govern."

That distinction has teeth. Here is a story from 1993. The Supreme Court dealt with a 1916 provision on national banks selling insurance. Early editions of the Code printed it as 12 U.S.C. section 92. The 1952 edition and later ones left it out, with a note saying Congress had repealed it in 1918. The Comptroller of the Currency still relied on it in 1986, and the case reached the Supreme Court. Justice Souter wrote for a unanimous Court that no repeal had occurred. The Code is prima facie evidence, he explained, but "it is the Statutes at Large that provides the 'legal evidence of laws,'" and "despite its omission from the Code section 92 remains on the books if the Statutes at Large so dictates." (United States National Bank of Oregon v. Independent Insurance Agents of America, 508 U.S. 439 (1993)) A provision the Code said was gone was still the law.

The practical lesson: the Code is the convenient layer, and for anything that matters you want to be able to walk back to the Public Law. That is why the join on the Public Law number in the section below is worth building.

When to pair it with a statutes source

Most real products need both halves. A compliance tool wants to know that a statute changed and also why. A research tool wants to show the current section next to the Public Law that last amended it. The two sources join on the Public Law number.

The join runs in either direction.

From a Code section to the laws behind it. A statutes source that carries the credit line gives you the Public Laws that enacted and amended a section. In the Vaquill AI OpenAPI spec (read 4 October 2026), the example for 42 U.S.C. § 1983 lists publicLaws of Pub. L. 104-317 and Pub. L. 96-170, with the full credit line in sourceCredit. Take 104-317 and ask Congress.gov for it:

curl -H "X-Api-Key: $CONGRESS_API_KEY" \
  "https://api.congress.gov/v3/law/104/pub/317?format=json"

I ran that call. It returned the 104th Congress bill S. 1887, introduced 1996-06-19, with the latest action "Became Public Law No: 104-317." You now have the bill history, sponsors, committee reports and text versions that sit behind one line of a Code section's credit.

From a law to the Code. Take a Public Law you found in Congress.gov and look for it in the credit lines of the sections you track. The statutes side is where you read the integrated result.

On the statutes side, the same spec offers a citation resolver and a text endpoint. This call resolves a citation to a section and returns its actId:

curl -G "https://api.vaquill.ai/api/v1/us/statutes/resolve" \
  -H "Authorization: Bearer $VAQUILL_API_KEY" \
  --data-urlencode "cite=42 U.S.C. 1983"

The spec's example response, trimmed:

{
  "resolved": true,
  "inputCitation": "42 U.S.C. 1983",
  "section": {
    "actId": "USC_T42_C21_S1983",
    "citationShort": "42 U.S.C. § 1983",
    "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.",
    "publicLaws": ["Pub. L. 104-317", "Pub. L. 96-170"],
    "currentThrough": "2026-09-02"
  }
}

The same OpenAPI spec documents a changes endpoint that lists changes its refreshes have observed for a section, and board watches (the /watches endpoints) that send a webhook or an email when a source refreshes with real changes. That pairs well with a Congress.gov poll: when the legislative feed shows a new Public Law, the statutes feed tells you when the Code text moved. The spec is careful to say these are observed changes, not the legal effective date, so keep the publisher's own dates for that.

If you want to see how the other free sources stack up for the Code side, the US statutes API guide compares them, and govinfo API versus a legal data API goes deeper on the federal bulk data route.

What developers say about it

Praise first. One developer who built a tool on the API wrote on Hacker News in June 2025 that the Congress.gov API is "rather comprehensive," and that it "exposes that information, in near real-time." (ashwinsundar, Hacker News, June 2025) Having read the spec, I agree on the breadth: 108 paths is a lot of Congress.

The Library also runs its issue tracker in the open, and its staff answer. That makes it a good place to learn the rough edges before you hit them. Two that matter for a backend:

• Bulk text downloads can get challenged. A developer downloading bill text from the links the API returns reported in March 2024 that the site started answering with a challenge page after about 3,000 downloads, and in July 2024 after about 700 requests in seven minutes. A repository maintainer replied in July 2024: "we recommend using the GovInfo API if the goal is to download the entire bill text corpus." (GitHub issue 207) The same reporter saw it again in November 2025, and the issue was still open when I checked on 5 October 2026.
• Expect the odd error burst. In March 2026 a developer logged bursts of 503 and 520 responses and reproduced them over a five-hour window. The maintainers first said their logs showed nothing unusual, then opened a bug ticket (GitHub issue 431). Build retries with backoff, as you would for any API.

A fair summary: the API is broad and documented, and the maintainers answer. Treat it as the source for the legislative record, and plan for the occasional wobble.

Practical tips for building on it

Set format=json once in a shared client, not on each call. Check X-RateLimit-Remaining after every response.

Cache what you have already fetched. The API supports fromDateTime and toDateTime filters on update date, so you can poll for what changed since your last run instead of re-reading everything.

Use the introducedDate field and the introducedDate asc or desc sort on the bill list endpoints when you want chronological order. The repository changelog shows both were added in August 2026.

Follow the URLs in the response instead of building them. Each bill record gives you the exact URL for its actions, cosponsors and text.

Watch the changelog. The Library of Congress posts changes to endpoints and fields there, and an open issue tracker in the same repository is where they ask for bug reports.

Which tool for which job

If your product follows legislation, build on the Congress.gov API. It is the authoritative feed for the process, and the 5,000-per-hour limit is generous for polling. If your product needs the law as it reads now, add a statutes source and join on the Public Law number. For the wider market, see the best legal data APIs for developers. If you want the Code side as JSON by citation, with state codes under the same schema, get an API key for the Vaquill AI US primary law API and resolve your first citation.

This guide is part of US Law Data: The Complete Guide, a map of where US law comes from and how to use it.

FAQ

What is the Congress.gov API? It is the Library of Congress's API for the collections on Congress.gov. It returns bills, amendments, laws, members, committees, hearings, votes, nominations, treaties, CRS reports and the Congressional Record in JSON or XML. The current version is v3.

How do I get a Congress.gov API key? Sign up at api.congress.gov/sign-up. The key is issued through api.data.gov. You can send it in an X-Api-Key header or as an api_key query parameter, and the header keeps it out of URLs and logs.

What is the Congress.gov API rate limit? The README states 5,000 requests per hour. If you go over a limit, api.data.gov temporarily blocks the key, and the block lifts after an hour. Each response includes X-RateLimit-Limit and X-RateLimit-Remaining headers.

Is the Congress API the same as the Congress.gov API? Most people searching for the "Congress API" mean this one, the Library of Congress API at api.congress.gov. It is a separate service from the GPO's govinfo API, which publishes the Code, the Federal Register and other publications.

Can I get the text of a US Code section from the Congress.gov API? No endpoint in its OpenAPI spec returns a Code section by citation. You can get bill text versions and the law records. For the integrated current text of a section, use a statutes source such as the Office of the Law Revision Counsel's bulk XML, govinfo, or a statutes API.

How do I get JSON from the Congress.gov API? Add format=json to the request. The spec sets the default format to XML, so a call without it returns XML.

How do I find the bill behind a Public Law? Call /law/{congress}/{lawType}/{lawNumber} with pub for public laws, for example /law/104/pub/317. The response is the bill record, with its sponsors, actions and text versions.

How do I use Congress.gov with Vaquill AI? Use Congress.gov for bill activity and Public Law history. Use Vaquill AI to resolve a US Code, CFR or state citation to its section and read the text as JSON. The Public Laws listed in a section's credit line are the link between the two.

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.