Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/BladimirGS/judicial-backend/llms.txt

Use this file to discover all available pages before exploring further.

Judicial Backend is the server-side application powering the Oficialía de Partes Penal de Segunda Instancia — the court clerk’s office that receives, registers, and tracks criminal appeals at the second-instance level. It exposes a structured REST API consumed by the court’s front-end client (Angular), handling everything from authenticating court clerks to registering new appeals, running advanced searches, and producing Excel and PDF statistical reports for the judiciary.

​
What the system does

When a criminal appeal is filed at a second-instance court, court clerks must record it with full metadata: the originating court (juzgado), the parties involved, the legal typology (tipo de apelación), the room assignment (sala), and any attached annexes. Judicial Backend automates this intake workflow and exposes search, history, and statistics endpoints so supervisors can query case loads, export data to Excel, and generate standardized PDF reports — all without direct database access.

​
Domain modules

The API is organized into four focused modules, each with its own routes, controllers, services, DTOs, mappers, and repository layer:
ModuleBase pathResponsibility
auth/api/authSession management — login, token refresh, and logout via BFF pattern
apelacion/api/apelacionesAppeal intake — create appeals, manage annexes, retrieve catalogues
busqueda/api/busquedasAdvanced search — filter appeals, historical records, and flat-file views; export to Excel and PDF
estadistica/api/estadisticasStatistical reporting — flat and grouped aggregations, multi-sheet Excel exports with charts

​
auth

Handles clerk authentication by delegating credential validation to an external identity provider, receiving a signed JWT in return, and setting a secure HttpOnly refresh-token cookie. The three endpoints are POST /login, POST /refresh, and POST /logout.

​
apelacion

The core data-entry module. Exposes endpoints to fetch dependent catalogues (matters, courts, municipalities, localities, type lists), register a new appeal with its parties and metadata, and attach scanned-document annexes to an existing record.

​
busqueda

A read-only module designed for filtering and exporting. It supports three views — current appeals, flat (plano) projections, and historical records — each with its own catalogue/filter endpoint plus Excel and PDF export endpoints streamed directly to the response.

​
estadistica

Aggregates appeal data by configurable time periods and groups. Provides a flat report, a grouped report, and a multi-sheet Excel export that embeds chart data suitable for managerial dashboards.

​
Technology stack

Judicial Backend is built on a modern, strongly-typed Node.js stack:
  • Runtime: Node.js 18+
  • Framework: Express 5 — async-native routing with improved error propagation
  • Language: TypeScript (strict mode, compiled with tsc)
  • ORM: TypeORM 0.3 — entities, repositories, and stored-procedure calls against SQL Server
  • Database: Microsoft SQL Server (MSSQL) via the mssql / tedious drivers
  • Document generation: ExcelJS (multi-sheet workbooks with styles and charts) + pdfmake (template-driven PDF output)
  • Logging: Pino with pino-pretty for structured, high-throughput JSON logs
  • Validation: class-validator + class-transformer for DTO-level request validation
  • API documentation: Swagger UI served at /api-docs, with spec available as JSON at /api-docs.json
  • Security: express-rate-limit (global + auth-specific limiters), CORS with configurable origins, HttpOnly / Secure cookies, RS256 JWT verification via JWKS

​
BFF authentication pattern

Judicial Backend does not own user credentials. Instead it acts as a Backend for Frontend (BFF) that proxies login requests to a separate identity service:
  1. The front-end sends POST /api/auth/login with { usuario, contrasenia }.
  2. Judicial Backend forwards those credentials — along with the configured ID_SISTEMA — to EXTERNAL_AUTH_URL.
  3. The external service returns a short-lived access token (JWT) and a refresh token.
  4. Judicial Backend sets the refresh token in a Secure; HttpOnly cookie and returns the access token in the response body.
  5. On every subsequent request to a protected route, the protect middleware validates the access token’s signature using the external service’s public JWKS endpoint (/api/AuthJWT/GetJwks), verifying the iss and aud claims against JWT_ISSUER and JWT_AUDIENCE.
This means the application never stores passwords and the front-end never handles refresh tokens directly — a clean separation of concerns suited to a browser-based court management client.

​
Explore further

Quickstart

Clone, configure, and run the server locally in under 10 minutes.

Architecture Overview

Understand the layered module structure, data-source configuration, and shared utilities.

Authentication Module

Deep-dive into the BFF auth flow, JWT validation, token refresh, and the protect middleware.

Login Endpoint Reference

Full request/response schema for POST /api/auth/login.

Build docs developers (and LLMs) love

Get started for freeTalk to us