Deadline Calculation in Federal Court is Harder Than You Think

Every legal tech product eventually hits the same wall: the rules aren't in a database. They're in PDFs. Hundreds of pages of local rules and standing orders, per judge, per district, updated whenever that judge feels like it.

You can throw an LLM at a motion and get something that reads well. But can it tell you that Judge Albright in WDTX allows 13pt font while Judge Caproni in SDNY requires 12pt? Can it reliably compute a deadline when the rule implies a holiday exclusion buried on page 4 of a standing order? Probably not. And "probably" isn't good enough when a missed deadline means a terminated motion.

The CourtRules API gives you structured, verified constraints extracted from the judge's actual standing orders. No inference. No hallucination risk. Deterministic data you can build on.

What Raw Rules Actually Look Like

Open any standing order PDF. You'll find something like this:

"Opposition briefs must be filed within 14 days of service of the moving papers. Reply briefs may be filed within 7 days thereafter."

That's a string. Your code needs a data structure. We normalize it into a TemporalConstraint:

{
  "type": "TEMPORAL",
  "value": 14,
  "unit": "DAYS",
  "trigger_event": "SERVICE_OF_MOTION",
  "direction": "AFTER",
  "is_business_days": false
}

Now you can do math with it. That is_business_days flag matters more than you'd expect. Some judges specify "10 business days" for the same type of filing where others say "14 days." Your date library needs to handle both, and your code needs to know which one it's dealing with.

Authentication

Grab an API key from the dashboard. Standard Bearer token:

Computing a Deadline

Say you need the response deadline for a Motion for Summary Judgment. Hit /v1/docket/calculate with the judge ID and trigger event:

const calculateDeadline = async (
  judgeId: string,
  triggerDate: Date
) => {
  const response = await courtRules.docket.calculate({
    trigger_event: "Service of Motion for Summary Judgment",
    judge_id: judgeId, // e.g., "sdny-caproni"
    case_type: "CIVIL"
  });

  return response.deadlines.map(d => ({
    action: d.action,
    // API returns the offset. You handle calendar logic.
    due_date: addDays(triggerDate, d.due_date_offset),
    rule_source: d.rule_source,
    citation: d.citation
  }));
};

Notice the API returns an offset (+14 days), not an absolute date. That's intentional. Federal holiday calendars and state holiday calendars don't always overlap, and the right answer depends on your jurisdiction. We give you the constraint. You apply the calendar.

Chaining Deadlines

Federal motion practice is sequential: Motion, then Opposition, then Reply. Each deadline triggers from the previous one. When you query for "Summary Judgment," the API returns the full chain:

{
  "trigger_event": "Service of Motion",
  "jurisdiction": "SDNY (Caproni)",
  "deadlines": [
    {
      "action": "File Opposition Brief",
      "due_date_offset": 14,
      "unit": "days",
      "id": "opp_brief"
    },
    {
      "action": "File Reply Brief",
      "due_date_offset": 7,
      "unit": "days",
      "trigger": "opp_brief" // chains off the previous deadline
    }
  ]
}

The trigger field links the reply deadline to the opposition deadline. Your UI can render this as a timeline without any manual wiring.

Compliance Checks

Deadlines aren't the only thing that gets filings rejected. Formatting is worse. Wrong font size, too many pages, missing table of contents. These are mechanical errors, and they happen constantly.

The /v1/compliance/check endpoint validates document metadata against the judge's requirements before you file:

const checkBrief = async (fileMetadata: FileMetadata) => {
  const compliance = await courtRules.compliance.check({
    judge_id: "wdtx-albright",
    document_type: "Claim Construction Brief",
    page_count: fileMetadata.pages
  });

  if (compliance.status === "RISK_DETECTED") {
    compliance.violations.forEach(v => {
      console.warn(
        `${v.severity}: ${v.rule} (Limit: ${v.limit}, Actual: ${v.actual})`
      );
    });
  }
};

One practical note: always surface the rule_source and citation fields to your end users. Lawyers need to see where a constraint comes from. They won't trust a system that just says "your brief is too long" without pointing to the specific standing order paragraph that says so.

Caching

Standing orders don't change every day, but they do change without warning. Cache rules for 24 hours, and use our webhooks to invalidate the cache immediately when a judge updates a PDF. That way you're not hammering the API on every request, but you're also not serving stale data when it matters.

Get Started

If you're building deadline calculation, docketing, or filing compliance into your product, the hard part isn't the code. It's keeping up with 700+ judges who each have their own rules and change them on their own schedule. That's what the API handles for you.