Skip to main content
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)
Use this field to reliably identify which response represents the most recent state of the lawsuit.
One court fetch per day, per lawsuitFor lawsuit queries (search_type: "lawsuit_cnj"), fetching updated data from the court for a specific lawsuit happens, by default, at most once per day. If you trigger more than one query for the same lawsuit on the same day, the following calls return the data already in cache (cached_response: true), with no new court fetch.This is a performance optimization, not a billing exemption: every request you send is counted and billed normally, as established in your contract, regardless of whether the result came from cache or from a fresh court extraction.
The Asynchronous Lawsuit Query is the most complete and freshest way to fetch a lawsuit: Judit reaches the court in real time, downloads the full tree (cover, parties, lawyers, steps, classes, attachments) and returns it via webhook or polling.
🤖 The lawsuit search route operates asynchronously. The client application must make a POST /requests to start the search, wait for processing (via Webhook or by polling GET /requests/{id}), and, when the status is completed, capture the data via GET /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:
  1. Create the request: You send the lawsuit number.
  2. Track the status: You check if the bot has finished the extraction.
  3. Capture the result: You consume the JSON with the lawsuit data.

Step 1: Creating the Search Request

To initiate a lawsuit search, make a POST 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:
Judit AI (Beta): The artificial intelligence feature (judit_ia) is in Beta. Response time may vary and the summary structure is subject to improvements.

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 — send should_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.
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 the search_key.
Each of those queries for related lawsuits is a new lawsuit search and is billed as such.

Request Example (POST)

Save the value of 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 here

Step 2: Check the Request Status

This step is crucial if you are not using Webhooks. Responses are inserted into the database incrementally as the bots interact with the court.
To find out whether the extraction has finished, query the request history endpoint passing the ID generated in Step 1:
Wait until the status property changes to "completed".

Step 3: Capture the Result (The Lawsuit)

As soon as the status is completed, you can retrieve the complete lawsuit data (and the AI summary, if requested).

Request example (GET)

Response examples

What you receive back

The return is paginated and contains the Lawsuit Object inside the page_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:
In the example above, the first attachment can already be downloaded; the second cannot.

Query without attachment capture

When the request is made without with_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 send with_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.
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

Every request is billed as a lawsuit query + attachment capture. This applies to all calls, including the repetitions made only to capture the following batches of 1,000 attachments. A lawsuit with 2,500 attachments therefore costs 3 lawsuit queries with attachment capture — not one.
If the attachment volume is a cost concern, first run a query without with_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