Getting Started Copied!

OpenLaws APIs allow your company and your clients to bring current and precise primary law text into legal and compliance workflows and GenAI applications. Legal text can be queried by Bluebook citation strings (recommended approach), keyword search, or by hierarchical queries. OpenLaws also provides hosted legal text webpages to use when hyperlinking legal citations and when citing from LLM output.

To get started:

1. Request access to OpenLaws API

2. Schedule a 25-min session to chat about use cases and receive API bearer token and sandbox API information

3. View our API Reference, enter your API bearer token, and Test Requests

4. Make API calls from your application, RAG workflow, or agent

5. Find us on Slack if you have questions, need help, or have a request

Common API Use Cases Copied!

• Show legal text within your application and hyperlink legal citations in your documents and applications

• Eliminate the need for your users to have expensive legal research subscriptions

• Add up-to-date contextual legal text into your LLM prompts

• Build RAG workflows and agents with keyword and semantic search

• Validate statute and regulation citations written by humans or as part of LLM output

• Compare statutes and regulations across multiple jurisdictions

• Monitor newly codified statutes and rules & regulations

Concepts Copied!

Jurisdictions Copied!

Jurisdictions in OpenLaws represent the 50 U.S. states (ex: AK, CA, FL) along with the federal government (FED), the District of Columbia (DC), and Puerto Rico (PR). These are containers for Laws which contain the data for various types of primary law. Each jurisdiction has a 2-3 letter capitalized ID which generally is the postal abbreviation.

Laws Copied!

All data in the OpenLaws API is organized under a single Law and identified by human-readable keys , e.g. FED-CFR for the Federal Code of Federal Regulations, CA-RR for the California Code of Regulations.

We categorize primary law into various law types:

• Rules and Regulations (keys ending in -RR )

• Statutes (keys ending in -STAT )

• Constitutions (keys ending in -CONST )

• Case law (keys ending in -CL )

• Court Rules and Civil Procedures ( Future)

Citations Copied!

Citations are the most common way to query and find specific legal text. For the most accurate queries, we use Bluebook formatted citations.

Examples of valid citations:

• 42 U.S.C. § 1983

• 16 C.F.R. § 444.1

• Del. Code Ann. tit. 13, § 1301

• 1 U.S. 22

• Cobb v. Davenport, 32 N.J.L. 369 (Sup. Ct. 1867)

Statutes and Regulations Copied!

Hierarchical Divisions Copied!

Law data is naturally hierarchical. For example, a title could contain chapters that could contain sections that might have appendices. State and federal law data in OpenLaws is standardized into a hierarchical tree structure. Each of the tree nodes of the law structure is called a Division in OpenLaws.

To illustrate, a law — let’s say EXAMPLE-RR — might look like this:

Each rectangle is a division in OpenLaws. The “Titles” in this example are top-level, root divisions. “Chapters” are children of “Titles” and so on.

Division Paths

Divisions typically have a division_type corresponding to how the state organizes their laws and an identifier that describes the node, e.g. Title I, Chapter 1, Section 100. We normalize the pairing of the division’s type and identifier (or the division’s name when there is no identifier). Then we combine all of a single division’s ancestor tree nodes into a URL-like string, called a path . This is used frequently in the API to identify a specific law division node.

The Get law structure Query or any of the Division Queries will return the paths for a set of divisions. Generally, it is not necessary to construct the path on your own.

Example paths for the above diagram:

title_i.chapter_1 is the path of the “Chapter 1” node belonging to the “Title I” node

title_i.chapter_3.section_100.appendix_100_a is the path of “Appendix 100.A” node belonging to the “Section 100” node.

Sorting Like a Human

OpenLaws returns query results in the order a human would sort a list of divisions rather than consistently alphabetical or numerical. Normally, this is determined by the state or federal data source. This is tricky to explain so we’ll give several examples of how we sort:

• “1”, “2”, “3”, … , “9”, “10”

• “001”, “002”, “003”, … , “009”, “010”

• “I”, “II”, “III”, … , “IX”, “X”

• “A”, “B”, “C”, … , “Z”, “AA”, “AB”

• “100.1”, “100.1.A”, “100.2”, “100.3”, “100.10”

• “Section 1”, “Section 2”, “Appendix A”, “Appendix B”

Case Law Copied!

Enterprise API Copied!

Get legal text by citation string Copied!

Additional enterprise features:

• Pincite parsing, ex: 12 C.F.R. § 1026.1(a)

• §§ ranges for sections

• Internal (non-Bluebook) state citation formats

• Common “short” regulation names, ex: Reg Z, Regulation Z, Truth in Lending Act

• Higher depth limits to get back more data in a single query. Enterprise allows up to depth of 3.

Validate and correct citation string Copied!

Check a citation string for validity and get back the recommended Bluebook citation

Get authoritative URL by citation string Copied!

Returns a last known authoritative URL for a division. URL could be a link to a deep-linked U.S. state or federal website, PDF, Word document or other document.

Webhooks and GraphQL Subscriptions Copied!

Subscribe to changes in the statute or regulatory text to build your own workflows.