Cached response (
cached_response)When you create a lawsuit or historical query, Judit first checks whether the data already exists in our database. If it does, we return the result immediately — both in the API response and via webhook (if registered) — with the field cached_response: true.In parallel, Judit triggers a fresh fetch against the courts. If anything has changed, you receive a second response with cached_response: false. That is the most up-to-date result.This is why it is normal to receive two seemingly identical webhooks for the same request_id:- The first one comes from cache (
cached_response: true) - The last one is the updated result (
cached_response: false)
🤖 The lawsuit search route operates asynchronously. The client application must make aPOST /requeststo start the search, wait for processing (via Webhook or by pollingGET /requests/{id}), and, when the status iscompleted, capture the data viaGET /responses.
When to use
Forced refresh
The lawsuit must reflect the latest court state — the datalake cache isn’t enough.
Full cover + steps
You need every cover field, all steps, attachments (up to 1,000 per query) and relationships.
AI summary
Trigger
judit_ia: ["summary"] to get a human-friendly summary ready for your UI.Lawsuits under secrecy
Combine with the Credentials Vault to reach lawsuits that require court login.
If speed beats freshness (e.g. on-screen validation, interactive dashboard), use the Hot Storage Synchronous Query — millisecond response from Judit’s datalake. If you want a single synchronous call with a freshness guarantee at the court (no polling or webhook to manage), see the On-Demand Query.
Asynchronous on-demand flow (overview)
Understanding the Asynchronous Flow
Since data extraction directly from the courts can take a few seconds or minutes (depending on court instability), the Judit API uses an asynchronous request pattern. The flow consists of 3 simple steps:- Create the request: You send the lawsuit number.
- Track the status: You check if the bot has finished the extraction.
- Capture the result: You consume the JSON with the lawsuit data.
Step 1: Creating the Search Request
To initiate a lawsuit search, make aPOST request to the base requests route, sending the desired parameters in the body of the call.
Payload Parameters (Body)
Refer to the table below to configure your search, enable attachments, or trigger Judit AI:Searching Superior Instances
By default, the lawsuit search considers the lawsuit sent in the request and the instances normally associated with that query.When to enable it
When the lawsuit you send originates in the 1st or 2nd instance and you want Judit to also run a complementary search on the Superior Instance systems — STF, STJ, TST and CNJ — sendshould_search_superior_instances: true inside search_params:
Request cost
Enabling this option adds 30% over the standard price of the request, due to the extra processing required to query the Superior Instance systems. Whether the surcharge applies depends on the origin of the lawsuit you send:In other words: if the number you send already belongs to a lawsuit originating in a Superior Instance, the query is billed at the normal price even when the parameter is sent. The surcharge only applies when the complementary search on the superior systems actually happens.
Related lawsuits in other instances
When related lawsuits in other instances are identified, their numbers may be returned in the query result. What comes back is the reference — the related lawsuit’s number — not its full data. To obtain the header, case updates and remaining information of a related lawsuit, you must make a new request for each lawsuit you want, using the returned number as thesearch_key.
Each of those queries for related lawsuits is a new lawsuit search and is billed as such.
Request Example (POST)
request_id, as you will need it for the next steps.
🚀 Shortcut: Automate with Webhooks (Recommended)If you have a Webhook URL configured, Steps 2 and 3 below are entirely optional.
Instead of programming your application to keep polling the request status, the Judit API will send the found lawsuits incrementally directly to your server as soon as they are captured, finishing the flow with a
request_completed event.👉 Learn how to configure and receive Webhooks hereStep 2: Check the Request Status
To find out whether the extraction has finished, query the request history endpoint passing the ID generated in Step 1:status property changes to "completed".
Step 3: Capture the Result (The Lawsuit)
As soon as the status iscompleted, you can retrieve the complete lawsuit data (and the AI summary, if requested).
Request example (GET)
Response examples
See response examples (3 variants)
See response examples (3 variants)
What you receive back
The return is paginated and contains the Lawsuit Object inside thepage_data array. If you requested Judit AI (use_judit_ia: true), the judit_ia object brings a human-readable summary of the lawsuit + structured listing of parties, classes, subjects and movements.
How attachments work (attachments)
This is the part of the lawsuit query that raises the most questions, so it is worth understanding the mechanism before requesting the capture.
The attachments array always comes in the response
Every lawsuit query returns the attachments array inside the Lawsuit Object — whether or not you sent with_attachments. Each item in the array is an object representing one attachment that exists in the lawsuit today, with its identifier, name, date and extension.
In other words: the array is the reference of every attachment in the lawsuit, not the list of files Judit has already downloaded. Seeing an attachment listed there does not mean the file was captured.
What matters is each attachment’s status
Inside each object in the array there is a status property. It — and only it — tells you whether that specific file has been captured and is available for download:
Query without attachment capture
When the request is made withoutwith_attachments (or with with_attachments: false), the attachments array still comes back listing every attachment in the lawsuit — but all of them with status: "pending". You see what exists in the lawsuit, and no file is downloaded.
This is useful to size up the lawsuit before requesting the capture: you can count how many attachments exist and work out how many requests will be needed.
Query with attachment capture and the 1,000 limit
When you sendwith_attachments: true, Judit captures up to 1,000 attachments per request. In the response, those up to 1,000 attachments move from pending to done. The rest stay pending.
If the lawsuit has more than 1,000 attachments, you must repeat the lawsuit query for the same CNJ, again with with_attachments: true. With each new request, the next batch of up to 1,000 attachments moves from pending to done.
Here is how it looks for a lawsuit with 2,500 attachments:
The capture is finished when no attachment in the array has
status: "pending". There is no field such as “X attachments remaining”: the correct way to know you are done is to iterate over the attachments array and check each object’s status.
Recommended flow
1
Run the query requesting attachments
Send the request for the desired CNJ with
"with_attachments": true.2
Iterate over the attachments array in the result
In Step 3, when capturing the result, iterate over
attachments and count how many objects have status: "pending".3
Repeat while there are pending ones
If there are still attachments in
pending, send a new lawsuit query for the same CNJ, also with "with_attachments": true. Each repetition captures the next batch of up to 1,000.4
Stop when there are no pending ones left
When every object in the array has
status: "done", all of the lawsuit’s attachments have been captured.Billing for the repetitions
If the attachment volume is a cost concern, first run a query withoutwith_attachments to find out how many attachments the lawsuit has and estimate the number of repetitions. That initial query is billed as a lawsuit query, without the attachment capture cost.
Next steps
- 👉 Webhook & Callbacks — receive automatic notifications when the search ends.
- 👉 Hot Storage (sync) — for an immediate response (cached).
- 👉 Has Lawsuits? (true/false) — lightweight boolean gate.
- 👉 Lawsuits Count — only the total.
- 👉 Error Codes — troubleshooting.