Coverage

Coverage is the set of courts, judges and rulebooks the API holds rules for, and how much it holds for each one. It differs from court to court, so a client should read it from the API instead of assuming it. Counts change as courts are added, so this page gives none. The coverage page on courtrules.app lists today’s counts by court, state and judge, with the date they were counted. GET /api/v1/courts returns totals in its meta object. The coverage page counts a court only when it has at least one current rule and leaves out listings that redirect to another court, so its totals can differ from the API’s.

Why teams read coverage

Before building: find out whether the courts your customers file in are covered, and how deeply.
In the product: tell a filer when a judge has no rules of their own, so an empty list is not read as “no requirements”.
In the interface: show the court’s own sentence and a link to its document beside each requirement.

How coverage works

Coverage has three levels, and each level has a field that says where it stands.

A court is covered when its status in /courts is live. A coming_soon court is mapped and has a roster, but the API holds no rules for it yet.
A judge on a live court is covered when has_rules is true in /judges, which means the API holds the judge’s own standing orders, individual practices or courtroom rules. A judge without rules of their own still has the court-wide rules whenever the court has any, and meta.court_level_rules reports that.
A rule is one requirement. It carries the court’s own sentence in content.source_text, a plain-English content.summary, a rule type, and source_url, the official address the rule was read from.

Every API key can query every court, and each endpoint answers one coverage question:

GET /api/v1/courts lists every court we map, with its status and roster size.
GET /api/v1/judges lists a court’s current roster and marks the judges whose own rules we hold.
GET /api/v1/rules returns a judge’s rules. For courts without a compliance profile, that is the court-wide rules plus the judge’s own rules, each with its quoted source text.
GET /api/v1/extracted-rules searches and pages rules across every court.
GET /api/v1/rulebooks lists official rulebooks, such as the California Rules of Court, whose rules you read one by one with their official text.
GET /api/v1/holidays lists court holidays and closure dates with their official sources.

To read the rules of a court in three calls, follow Read a court’s rules.

Key terms

Term	Meaning	Where you see it
Court	A federal district court or a state trial court that the API maps.	`district_id`, such as `edny` or `ca-los-angeles-superior`
Live	The API holds rules for the court.	`status: live` in `/courts`
Coming soon	The court is mapped and its roster is listed, but the API holds no rules for it yet.	`status: coming_soon`
Roster	The judges currently listed for a court. In some state courts the roster lists departments or courtrooms instead of people.	`judges_mapped`, `/judges`
Judge with own rules	A roster entry for which the API holds the judge’s own standing orders, individual practices or courtroom rules.	`has_rules`, `meta.with_rules`
Court-wide rules	Rules that apply in every courtroom of the court, such as local rules and general orders.	`judge_slug` of `court`
Rule	One requirement, with the court’s own sentence, a plain-English summary and a link to the source.	`/rules`, `/extracted-rules`
Rule type	The kind of requirement a rule states. The list is fixed.	`logic_type`
Compliance profile	A prepared set of rules that lets `/check` and `/classify` run for a court. The Eastern District of New York has one today.	`has_profile`, `judges_profiled`
Rulebook	An official set of numbered rules published as one book. See Rulebooks.	`/rulebooks`
Partial coverage	A live court where some roster entries have no rules of their own, or a rulebook rule whose text has not been read yet.	`meta.with_rules` and `meta.total`; `extraction_status`

Check coverage in code

Two calls answer most coverage questions. The first reads the court, and the second reads its roster.

# The court
curl 'https://api.courtrules.app/api/v1/courts/ca-los-angeles-superior' \
  -H "Authorization: Bearer YOUR_API_KEY"
# The roster
curl 'https://api.courtrules.app/api/v1/judges?district_id=ca-los-angeles-superior' \
  -H "Authorization: Bearer YOUR_API_KEY"

import requests

BASE = "https://api.courtrules.app/api/v1"
HEADERS = {"Authorization": "Bearer YOUR_API_KEY"}


def describe_coverage(district_id):
    court = requests.get(f"{BASE}/courts/{district_id}", headers=HEADERS)
    court.raise_for_status()
    if court.json()["status"] != "live":
        return "The court is mapped, but we hold no rules for it yet."

    judges = requests.get(
        f"{BASE}/judges", headers=HEADERS, params={"district_id": district_id}
    )
    judges.raise_for_status()
    meta = judges.json()["meta"]
    return f"{meta['with_rules']} of {meta['total']} roster entries have rules of their own."


print(describe_coverage("ca-los-angeles-superior"))

The court answers with its status and roster size. The roster answers with a meta object that counts the judges.

{
  "district_id": "ca-los-angeles-superior",
  "name": "Superior Court of California, County of Los Angeles",
  "circuit": null,
  "state": "California",
  "status": "live",
  "judges_mapped": 116
}

{
  "meta": {
    "total": 116,
    "profiled": 0,
    "with_rules": 113,
    "court_level_rules": true
  }
}

The responses above are a sample, and the counts change as rosters change, so read them from the response instead of copying them from this page. The sample court is live. Its with_rules is lower than its total, and a roster entry without rules of its own receives the court-wide rules, which exist when court_level_rules is true. The second response is shortened to its meta object.

Rule types

A rule’s logic_type names the kind of requirement it states, and the fields in its content.structured_data depend on that type. The workflow_phase of a rule names the stage of a case it applies to, which is one of CASE_INITIATION, FILING, MOTION_PRACTICE, TRIAL_PREP or POST_JUDGMENT.

