/check endpoint runs your filing through every applicable rule and returns results in under a millisecond. There’s no LLM involved, no network calls, nothing non-deterministic. Same input always gives you the same output.
Every result tells you exactly where the rule comes from (e.g., “FRCP 10(a)”, “EDNY LR 7.1(c)”, “Brown SO §2.B”) so you can look it up in the original document yourself.
Key terms
What gets checked
How limits work
Page limits and word limits are independent. Both apply at the same time. You can pass the word limit but fail the page limit, or the other way around. Opposition briefs use the same limits as support briefs. When you senddocument_scope: "brief_opposition", the API checks limits under brief_support automatically.
When structural checks apply
Not every structural check runs on every filing. Each check has a trigger condition:
If you don’t include a particular section in your request (for example, you skip the
format object), checks that depend on it are silently skipped. You only get results for what you send.
Pre-motion conference logic
Some judges require a pre-motion conference (PMC) before you can file certain motions. The API walks through a decision tree to figure out whether PMC applies to your filing: In EDNY: Judge Amon requires a PMC letter before any dispositive motion. Judge Block does not. A Rule 56 motion that passes PMC with Block would fail with Amon ifpmc_completed: false.
A few details: some judges require the opposing party to respond within a set number of days (response_required, response_days). Some judges only require PMC for represented counsel, not pro se parties (requires_represented_counsel).