Skip to main content

​
Integration Patterns

Four patterns for integrating the API, from lightweight pre-flight checks to full document analysis pipelines.

​
Overview

                               Court Rules Linter API
                              ________________________
                             |                        |
  Document draft  ---------> | 1. Pre-flight Check    |  Quick pass/fail on limits
                             |    POST /check         |  (page_count + word_count only)
                             |________________________|
                                        |
                                        v
                              ________________________
                             |                        |
  Parsed document ---------> | 2. Full Compliance     |  All structural checks
                             |    POST /check         |  (caption, signature, sections...)
                             |________________________|
                                        |
                                        v
                              ________________________
                             |                        |
  UI display      ---------> | 3. Rules Lookup        |  Show applicable rules
                             |    GET /rules          |  before user starts drafting
                             |________________________|
                                        |
                                        v
                              ________________________
                             |                        |
  Raw document    ---------> | 4. Classify + Check    |  LLM analyzes text,
  text                       |    POST /classify      |  then auto-checks
                             |    POST /check         |
                             |________________________|

​
Pattern 1: Pre-flight check

Call /check with just page_count and word_count while the user is still drafting. This catches the most common compliance failures (page/word limits, PMC requirements, filing gates) with minimal input. 
curl -X POST https://api.courtrules.app/api/v1/check \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "judge_slug": "frederic-block",
    "district_id": "edny",
    "document_scope": "brief_support",
    "motion_type": "Rule_56",
    "document": {
      "page_count": 28,
      "word_count": 8500
    }
  }'
When to use: During drafting, on document save, or before the user starts formatting. Fast (sub-millisecond) and catches the failures that waste the most time. What you get: Page limit, word limit, courtesy copy, PMC, filing gate, and bundling checks. What you miss: Structural checks (caption, signature, sections), formatting checks (font, margins), and privacy checks. These require parsing the document.

​
Pattern 2: Full compliance check

After your application parses the document (e.g., extracting caption fields, checking for a table of contents, measuring font sizes), send the full document structure to /check. 
import requests

result = requests.post(
    "https://api.courtrules.app/api/v1/check",
    headers={"Authorization": "Bearer YOUR_API_KEY"},
    json={
        "judge_slug": "gary-r-brown",
        "district_id": "edny",
        "document_scope": "brief_support",
        "motion_type": "Rule_56",
        "pmc_completed": True,
        "document": {
            "page_count": 18,
            "word_count": 7200,
            "caption": {
                "present": True,
                "has_court_name": True,
                "has_case_title": True,
                "has_docket_number": True,
                "has_document_designation": True,
            },
            "signature_block": {
                "present": True,
                "has_attorney_name": True,
                "has_firm_name": True,
                "has_address": True,
                "has_email": True,
                "has_phone": True,
                "is_electronic_signature": True,
            },
            "sections": {
                "has_toc": True,
                "has_toa": True,
                "has_certificate_of_compliance": True,
                "certificate_word_count": 7200,
                "has_certificate_of_service": True,
                "has_numbered_paragraphs": True,
                "has_56_1_statement": True,
                "has_56_1_counterstatement": False,
                "has_proposed_amended_pleading": False,
                "has_verbatim_discovery_text": False,
                "has_conferral_certification": False,
                "has_notice_of_motion": True,
                "has_memorandum_of_law": True,
                "has_supporting_affidavits": True,
                "has_pro_se_sj_notice": False,
            },
            "format": {
                "primary_font_size_pt": 12,
                "footnote_font_size_pt": 10,
                "margin_inches": 1.0,
                "line_spacing": "double",
            },
            "privacy": {
                "contains_full_ssn": False,
                "contains_full_dob": False,
                "contains_minor_full_name": False,
                "contains_full_financial_account": False,
            },
        },
    },
).json()

# Show results to user
for r in result["results"]:
    icon = {"FAIL": "X", "PASS": "OK", "ACTION_REQUIRED": "!"}[r["status"]]
    print(f"[{icon}] {r['message']} ({r['source']})")
When to use: Before filing, after the document is finalized. This is the comprehensive check. What you get: All checks the engine supports — limits, formatting, structure, privacy, consistency, and judge-specific standing order rules.

​
Pattern 3: Rules lookup

Call /rules to display applicable rules proactively — before the user even starts drafting. Show them the requirements for their judge and motion type up front. 
const resp = await fetch(
  "https://api.courtrules.app/api/v1/rules?" +
    new URLSearchParams({
      judge_slug: "carol-bagley-amon",
      district_id: "edny",
      document_scope: "brief_support",
      motion_type: "Rule_56",
    }),
  { headers: { Authorization: "Bearer YOUR_API_KEY" } },
);
const { rules } = await resp.json();

// Display standing order highlights
if (rules.standing_order) {
  console.log("Judge-specific requirements:");
  for (const rule of rules.standing_order) {
    console.log(`  - ${rule.summary} (${rule.source})`);
  }
}
When to use: When the user selects a judge or starts a new filing. Show them the rules before they draft, not after. What you get: The complete rule set organized by authority layer (FRCP, Local Rules, Standing Order), filtered to the relevant document type and motion.

​
Pattern 4: Classify + Check pipeline

For applications that have the document text but haven’t parsed its structure, use /classify to let the LLM extract metadata, then feed the result directly into /check. 
import requests

headers = {"Authorization": "Bearer YOUR_API_KEY"}

# Step 1: Classify the document
classify_resp = requests.post(
    "https://api.courtrules.app/api/v1/classify",
    headers=headers,
    json={
        "judge_slug": "gary-r-brown",
        "district_id": "edny",
        "text": document_text,  # raw text from PDF extraction
        "filename": "motion_sj_support.pdf",
    },
).json()

print(f"Detected: {classify_resp['classification']['document_scope']}")
print(f"Confidence: {classify_resp['classification']['confidence']}")

# Step 2: Check compliance using the pre-built request
check_resp = requests.post(
    "https://api.courtrules.app/api/v1/check",
    headers=headers,
    json=classify_resp["check_request"],  # pass directly, no modification
).json()

print(f"Status: {check_resp['summary']['status']}")
When to use: When you have raw document text (from PDF extraction, OCR, or user paste) but haven’t built your own document parser. The /classify endpoint handles the analysis and produces a ready-to-use /check request. Latency note: /classify calls an LLM and takes 5-15 seconds. /check is deterministic and sub-millisecond. Plan your UX accordingly — show a loading state for classification, then instant results for the compliance check.

​
Choosing a pattern

PatternInput neededLatencyCoverage
Pre-flightpage_count + word_count< 1msLimits + standing order checks
Full complianceParsed document structure< 1msAll checks
Rules lookupJudge + document type< 1msRule display (no pass/fail)
Classify + CheckRaw document text5-15s + < 1msAll checks (LLM-extracted structure)
Most integrations use Pattern 1 during drafting and Pattern 2 before filing. Pattern 3 is for proactive UIs. Pattern 4 is for applications that don’t have their own document parser.