`logic_type`	What it covers
`CourtesyCopyRule`	When and how to deliver courtesy copies to chambers, including triggers and timing
`PageWordLimitRule`	Page and word limits for motions, briefs and other filings, including limits by role
`PreMotionConferenceRule`	Conference and letter requirements before a motion, including steps that must come first
`AdjournmentRequirementRule`	How to ask for an adjournment, extension or continuance
`BundlingRule`	Whether to file related papers together or promptly as each is completed
`FormatConstraint`	Font, margin, spacing and file format requirements
`DocumentRequirement`	Required elements, certificates and structure for court documents
`CommunicationRule`	How, when and why to contact chambers
`SealingProcedure`	How to file sealed or redacted documents, including required motions and formats
`ElectronicFilingRule`	Electronic filing requirements, permitted filing channels and exceptions
`FilingTimingRule`	Filing cutoffs, deemed-filed rules, rejection handling, cure periods and outages
`ServiceRule`	E-service, mail and personal service, proof of service, and service timing
`FilingFeeRule`	Filing fees, payment methods, fee waivers and deferrals
`JuniorLawyerIncentive`	Rules that encourage junior lawyers to take part in oral argument and court proceedings

Pass a type to /extracted-rules as logic_type to read only that kind of rule.

Freshness

Courts rarely change their rules more than a few times a year, so every source is read again at least once a quarter. Court holidays are updated monthly. Each rule carries source_url, the official address it was read from, so you can open the court’s own document and confirm the wording. The cadence section of the coverage page lists each kind of source. To follow new court documents as we find them, subscribe to the Atom feed at courtrules.app/changes.xml. Each entry names the court and links to the new copy and the copy it replaced, and each court’s entries are also on its changes page at courtrules.app/courts/<district_id>/changes. A new version does not always change a rule, so compare the two copies.

Rule layers

For courts with compliance profiles (the Eastern District of New York today), every judge is checked against three rule layers: FRCP (15 national rules), Local Rules (district-specific rules), and Standing Orders (judge-specific rules extracted from each judge’s chambers standing order). Each layer adds to the one above it and can override it. FRCP is the national baseline, Local Rules add district-specific requirements, and Standing Orders are the most specific. Standing orders are also the hardest to find and track.

FRCP (applies to every judge)

15 rules covering captions, signatures, privacy redactions, motion content, discovery conferral, and summary judgment requirements. They are national rules, identical regardless of judge or district.

Local Rules (applies to every judge in the district)

District-specific local rules covering formatting (font, margins, spacing), word limits, filing timing, required documents, and letter motions. The number of local rules varies by district.

Standing Orders (judge-specific)

Judge-specific rules extracted from individual chambers standing orders cover:

Page limits: judge-specific page limits that may differ from district word limits
Courtesy copies: whether required, format, and timing
Pre-motion conferences: whether required before filing, letter format, exemptions
Filing gates: whether all papers must be fully briefed before docketing
Bundling: whether motion, opposition, and reply must be filed together
Briefing schedules: whether changes require court approval

How the layers appear in the API

GET /api/v1/rules returns all three layers for a judge in a court with a compliance profile, including the judge’s standing order rules. For every other court, it returns the court-wide rules and the judge’s own rules. POST /api/v1/check checks a document against all three layers: page and word limits, formatting, structural requirements, privacy redactions, PMC requirements, filing gates, bundling, and courtesy copies. It returns 422 for courts without a compliance profile.

Official rulebooks

Rules from courts and judges are one kind of coverage. Rulebooks are another: the official, numbered rules a court system publishes as one book, such as the California Rules of Court. The API returns each rule with its official text and the filing requirements we read from it. See Rulebooks. Rulebooks sit beside the three layers above, not inside them. A statewide rulebook applies across its state, but the API does not yet merge it into a judge’s rules or a court’s rules. /rules and /extracted-rules?district_id=... answer as they did before and do not include the California Rules of Court, and /check does not use rulebooks. To see a judge’s rules and the statewide rules together, read both and combine them yourself.

Limits

Compliance checks: /check and /classify run for the Eastern District of New York only. Every other court returns 422 from them, and the error points to that court’s rules.
No merged answer: the API returns the rules each source states. It does not resolve conflicts between rules, and it does not compute the final rule set for a filing.
Empty results: an empty list means the API holds no matching rule. It does not mean the court has no such requirement.
Departed judges: a judge who has left the roster returns an empty rules.judge from /rules, and rules.court still lists the court-wide rules.

Common mistakes

Treating live as complete. A live court can have roster entries with no rules of their own. Read has_rules for one judge or meta.with_rules for the court.
Counting people with judges_mapped. In some state courts the roster lists departments or courtrooms, so the number is not a head count.
Listing every court for every request. Each court in GET /courts counts as one row against your daily row limit. Keep the list, or read one court with GET /courts/<district_id>.
Running /check for any live court. Only the Eastern District of New York has a compliance profile. Read the rules of other courts with /rules or /extracted-rules.

Getting started

Read court rules

Check filing compliance

Read official rulebooks

Monitor enforcement actions

Use with AI agents

Why teams read coverage

How coverage works

Key terms

Check coverage in code

Rule types

Freshness

Rule layers

FRCP (applies to every judge)

Local Rules (applies to every judge in the district)

Standing Orders (judge-specific)

How the layers appear in the API

Official rulebooks

Limits

Common mistakes

​Why teams read coverage

​How coverage works

​Key terms

​Check coverage in code

​Rule types

​Freshness

​Rule layers

​FRCP (applies to every judge)

​Local Rules (applies to every judge in the district)

​Standing Orders (judge-specific)

​How the layers appear in the API

​Official rulebooks

​Limits

​Common mistakes

​Related

Why teams read coverage

How coverage works

Key terms

Check coverage in code

Rule types

Freshness

Rule layers

FRCP (applies to every judge)

Local Rules (applies to every judge in the district)

Standing Orders (judge-specific)

How the layers appear in the API

Official rulebooks

Limits

Common mistakes

Related