- Listed available courts and judges
- Retrieved judge-specific filing rules
- Run a compliance check against those rules
1. See the universe
Start by listing all courts to see what’s available:accessible_districts field in the response to see what’s available to you.
2. List judges in a district
slug field when calling /rules or /check.
3. Get rules for a judge
4. Check a document
Send document metadata to the/check endpoint:
Minimal vs. full document input
Thedocument object only requires page_count and word_count. With just these two fields, the API checks:
- Page and word limits (judge-specific and local rules)
- Courtesy copy requirements
- Pre-motion conference requirements
- Filing gate and bundling rules
Understanding results
Each result has:| Field | Description |
|---|---|
severity | CRITICAL, WARNING, or INFO |
category | What kind of rule (e.g. PAGE_LIMIT, CAPTION, PMC) |
message | Human-readable explanation |
source | Citation (e.g. FRCP 10(a), EDNY LR 7.1(c), Brown SO §2.B) |
status | FAIL, PASS, or ACTION_REQUIRED |
status is:
COMPLIANT: No failures, no action itemsREVIEW: No failures, but action items exist (e.g. courtesy copy reminder)NON_COMPLIANT: At least one FAIL result
Next steps
- API Reference: Full endpoint reference with schemas, parameters, and live playground
- Same Document, Different Judge: See why the same filing gets different results for different judges
- Integration Patterns: How to integrate the API into your application
- Building with AI Agents: Use the OpenAPI spec with LLMs