Different results from api search and web recap archive search.

[pcd444]

There are some differences when using the search api https://www.courtlistener.com/api/rest/v3/search/ and the web search https://www.courtlistener.com/?q.
Some of the differences are as follows,

• The api shows a higher count of documents than the web search.
• The api seems more up to date
• The order by parameter does not seem to work precisely on the api

Is this intended? Are there any work arounds for getting orderby to work better for the api?

[mlissner]

Can you provide some queries that show these characteristics, please?

[pcd444]

Yes, sorry should have thought to do that.

recap search
api search

The web search says there are 561 Cases and 1,053 Docket Entries, the second has a count key with a value of 1557158. Assuming the count key is the number of results that would be much more than either the number of cases or docket entries.

The first result for the web search is case "Sivyer Steel Corporation (Bankr. S.D. Iowa 2018)", the first result for the api search is "Glass as Chapter 11 Trustee v. Emcare, Inc". Sivyer Steel does not appear on the first page of the api search.

If you order by newest cases (that is orderby datefilled), the most recent web result is Optio Rx, LLC (Bankr. D. Del. 2024) which was filled june 7, this search seems to be sorted by the date_filed key (a property of the case). The api gives different results, it seems to be sorting by the entry_date_filed key (a property of the document).

[mlissner]

Thanks. Super helpful. The reason this differs is because the front end is using our new Elastic search engine, but the API is using our older Solr engine. We're working to upgrade v3 of the API to use Elastic too, so it'll match the front end as well, but that's difficult for backwards compatibility reasons (watch your email for more on this though).

While we work on that, v4 of the API is where it's at:

https://www.courtlistener.com/api/rest/v4/search/?q=chapter%3A11%20document_type%3A%22PACER%20Document%22%20short_description%3A%22disclosure%20statement%22%20-short_description%3AApproving&type=r&order_by=score%20desc&available_only=on&court=almb%20alnb%20alsb%20akb%20arb%20areb%20arwb%20cacb%20caeb%20canb%20casb%20cob%20ctb%20deb%20dcb%20flmb%20flnb%20flsb%20gamb%20ganb%20gasb%20hib%20idb%20ilcb%20ilnb%20ilsb%20innb%20insb%20ianb%20iasb%20ksb%20kyeb%20kywb%20laeb%20lamb%20lawb%20meb%20mdb%20mab%20mieb%20miwb%20m

It'll get you the results you're expecting, it'll be faster, and it'll support many more features.

Sorry this is a bit awkward for the moment. We are working to get everything out the door, but it felt wrong to hold back on v4 of the API or on the upgrades to the front end just because the documentation for v4 isn't ready. This should get a lot more clear very soon!