How PACER and CM/ECF Work: Federal Court Data Infrastructure
Most federal court data in the United States flows through two systems: PACER and CM/ECF. Understanding what each system is — and how they relate to each other — clarifies why programmatic access to federal docket data requires more than a standard API call, and why normalization is the core engineering challenge of any court data service.
What CM/ECF Is
CM/ECF — Case Management/Electronic Case Files — is the filing and case management system used across the federal judiciary. When an attorney files a motion, a judge issues an order, or a clerk enters a docketing note, it goes into CM/ECF. The system is the authoritative record for all federal case activity.
There is no single federal court database. Each court runs its own CM/ECF instance — the Southern District of New York runs its own, the Northern District of California runs its own, across all 94 district courts and 94 bankruptcy courts. This distributed architecture means that accessing federal court data at scale requires interfacing with each court's system individually. Two courts running the same CM/ECF software version can still present data in subtly different formats.
What PACER Is
PACER — Public Access to Court Electronic Records — is the public-facing access layer on top of CM/ECF, operated by the Administrative Office of the U.S. Courts. It provides authenticated access to case documents and docket sheets across the federal judiciary. PACER charges $0.10 per page for all access, including docket sheets and documents. A per-document cap of $3.00 applies (equivalent to 30 pages). Accounts that accrue less than $30 in charges in a calendar quarter are not billed for that quarter.
PACER is designed for human use. It is not an API. There is no structured data output, no machine-readable feed, and no official programmatic access method. Extracting data from PACER means parsing HTML docket sheets — work that requires handling format variations between individual court instances, session limits, and inconsistent field labeling across hundreds of independently maintained systems.
The ACMS Transition in Appellate Courts
The federal appellate courts are mid-transition from CM/ECF to ACMS — the Appellate Case Management System. The Second and Ninth Circuits currently operate on ACMS; the remaining circuits still use CM/ECF. ACMS has a different data structure and access pattern than CM/ECF. DocketLayer handles both systems transparently: the same API call works regardless of which system a circuit operates on, and the response schema is identical in both cases.
The Normalization Problem
Because PACER outputs HTML rather than structured data, any service that exposes federal court data via API must parse and normalize that output. Docket sheets vary in structure between courts. Filing categories are labeled inconsistently. Date formats differ. Case numbers follow different conventions by court type. The normalization problem — turning inconsistent HTML from 200-plus independent systems into coherent, queryable JSON — is the primary engineering challenge of federal court data infrastructure.
DocketLayer handles PACER and ACMS access, parsing, normalization, and edge caching. API responses return structured JSON with consistent field names regardless of which underlying court system generated the data. See coverage status for the current state of each court.
What PACER Does Not Cover
PACER covers federal courts only. State courts operate their own case management systems — there is no state-level equivalent of PACER, no standardized access layer, and no cross-state aggregation. State court data is more fragmented than federal data: each state, and often each county within a state, maintains its own portal with its own format and access rules. Building state court coverage requires independent integrations against each state's public portal, using whatever combination of structured endpoints, HTML parsing, and session-based access each system exposes.