A lot of products need to put real US law in front of a user. A compliance tool needs the exact regulation. A contract app needs the governing statute. A research assistant needs a citation the user can open and trust.
What those builders usually do not want is a general chatbot guessing at the law. They want the actual section, its citation, and a link to the official government source, returned over an API they can call from their own code. That is what our statutes and regulations API is. This post walks through what it covers, the endpoints, and, most importantly, the things that make it safe to build on: every result links to an official source, and you are not charged when a call fails.
What it covers
The API is one search surface over eight bodies of US law, federal and state.
You pick a corpus with a corpusType token, or omit it to search everything at once.
USC: the United States Code, the federal statutes. Roughly 55,000 sections.CFR: the Code of Federal Regulations, the federal regulations. Over 219,000 sections.STATE: state statutory codes, covering 49 states plus DC and Puerto Rico.CONSTITUTION: the US Constitution, Articles I through VII and the 27 Amendments.FEDERAL_RULES: the Federal Rules of Civil Procedure, Criminal Procedure, Evidence, Appellate Procedure, and Bankruptcy Procedure.STATE_CONSTITUTION: state constitutions, dozens of jurisdictions.STATE_RULES: state court rules, for a growing set of states.EXECUTIVE_ACTION: Federal Register Presidential Documents, meaning Executive Orders, Proclamations, and Memoranda, refreshed daily.
Across all of it, the corpus runs to more than 2.6 million sections. The section counts drift as we ingest more, so treat those numbers as a snapshot, not a contract.
The important part is not the size. It is that every one of these corpora is public-domain government law, sourced from official publishers, and every result we return links back to that official source. You are never asking your users to trust an answer that traces to nowhere.
Start free: discover coverage before you spend
Two endpoints are free. They exist so you can see exactly what is queryable before you spend a single credit.
GET /statutes/states lists every jurisdiction in the corpus with its ingested section count, so you can tell at a glance whether the state you care about is covered and how deeply.
GET /statutes/codes?state=tx lists the distinct statutory codes ingested for one state, for example the Texas Government Code, Health and Safety Code, and Penal Code, each with a section count.
Both require an API key and are rate limited, but they cost nothing. The point is that coverage is inspectable, not a promise you have to take on faith.
Search
The core call is a search. You send a natural-language or keyword query, optionally scoped to a corpus, a state, or a federal title number.
Illustrative request:
import requests
headers = {"Authorization": "Bearer YOUR_API_KEY"}
# Search federal regulations (CFR), Title 17, for an SEC topic.
resp = requests.post(
"https://api.vaquill.ai/api/v1/statutes/search",
headers=headers,
json={
"query": "insider trading material nonpublic information",
"corpusType": "CFR",
"titleNumber": 17,
"limit": 5,
},
)
Illustrative response (one result, trimmed):
{
"results": [
{
"actId": "CFR_T17_P240_S240_10b5_1",
"citation": "17 C.F.R. § 240.10b5-1 (2026)",
"citationShort": "17 C.F.R. § 240.10b5-1",
"title": "Trading on the basis of material nonpublic information",
"corpusType": "CFR",
"titleNumber": "17",
"sectionNumber": "240.10b5-1",
"relevanceScore": 0.91,
"excerpt": "The manipulative and deceptive devices prohibited by section 10(b)...",
"externalUrl": "https://www.ecfr.gov/..."
}
],
"total": 1,
"query": "insider trading material nonpublic information"
}
The same call shape works for state legislation.
Scope to a state code with corpusType: "STATE" and a two-letter state:
# Search California state statutes.
requests.post(url, headers=headers, json={
"query": "shareholder derivative action standing",
"corpusType": "STATE",
"state": "ca",
})
And for regulations at the federal level you scope to CFR, for executive actions to EXECUTIVE_ACTION, for procedural law to FEDERAL_RULES, and so on.
Omit corpusType and the query runs across every corpus at once.
Two design choices in that search are worth calling out, because they are about not lying to you.
First, relevanceScore ranks results within one response.
It is a relative ranking signal, not a calibrated confidence or a probability.
We say so in the field's own description, because a number that looks like a probability but is not one is a trap, and treating a fixed score as a quality threshold across different queries will burn you.
Second, the titleNumber filter only applies to the federal USC and CFR corpora, whose titles are numbers.
State titles are alphabetic codes, or worse, numbers that collide with federal title numbers.
So if you send a titleNumber with a state search, we reject the request with a clear error rather than quietly returning a polluted mix of federal and state sections that happen to share a number.
Refusing a query is sometimes the honest answer.
Get the section, then the full text
A search result carries a stable actId.
You do not build that identifier by hand; you take it from a response and use it to fetch more.
GET /statutes/section/{actId} returns the section's metadata: its citation, its place in the title and chapter hierarchy, a breadcrumb, and links to every format the official source offers, HTML, PDF, XML, plain text, and Word where available.
GET /statutes/section/{actId}/body returns the full text, in HTML and plain text, preserving the formatting, cross-references, and paragraph numbering as published in the official source.
# Full text of a specific section.
requests.get(
"https://api.vaquill.ai/api/v1/statutes/section/CFR_T17_P240_S240_10b5_1/body",
headers=headers,
)
If we have not ingested the full text for a section yet, the body call tells you so plainly, returns the metadata path you can still use, and does not charge you. More on that next, because the billing is part of the trust story.
Billing you can reason about
Metered APIs earn distrust when the meter is a black box. Ours is built so that you only pay for what you actually got.
Search costs a small number of credits per call. Section metadata and full-text fetches cost a little less and a little more respectively. The two coverage-discovery endpoints are free.
The rule that matters: failed calls are not charged.
If a search hits an internal error, the credit is refunded.
If a section lookup returns not-found, refunded.
If a full-text fetch finds that we have not ingested that text yet, refunded, and the response says available: false with a note.
You can see the current per-call prices from the pricing endpoint, and you can watch credits move, because the response tells you how many were consumed and how many remain.
Under the hood, your credit balance is not a single stored number that can drift. It is recomputed from the underlying ledger under a row lock, so two calls racing at the same moment cannot double-spend or lose a credit. The balance is derived from the record, not a cache that hopes to stay in sync with it.
How the search actually finds things
You do not need to know this to use the API, but it is why the results are good.
A pure semantic search is fluent and structurally blind. Ask it for a specific section number or a defined term and it will happily return something that reads similar but is the wrong provision. So the search combines keyword matching, which nails exact identifiers and citations, with semantic matching, which handles the natural-language query, and then runs a cross-encoder reranker over the candidates to put genuine relevance on top rather than a literal keyword coincidence. There is a conservative relevance floor and de-duplication, so a sparse but valid result is never dropped to nothing, and the same section does not show up three times as three chunks.
A few concrete numbers make the shape clearer. We over-fetch candidates before reranking rather than trusting the fused ranking: we over-fetch a multiple of the result count you asked for, clamped into a sane band so a small query still gets enough to rerank and a large one does not fan out without limit. The reranker then scores real query-to-passage relevance, de-duplicates on the section identifier so one section split across several chunks collapses to a single result, and applies the relevance floor only once it already has a healthy set, so a thin-but-valid answer is never trimmed to zero. If the reranker itself is unavailable, we fall back to the de-duplicated original order rather than failing the call. For long sections, the passage handed to the reranker is windowed around the query match instead of just the opening characters, so operative language buried past the head is scored, not truncated away.
The result is that a query for a precise provision tends to return that provision, and a natural-language query returns the sections that actually address it.
Put end to end, a single metered search is a short, auditable lifecycle: authenticate, hold the credit, retrieve, rerank, and either return sources or refund.
The section and full-text endpoints follow the same spine, with their own refund branches: a not-found lookup and an un-ingested body both release the held credit before the response returns.
The ingestion is open source
The API surface is the easy part. The hard part is turning fifty states' worth of inconsistent statute publishing, each with its own format, quirks, numbering, and update cadence, into clean, structured, citable sections. That work is open.
github.com/Vaquill-AI/open-us-law holds the ingestion scripts for the fifty states and the federal corpora. If you want the corpus hosted, searchable, and metered, use the statutes and regulations API with the endpoints above. If you would rather build it yourself, or just check exactly how a given jurisdiction is parsed and normalized before you trust it, the scripts are right there. Same public-domain law, two ways in.
That is the same principle as the rest of this API: the source is the thing you are buying, so we do not ask you to take it on faith.
What to check before you trust any legal API
If you are evaluating ours or anyone else's, these are the questions that separate a real legal data API from a wrapper.
-
Does every result carry a citation and a link to the official government source? If you cannot open the underlying statute or regulation on a
.govsite from the response, you cannot show your users the real law, only a claim about it. -
Can you discover coverage before you pay? A vendor confident in their corpus lets you list jurisdictions and codes for free. A vendor who hides coverage behind paid calls is hoping you do not check.
-
What happens on a miss? Ask for a section that does not exist, or full text that is not ingested. A good API tells you plainly and does not charge you. A weak one charges you to be told nothing.
-
Is the relevance score honest about what it is? A within-response ranking signal is useful. A number dressed up as a calibrated probability is a liability.
We publish these answers because in legal software the source is the product. An answer you cannot trace to the official law is not research. It is a guess with good formatting.
