Skip to main content
🤖 Context for AIs and Code Assistants: The structure of the Penal Execution object is similar to the Lawsuit Object, but contains specific fields such as free_justice and a dedicated object for the last_step (most recent case update). The roles of the parties (person_type) also differ, taking values such as EXECUTADO (convicted person) or REEDUCANDO (inmate).

General Structure

The Penal Execution JSON is organized into the following blocks:
  • Header (Metadata): Data of the execution court, county, dates, and status.
  • Parties (parties): Array containing the State (Authority) and the Inmate.
  • Last Case Update (last_step): Object with the most recent case update highlighted.
  • Case Updates (steps): Complete array with the full history of case updates.
  • Attachments (attachments): Array of linked documents.
  • Related (related_lawsuits): Array of originating lawsuits (criminal action that generated the conviction).

Data Dictionary

1. Lawsuit Header (Object Root)

Internal Metadata: The object may also return the keys created_at, updated_at, and crawler (containing source_name and crawl_id), which are technical metadata about when Judit performed the data extraction.

2. Involved Parties (parties)

Array of objects representing the parties in the execution case.

3. Case Update History (last_step and steps)

The Penal Execution API makes tracking easier by returning the most recent case update highlighted (last_step), in addition to the complete history (steps).

Highlighted Object: last_step

Complete Array: steps

Array of objects identical to the last_step structure, ordered chronologically, containing the entire history of the sentence.

4. Attached Documents (attachments)


Payload Example (Penal Execution)


Next Steps

Now that you understand the Penal Execution data dictionary, move on to integration: