Modelos JSON y mapeo de campos para integrar publicaciones judiciales al ERP o CRM
Una guía práctica para diseñar payloads JSON, mapear procesos y plazos, evitar duplicaciones y conectar el monitoreo jurídico con Salesforce, TOTVS y calendarios.
Conoce una forma más simple de organizar tu monitoreo jurídico
En este artículo8 secciones
- Qué son los modelos JSON para publicaciones judiciales
- Cómo mapear campos de publicaciones judiciales al ERP o CRM
- Guía paso a paso para diseñar una integración segura
- Diez modelos JSON listos para publicaciones judiciales
- Cómo evitar duplicaciones y mantener la cadena de custodia
- Cómo encaja el monitoreo del Pocket Jurídico en esta arquitectura
- Cómo sincronizar plazos judiciales con Google Calendar y Outlook
- Errores frecuentes y lista de validación antes de publicar
Qué son los modelos JSON para publicaciones judiciales
Los modelos JSON para publicaciones judiciales permiten transformar una notificación del diario o una movimentación procesal en datos que otros sistemas pueden entender. En lugar de copiar el contenido a una planilla, el equipo jurídico puede enviar un evento estructurado a un ERP, CRM, gestor de procesos o calendario.
La estructura correcta debe conservar tres dimensiones: el hecho jurídico, el proceso al que pertenece y la acción que debe realizarse. Por ejemplo, una nueva publicación puede contener el tribunal, el número CNJ, el texto original, la fecha de disponibilidad, un resumen, un plazo extraído y los documentos relacionados.
En la práctica, el valor no está solamente en enviar más datos. Está en enviar datos consistentes, identificables y auditables. Un CRM necesita saber si debe crear un registro, actualizarlo o ignorar el evento porque ya fue procesado.
Para oficinas de abogados y departamentos jurídicos con alto volumen, esta diferencia evita dos problemas frecuentes: la duplicación de procesos y la pérdida de contexto entre la publicación, el responsable y el plazo. La integración debe reducir trabajo manual, no trasladarlo a otra pantalla.
Cómo mapear campos de publicaciones judiciales al ERP o CRM
Antes de crear un webhook, separa el modelo en entidades. La entidad proceso identifica el expediente; la entidad publicación registra el acto divulgado; la entidad plazo representa una obligación temporal; y la entidad documento conserva los archivos o evidencias relacionadas.
Un campo como numero_cnj debe ser tratado como identificador de negocio, no como un simple texto visible. En Salesforce puede alimentar un campo personalizado como Numero_CNJ__c en un objeto de caso u oportunidad. En TOTVS, el mismo valor puede vincularse al código del proceso, expediente o registro jurídico según la configuración del producto y del módulo utilizado.
El mapeo debe documentar el tipo, la obligatoriedad, el formato y la regla de actualización. Por ejemplo, fecha_disponibilidad puede ser obligatoria y usar ISO 8601, mientras que resumen_ia puede ser opcional y actualizarse sin sobrescribir el texto original.
Una matriz mínima de mapeo puede contener estas columnas: campo de origen, descripción, tipo, destino Salesforce, destino TOTVS, regla de transformación y comportamiento cuando el valor está vacío. Esta matriz se convierte en el contrato entre el jurídico, el equipo de tecnología y el proveedor de integración.
Para Salesforce, la documentación oficial de la API REST explica cómo trabajar con recursos y campos de objetos. En TOTVS, conviene validar siempre el endpoint y el modelo de datos de la versión contratada, porque los nombres y recursos pueden variar entre productos y módulos.
Guía paso a paso para diseñar una integración segura
- 1
Define el evento de negocio
Comienza por eventos comprensibles para el equipo jurídico: nueva publicación, actualización de movimentación, plazo extraído, documento adjuntado o comentario interno. Evita crear un evento genérico llamado actualización, porque dificulta las reglas de automatización y auditoría.
- 2
Establece la clave única
Combina un identificador estable del proceso con el identificador de la publicación y una versión del evento. El número CNJ por sí solo no es suficiente, ya que un mismo proceso puede generar cientos de publicaciones y movimentaciones.
- 3
Normaliza fechas y zonas horarias
Envía timestamps en UTC con formato ISO 8601, por ejemplo 2026-10-22T14:30:00Z. Conserva además la zona horaria de origen y la fecha jurídica local cuando la regla del plazo dependa del calendario brasileño.
- 4
Separa original, interpretación y acción
Guarda el texto original de la publicación sin alteraciones. En campos separados, registra el resumen generado por una IA, el plazo identificado, la confianza de la extracción y la acción sugerida para que una interpretación no se confunda con la fuente.
- 5
Decide la estrategia de actualización
Usa upsert para crear o actualizar registros con una clave externa, y utiliza eventos inmutables para la evidencia histórica. Una corrección de metadatos no debería borrar el contenido que fue recibido originalmente.
- 6
Prueba casos excepcionales
Incluye procesos con múltiples partes, instancias distintas, documentos repetidos, publicaciones sin plazo y eventos recibidos fuera de orden. También prueba reintentos, respuestas 429, interrupciones de red y payloads parcialmente incompletos.
- 7
Monitorea el resultado
Registra el estado de entrega, el código HTTP, el identificador de correlación y la fecha del último intento. La tasa de errores y los eventos pendientes deben estar visibles para que el equipo no descubra una falla al revisar un plazo vencido.
Diez modelos JSON listos para publicaciones judiciales
Los siguientes ejemplos usan una estructura común: event_id identifica el mensaje, source_id identifica el registro en el sistema de monitoreo y correlation_id permite rastrear la operación entre servicios. Los nombres de campos de Salesforce y TOTVS aparecen dentro de mapping para facilitar la implementación, pero deben adaptarse a los campos personalizados de cada ambiente.
- Nueva publicación judicial:
{ "event_type": "publication.created", "event_id": "pj_pub_8f31_v1", "occurred_at": "2026-10-22T12:40:00Z", "source_id": "pub_8f31", "process": { "numero_cnj": "0001234-56.2026.8.26.0100", "court": "TJSP", "instance": "primera", "parties": ["Empresa Alfa", "Parte Beta"] }, "publication": { "available_date": "2026-10-22", "publication_date": "2026-10-23", "journal": "Diario de Justicia Electrónico", "content_original": "Texto íntegro de la publicación...", "source_url": "https://fuente-ejemplo.local/pub_8f31" }, "mapping": { "salesforce": {"Numero_CNJ__c": "process.numero_cnj", "Fecha_Publicacion__c": "publication.publication_date"}, "totvs": {"numero_processo": "process.numero_cnj", "data_publicacao": "publication.publication_date"} } }
- Actualización de movimentación:
{ "event_type": "case.movement.updated", "event_id": "pj_mov_91aa_v1", "occurred_at": "2026-10-22T13:05:12Z", "source_id": "mov_91aa", "process_key": "0001234-56.2026.8.26.0100", "movement": { "type": "despacho", "description": "Intimación de la parte para manifestarse", "date": "2026-10-22", "sequence": 47 }, "external_keys": { "salesforce": "sf_case_00381", "totvs": "totvs_proc_7781" } }
- Plazo extraído por una IA:
{ "event_type": "deadline.extracted", "event_id": "pj_dead_4c20_v1", "occurred_at": "2026-10-22T13:10:00Z", "source_id": "pub_8f31", "process_key": "0001234-56.2026.8.26.0100", "deadline": { "description": "Presentar manifestación", "start_date": "2026-10-23", "due_date": "2026-11-06", "business_days": 10, "calendar": "Brasil, tribunal correspondiente", "status": "pending" }, "ai": { "provider": "modelo-configurado-por-el-cliente", "summary": "La parte debe presentar manifestación dentro del plazo identificado.", "confidence": 0.91, "requires_human_review": true }, "mapping": { "salesforce": {"Fecha_Vencimiento__c": "deadline.due_date", "Descripcion_Plazo__c": "deadline.description"}, "totvs": {"data_limite": "deadline.due_date", "observacao": "ai.summary"} } }
- Documento anexado:
{ "event_type": "document.attached", "event_id": "pj_doc_2e71_v1", "occurred_at": "2026-10-22T13:20:00Z", "source_id": "doc_2e71", "process_key": "0001234-56.2026.8.26.0100", "document": { "name": "despacho_22_10_2026.pdf", "mime_type": "application/pdf", "size_bytes": 284190, "sha256": "hash-do-arquivo", "download_url": "https://arquivos-ejemplo.local/doc_2e71", "is_original": true }, "mapping": { "salesforce": {"ContentVersion.Title": "document.name", "ContentVersion.Checksum": "document.sha256"}, "totvs": {"nome_arquivo": "document.name", "hash_arquivo": "document.sha256"} } }
- Comentario colaborativo:
{ "event_type": "publication.comment.created", "event_id": "pj_com_71b2_v1", "occurred_at": "2026-10-22T13:25:00Z", "source_id": "com_71b2", "process_key": "0001234-56.2026.8.26.0100", "comment": { "author_id": "user_184", "text": "Revisar la estrategia antes del vencimiento.", "mentions": ["user_209"], "visibility": "internal" }, "mapping": { "salesforce": {"Comentario_Juridico__c": "comment.text", "Autor_Comentario__c": "comment.author_id"}, "totvs": {"comentario_interno": "comment.text", "usuario": "comment.author_id"} } }
- Resumen generado a partir del contenido original:
{ "event_type": "publication.summary.updated", "event_id": "pj_sum_6a90_v2", "occurred_at": "2026-10-22T13:30:00Z", "source_id": "pub_8f31", "process_key": "0001234-56.2026.8.26.0100", "summary": { "text": "El tribunal solicitó una manifestación de la parte.", "actions": ["Revisar el despacho", "Preparar manifestación"], "model_version": "modelo-registrado", "generated_at": "2026-10-22T13:29:40Z", "source_hash": "hash-del-texto-original" } }
- Identificación o actualización de la carátula del proceso:
{ "event_type": "case.cover.updated", "event_id": "pj_case_55d1_v3", "occurred_at": "2026-10-22T13:35:00Z", "source_id": "case_55d1", "process": { "numero_cnj": "0001234-56.2026.8.26.0100", "class": "Procedimiento común", "subject": "Contrato comercial", "jurisdiction": "Foro central", "judge": "Nombre no informado", "status": "en trámite" }, "identity": { "pocket_case_id": "case_55d1", "cover_hash": "hash-de-la-caratula" } }
- Historial o lote de movimentaciones:
{ "event_type": "case.history.synced", "event_id": "pj_hist_90ac_v1", "occurred_at": "2026-10-22T13:40:00Z", "source_id": "case_55d1", "process_key": "0001234-56.2026.8.26.0100", "history": { "from_sequence": 40, "to_sequence": 47, "movements": [ {"sequence": 41, "date": "2026-09-10", "type": "petición", "description": "Petición protocolada"}, {"sequence": 47, "date": "2026-10-22", "type": "despacho", "description": "Intimación"} ] } }
- Evento para calendario:
{ "event_type": "calendar.event.requested", "event_id": "pj_cal_12f0_v1", "occurred_at": "2026-10-22T13:45:00Z", "source_id": "pj_dead_4c20", "process_key": "0001234-56.2026.8.26.0100", "calendar_event": { "title": "Vencimiento: presentar manifestación", "start": "2026-11-06T09:00:00-03:00", "end": "2026-11-06T09:30:00-03:00", "timezone": "America/Sao_Paulo", "description": "Proceso 0001234-56.2026.8.26.0100. Confirmar criterio del tribunal antes de actuar.", "reminders": ["P14D", "P3D", "P1D"], "calendar_provider": "Google Calendar" } }
- Confirmación de entrega y cadena de custodia:
{ "event_type": "delivery.confirmed", "event_id": "pj_del_31ca_v1", "occurred_at": "2026-10-22T13:50:00Z", "source_id": "pub_8f31", "delivery": { "destination": "salesforce", "http_status": 201, "received_at": "2026-10-22T13:49:58Z", "external_record_id": "sf_case_00381", "correlation_id": "corr_20261022_8831", "attempt": 1 }, "custody": { "original_payload_hash": "hash-del-payload", "content_hash": "hash-del-contenido", "received_by": "webhook-integrator", "retention_policy": "definida-por-el-cliente" } }
Estos modelos pueden enviarse mediante un webhook HTTPS. Un patrón habitual es usar headers como Authorization: Bearer <token>, X-Event-Id: pj_pub_8f31_v1, X-Signature: <firma-hmac> y X-Correlation-Id: corr_20261022_8831. El receptor debe validar la firma, devolver una respuesta rápida y procesar el evento de forma asíncrona cuando la operación incluya documentos o varias reglas de negocio.
Cómo evitar duplicaciones y mantener la cadena de custodia
- ✓Usa una clave de idempotencia compuesta por pocket_case_id, publication_id, event_type y event_version. Si el mismo evento llega dos veces, el ERP o CRM debe devolver el registro existente en lugar de crear otro.
- ✓Conserva dos identificadores diferentes: la identidad del proceso y la identidad del contenido. El número CNJ vincula el expediente, mientras que el hash de la carátula, de la publicación o del documento ayuda a detectar cambios y archivos repetidos.
- ✓No uses el texto completo como clave única. Una corrección de formato, un espacio adicional o la incorporación de un documento puede cambiar el contenido sin representar una nueva publicación jurídica.
- ✓Implementa una tabla de recepción con event_id, source_id, fecha de llegada, estado, cantidad de intentos, respuesta del destino y correlation_id. Esta tabla permite reintentar fallas sin duplicar el trabajo ya confirmado.
- ✓Mantén el payload original separado de los campos enriquecidos. El contenido capturado debe permanecer intacto, mientras que el resumen de una IA, la extracción de plazo y la clasificación pueden tener nuevas versiones.
- ✓Registra la secuencia temporal completa: fecha de disponibilidad, fecha de publicación, fecha de captura, fecha de enriquecimiento y fecha de entrega. No sustituyas una fecha por otra, porque cada una responde a una pregunta distinta.
- ✓Protege datos personales y controla el acceso por función. El principio de seguridad y las obligaciones relacionadas con datos personales deben evaluarse conforme a la Ley General de Protección de Datos de Brasil, Ley 13.709.
- ✓Define qué ocurre cuando falta un dato crítico. Un evento sin número CNJ puede ir a una cola de revisión, pero no debería crear automáticamente un proceso que después tendrá que ser corregido en varios sistemas.
Cómo encaja el monitoreo del Pocket Jurídico en esta arquitectura
El monitoreo de publicaciones funciona mejor cuando entrega contexto suficiente para que el ERP o CRM no sea obligado a reconstruir el proceso. El Pocket Jurídico monitorea más de 490 diarios y tribunales y, ante una nueva publicación, identifica y valida el proceso, captura carátula, historial, movimentaciones y documentos para formar una visión más completa.
Ese contexto puede llegar al sistema interno como un conjunto de eventos relacionados. La nueva publicación crea o actualiza el expediente, el plazo extraído alimenta una tarea, el documento se almacena como evidencia y un comentario mantiene la decisión dentro del proceso. Así se evita repartir información entre correos, planillas y conversaciones aisladas.
Una ventaja operativa es recibir publicaciones antes de la fecha de publicación cuando la fuente lo permite. Esto da más tiempo para validar el contenido y revisar la fecha límite, pero no elimina la responsabilidad de confirmar la regla procesal aplicable. La extracción por IA debe asistir al análisis, nunca sustituir la revisión profesional.
El modelo también sirve para departamentos jurídicos que ya utilizan otro software. La API puede enviar solamente los eventos necesarios, mientras que el Pocket Jurídico conserva la experiencia de monitoreo, organización del feed, comentarios y consulta centralizada de procesos.
Para una operación con varios estudios tercerizados, el campo responsable puede incluir oficina, abogado, equipo y centro de costo. El ERP o CRM puede usar estos valores para enrutar tareas, mientras el jurídico conserva una vista consolidada del contencioso de la empresa.
Cómo sincronizar plazos judiciales con Google Calendar y Outlook
Un plazo judicial no debe convertirse directamente en una reunión genérica. El evento de calendario necesita indicar si se trata de una fecha límite, una revisión interna, una audiencia o un recordatorio de preparación. La descripción debe incluir el número CNJ, el origen, el responsable y un enlace seguro al registro interno.
Para Google Calendar y Outlook, usa la zona horaria America/Sao_Paulo cuando corresponda y conserva el timestamp en UTC para la trazabilidad técnica. Si el proceso involucra otra jurisdicción o una regla especial, registra también el calendario utilizado para calcular los días hábiles.
Crea varios recordatorios solo cuando tengan una finalidad clara. Por ejemplo, un aviso 14 días antes puede iniciar la preparación, uno 3 días antes puede solicitar la revisión y uno 1 día antes puede confirmar el protocolo. Cada aviso debe apuntar al mismo deadline_id para impedir eventos duplicados.
Cuando una publicación actualiza el plazo, el integrador debe modificar el evento existente usando su identificador externo. Crear un segundo evento sin cancelar el anterior es una de las formas más comunes de generar confusión y falsas urgencias.
El calendario es una capa de ejecución, no la fuente principal. El registro jurídico debe conservar el texto original, la fundamentación de la fecha, la versión del análisis y la confirmación del responsable. Así, el equipo puede explicar por qué una tarea fue creada o alterada.
Errores frecuentes y lista de validación antes de publicar
- 1
No mezcles fecha de publicación con fecha de disponibilidad
Son hitos diferentes y pueden afectar el conteo del plazo. Envía ambos campos y deja que la regla procesal determine cuál inicia el cálculo.
- 2
No sobrescribas el texto original con un resumen
Un resumen facilita la lectura, pero no reemplaza la evidencia. Guarda la versión original, su hash y el modelo o usuario que produjo el enriquecimiento.
- 3
No identifiques el proceso solo por nombre de la parte
Una misma empresa puede aparecer en miles de expedientes. Prioriza el número CNJ y los identificadores internos, usando las partes como información complementaria.
- 4
No confíes únicamente en una respuesta HTTP
Un código 200 indica que el receptor aceptó la solicitud, pero no necesariamente que todas las reglas terminaron. Devuelve un external_record_id y un estado de procesamiento.
- 5
Valida el payload contra un esquema
Un esquema JSON ayuda a detectar tipos incorrectos, campos obligatorios ausentes y estructuras inválidas antes de llegar a Salesforce, TOTVS o al calendario.
- 6
Prueba duplicados deliberadamente
Envía el mismo event_id dos o tres veces y confirma que el destino conserve un solo registro. Repite la prueba después de una actualización de versión.
- 7
Crea una cola para revisión humana
Procesos sin identificador, plazos ambiguos, documentos ilegibles y conflictos entre fuentes deben quedar pendientes. Es preferible una excepción visible que una automatización silenciosamente incorrecta.
Preguntas Frecuentes
¿Qué campos mínimos debo enviar del monitoreo de publicaciones a un ERP o CRM?▼
Como mínimo, envía event_id, event_type, occurred_at, numero_cnj, tribunal, instancia, identificador de la publicación, fecha de disponibilidad, fecha de publicación y contenido original o una referencia segura a él. También conviene incluir source_id, correlation_id y una clave externa del registro de destino. Si existe un plazo, agrega fecha inicial, fecha límite, cantidad de días, calendario utilizado y estado de revisión.
¿Cómo evitar la duplicación de procesos al sincronizar publicaciones con Salesforce o TOTVS?▼
Usa una clave externa estable para hacer upsert, en lugar de crear registros en cada recepción. La clave debe identificar el proceso y no solamente el nombre de las partes, por ejemplo el pocket_case_id combinado con el número CNJ normalizado. Para las publicaciones, utiliza además publication_id, event_type y event_version, y guarda una tabla de idempotencia que registre los eventos ya procesados.
¿Cómo representar en JSON los plazos extraídos por una IA?▼
Representa el plazo como un objeto independiente con descripción, fecha de inicio, fecha de vencimiento, días hábiles, calendario, estado y responsable. Guarda en otro objeto el resumen, el proveedor o versión del modelo, la confianza y la indicación de revisión humana. La fecha extraída debe poder rastrearse hasta el texto original y su hash, porque una interpretación automática no tiene el mismo valor que la fuente judicial.
¿Cómo enviar varios documentos relacionados con una misma publicación?▼
Puedes usar un arreglo documents cuando el evento sea pequeño, o eventos document.attached separados cuando los archivos sean grandes o lleguen en momentos diferentes. Cada documento debe tener nombre, tipo MIME, tamaño, hash, URL segura y relación con el proceso y la publicación. No conviene insertar archivos binarios directamente en el JSON del webhook, porque aumenta el tamaño, complica los reintentos y puede superar los límites del sistema receptor.
¿Qué formato de fecha y zona horaria debe usarse en un payload judicial?▼
Usa ISO 8601 y conserva timestamps técnicos en UTC, por ejemplo 2026-10-22T14:30:00Z. Para la operación del equipo, incluye también la zona horaria y la fecha local que corresponda al calendario jurídico brasileño. Nunca sustituyas fecha de captura, fecha de disponibilidad y fecha de publicación por un único campo llamado fecha.
¿Cómo demostrar la cadena de custodia de una publicación integrada?▼
Conserva el payload original, el contenido original, sus hashes, el identificador de origen, la hora de recepción, los intentos de entrega y el identificador de correlación. Registra además quién o qué servicio produjo cada enriquecimiento, como un resumen o una extracción de plazo. La cadena de custodia no depende solamente del hash, sino de la combinación entre integridad, control de acceso, registro temporal y trazabilidad de las transformaciones.
¿Se puede enviar un plazo judicial directamente a Google Calendar o Outlook?▼
Sí, pero el calendario debe recibir un evento con título, fecha, zona horaria, descripción, recordatorios y un identificador del plazo. Mantén el deadline_id para actualizar el evento si la publicación cambia la fecha, en lugar de crear uno nuevo. El calendario debe ser una representación operativa del plazo, mientras que el sistema jurídico conserva la fuente, el cálculo y el historial.
¿La integración con un ERP o CRM reemplaza la revisión del abogado?▼
No. La automatización reduce la captura manual, organiza el volumen y puede sugerir resúmenes o fechas, pero la validación profesional sigue siendo necesaria en los casos ambiguos o sensibles. El payload debe indicar requires_human_review cuando la extracción tenga incertidumbre, falte información o exista una regla procesal que requiera análisis.