Skip to main content
Every court with status: live serves its rules through the same three calls. First, find the court. Second, find the judge. Third, read the rules. Each rule comes back with the court’s own sentence, a plain-English summary, structured fields and the address of the document it came from. The example reads the courtesy copy rule of one judge at the Superior Court of California, County of Los Angeles, and the same calls work for any other live court. All requests need a Bearer token, which Authentication explains. Compliance checks are separate and run for the Eastern District of New York only, as the Quickstart shows.

​
1. Find the court

A court is identified by its district_id. Federal district courts use short codes such as edny, and state courts start with the state’s two-letter code, such as ca-los-angeles-superior or il-cook-circuit. To find the id of a court, list the courts once and search the names:
Each court in the list counts as one row against your daily row limit, so keep the list instead of reading it again. Once you know the id, read one court with GET /api/v1/courts/{district_id}. The counts in the samples on this page change as rosters change.
A live court has rules. A coming_soon court is mapped but has none yet. Coverage explains how to check how deeply a live court is covered.

​
2. Find the judge

The response lists the court’s current roster, shortened here to a single judge.
Use the slug of a judge whose has_rules is true. A roster entry without rules of its own still has the court-wide rules. In some state courts the roster lists departments or courtrooms instead of people, and their slugs work the same way.

​
3. Read the rules

Send the court, the judge and, to narrow the answer, a rule type. The list of rule types names all of them.
The response holds the rules that match. Because include_court_rules defaults to true, it can also hold court-wide rules of the same type. The example keeps only the judge’s own rule and shortens its fields.
Each part of a rule has a use:
  • content.source_text: the court’s own sentence. Show it to filers.
  • content.summary: a plain-English summary of the sentence.
  • content.structured_data: the rule as fields, so software can act on it. The fields depend on logic_type. Here the trigger is a document longer than 15 pages, and the requirement is a drop-off at chambers on the filing date.
  • content.citation_source: the page, section, paragraph or sentence of the document, when the document has them.
  • source_url: the official address the rule was read from.
  • judge_slug: whose rule it is. A court-wide rule has the slug court.
To read every rule of the judge, leave out logic_type and page through the results with limit and offset, as Search extracted rules shows.

​
Behavior details

  • Court-wide rules come with the judge’s rules. Send judge_slug=court to read only the court-wide rules, or include_court_rules=false to leave them out.
  • The API does not pick a winner. A judge’s rule can add to or differ from a court-wide rule. The API returns both and does not work out which one governs a filing.
  • One call returns everything. GET /api/v1/rules returns a judge’s whole rule set, grouped as court-wide and judge rules. The court-wide layer comes back in full, which can be over a thousand rules in a large court, so page with /extracted-rules when you need only part of it.
  • Rows add up. Each rule in a list counts as one row against your daily row limit. See Rate limits.

​
Common mistakes

  • Showing the summary without the quote. The summary is a plain-English reading of the rule. Show the court’s sentence and the link with it, so a filer can check the wording.
  • Reading an empty list as “no requirement”. An empty list means the API holds no matching rule. It does not mean the court has none.
  • Assuming every roster entry has rules of its own. Check has_rules before you tell a filer that a judge has no requirements.