How is docket_id in the PACER Data API produced?

[AliSMAmin]

Hey I am working on an application that uses the original government managed PACER API to search for a case. When we get a response we receive:

      "courtCase": {
        "courtId": "alndc",
        "caseId": 54011,
        "caseYear": 1995,
        "caseNumber": 17218,
        "caseOffice": "2",
        "caseType": "cv",
        "caseTitle": "Sandig v. Dow Corning",
        "dateFiled": "1995-11-06",
        "dateTermed": "1996-10-16",
        "natureOfSuit": "365",
        "jurisdictionType": "Civil",
        "effectiveDateClosed": "1996-10-16",
        "caseLink": "https://ecf.alnd.uscourts.gov//cgi-bin/iqquerymenu.pl?54011",
        "caseNumberFull": "2:1995cv17218"
      },
      "dateFiled": "1995-11-06",
      "dateTermed": "1996-10-16",
      "natureOfSuit": "365",
      "caseOffice": "2",
      "caseNumberFull": "2:1995cv17218",
      "caseType": "cv",
      "caseTitle": "Sandig v. Dow Corning"

However the PACER Data API from CourtListener takes a "docket_id" parameter, as in,

curl -v \ --header 'Authorization: Token 1f20378df9a0639d27f4453fe5c61c75dc09b347' \ "https://www.courtlistener.com/api/rest/v3/dockets/4214664/"

How is this docket_id generated? Is it an internal CL sequential identifier or is it produced from the original PACER database somehow? It doesn't seem to be case_id and I can't see what it correlates to.

Would I need to first do a search using PACER's CaseNumberFull to obtain docket_id then use docket_id with the PACER Data API from CL to get more info?

Thank you!

[AliSMAmin]

We are using the original government-managed PACER API to search for a case. From PACER, we receive data including caseNumberFull and caseTitle. When a user selects a case from our PACER search results, we take the caseNumberFull (which seems to correspond to CL docket_number) and caseTitle (which seems to correspond to CL case_name) and input them into a CourtListener search URL. After retrieving the search results from CourtListener, we filter them using timestamps to identify the most recent case returned. We are assuming the most recently updated case is the most accurate result when multiple duplicate results appear.

Once we identify the correct case, we extract the docket_id from that result and send it to the CourtListener PACER Data API. We use that to query for dockets, docket entries, and documents.

Is this strategy accurate and effective for retrieving case details, or is there a simpler or more efficient way to achieve the same result?

[AliSMAmin]

It just seems like there isn't a lot of interoperability between the original PACER API and the CourtListener APIs. There's no smooth transition from a single identifying piece of info from the PACER API to docket information on CourtListener. What am I missing? It feels like we have 2-3 extra unnecessary steps here. There should be some single string we can input from PACER API to get to a docket on CourtListener, right?

[mlissner]

A couple thoughts. First, you can use the caseId in our search system. Case ID's are only unique within a court, so you'll want a query like:

https://www.courtlistener.com/?q=pacer_case_id%3A54011&type=r&order_by=score%20desc&court=alnd

That can be made into an API request easily enough:

https://www.courtlistener.com/api/rest/v4/search/?q=pacer_case_id%3A54011&type=r&order_by=score%20desc&court=alnd

So that's one approach! You can also use our DB-based APIs:

https://www.courtlistener.com/api/rest/v4/dockets/?pacer_case_id=54011&court=alnd

So that should get you off to the races. But, I have to ask why you're bothering with the PACER search API. We have a few features coming up:

1. We're going to start crawling PACER aggressively so that we have the basic metadata for every case within a few minutes (this will include case name, pacer_case_id, judges, and date filed).
2. We have a new feature coming out soon that will allow you to get alerts whenever a query in our search system has new hits.
3. We have webhooks that alerts can be sent to.

This isn't all set to go yet, but when it does, it might allow you to create an alert for cases of interest, then listen to the webhook to see when there's new stuff.

[AliSMAmin]

Hey @mlissner thanks so much for responding. @mlevy5722 and I are working on this together. We initially used the PACER API because we hadn't come across CourtListener and didn't know its features yet. We have some questions. The most pressing one is:

When can we expect the aggressive PACER crawling to start?

[mlissner]

Yeah, that's a fair question. Here's the roadmap for that:

1. We're doing a huge crawl of PACER right now to gather any free opinions we don't already have. That's going to take a few weeks at best.
2. When that completes, we'll be doing a sweep of every pacer case ID to make sure we have every case. That'll probably take a few weeks.
3. When that finishes, we'll be able to turn on the crawler to get every case, but we can't turn that on until we've completed those other two crawls or it's quite likely that PACER will block our crawlers.

So, it's one at a time, I'm afraid, though everything is code-complete and merged into CL already.

How did you find CourtListener, eventually? How did you miss it at first, so we can try to help the next person better?

[AliSMAmin]

Hey @mlissner we are planning to meet and discuss on a call on Weds. Thank you!