Envío de Documentos y Mantenimiento¶
API REST para la firma digital de documentos PDF (PAdES). Recibe documentos, los deja disponibles para que un componente de escritorio los firme, y entrega el resultado — además de administrar los clientes, usuarios y procesos de firma que usan ese flujo.
Esta documentación es autocontenida: no asume que ya viste la documentación de ssigner-server (la app de escritorio con la que este servicio se coordina). Si vas a construir un front de administración o integrar un sistema externo contra esta API, todo lo que necesitas está acá.
Qué hace este servicio¶
- Recibe documentos PDF para firmar (
POST /api/v1/documentos), junto con el identificador del proceso de firma al que deben ir. - Consulta el estado de un documento y permite descargarlo una vez firmado.
- Administra clientes (las organizaciones a las que se les presta el servicio), usuarios (personas: un admin único y firmantes por cliente) y la asignación de qué procesos puede operar cada firmante.
- Expone dos formas de autenticación independientes: credenciales de sistema (machine-to-machine) y login de persona (con rol).
Qué NO hace este servicio¶
- No firma documentos. La firma digital la ejecuta un componente de escritorio aparte (
ssigner-server), que vigila una carpeta compartida y usa una librería de firma externa. Este servicio nunca invoca esa librería ni contiene lógica de PAdES. - No expone un endpoint para configurar procesos de firma (certificados, rutas, apariencia de la firma). Eso se configura manualmente desde la app de escritorio, por personal de soporte — ver la sección "Cómo se coordina con el resto del sistema" más abajo.
Cómo se coordina con el resto del sistema¶
Aunque esta API no firma nada directamente, depende de otro componente para completar el trabajo: una aplicación de escritorio (JavaFX) llamada ssigner-server, que corre siempre en segundo plano en el mismo servidor. Los dos componentes nunca se llaman entre sí — ninguno expone un endpoint que el otro consuma. Se coordinan únicamente a través de:
- Una base de datos SQLite compartida (
ssigner.db) — cada uno lee y escribe un subconjunto de tablas distinto (ver Modelo de datos). - Carpetas de archivos compartidas — cada proceso de firma tiene su propia carpeta de entrada y de salida; este servicio escribe en la de entrada y lee de la de salida.
En términos prácticos, para vos que vas a integrar contra esta API: enviás un documento, y en algún momento (normalmente segundos) deja de estar EN_PROCESO y pasa a FIRMADO — sin que tengas que saber ni que te importe qué componente físico lo firmó.
Índice de esta documentación¶
| Documento | Contenido |
|---|---|
| 01 · Arquitectura y flujo | Los dos componentes, cómo se coordinan, el pipeline completo de un documento |
| 02 · Autenticación y roles | Los dos mecanismos de login, roles, JWT, credenciales |
| 03 · Modelo de datos | Diagrama ER, tablas, quién escribe cada una |
| 04 · Referencia de API | Cada endpoint, con ejemplos reales de request y response |
| 05 · Catálogo de errores | Todos los códigos de error, su HTTP status y su significado |
| 06 · Guía de integración | Paso a paso para construir un front de administración, de punta a punta |
openapi.yaml | Spec OpenAPI 3.0, para generar clientes o importar en herramientas de API |
postman/ | Colección de Postman lista para usar, con entornos de desarrollo y producción |
Datos rápidos¶
| Base URL (producción) | https://agente.plussigner.com |
| Formato de autenticación | Authorization: Bearer <token> (JWT, HS512) |
| Formato de fechas | ISO-8601 UTC (Instant), ej. 2026-08-14T15:30:00Z |
| Base de datos | SQLite, compartida con ssigner-server |
| Framework | Spring Boot 3.3.4 |
| CORS | Habilitado para cualquier origen por ahora (mientras no hay un dominio de front definido) — hay que restringirlo a los dominios reales antes de ir a producción con un front específico |