API de iDataSeguro — 103 endpoints documentados

Consulta al asistente consultor-normativo (Q&A con citas de la Ley 21.719/19.628). Cada consulta queda registrada en el log de auditoría (M9).

Sugiere categorías de datos personales que probablemente trata un sistema del inventario (M4), a partir de su nombre/descripción. Solo lectura: no crea categoria_dato — el DPO decide qué llevar al RAT.

Solicita el envío de un correo para restablecer la contraseña. Responde { ok: true } siempre, exista o no el email (anti-enumeración).

Solicitud de demo/más información desde la landing pública

Listar el RAT del tenant autenticado (dueno_proceso sin rol exento: solo actividades de sus áreas asignadas, matriz §3.2)

Crear una ActividadTratamiento en estado borrador

Obtener una ActividadTratamiento por id (dueno_proceso sin rol exento: 403 si la actividad no es de sus áreas asignadas, matriz §3.2)

Actualizar una actividad en estado editable (borrador/en_revision). Vigente → 400 (usar /proponer-version); histórico → 400 (inmutable); transiciones a vigente/historico → 400 (usar /aprobar o /baja)

Aprobar una actividad en revisión → vigente (HU-M1-01, F2 §5.3, solo DPO). Revalida las 4 reglas de integridad en el servidor y aplica segregación de funciones (§5.3.5)

Dar de baja una actividad vigente → historico registrando motivo y fecha de cese (HU-M1-05, F4 §5.5, solo DPO)

Informe de evidencia de accountability de la actividad lógica de :id (HU-M1-16, auditor/DPO): todas las versiones, todas las aprobaciones del DPO en LogAuditoria (incluidas las excepciones de segregación), fecha de generación y versión de la fuente normativa (art. 14). La sección de documentos publicados asociados se omite: el modelo aún no relaciona documento↔actividad

Proponer nueva versión de una actividad vigente (HU-M1-08, F3 §5.4): clona la vigente como borrador con version+1 SIN tocar el estado de la vigente (sigue vigente hasta que la nueva se apruebe). Body opcional con los mismos campos del PATCH para partir con cambios aplicados

Rechazar una actividad en revisión → borrador con observaciones obligatorias (HU-M1-01, §5.3.5, solo DPO)

Semáforo de las cuatro reglas de integridad de la actividad :id (HU-M1-07, §5.2 punto 4): cumple/errores por regla + agregado cumpleTodas. Lectura pura, sin gateo de rol (mismo alcance que GET /:id)

Vincular un sistema del catálogo a la actividad (M4 básico, N:M). Sin gateo de rol propio, pero el dueño de proceso restringido solo opera sobre actividades de sus áreas (matriz §3.2, mismo criterio que el PATCH)

Desvincular un sistema de la actividad (M4 básico, N:M). Misma restricción de área del dueño de proceso que el PATCH (matriz §3.2)

Vincular un tercero del catálogo a la actividad (M5, N:M — encargados del art. 15 bis y cesionarios del art. 15). Sin gateo de rol propio, pero el dueño de proceso restringido solo opera sobre actividades de sus áreas (matriz §3.2, mismo criterio que sistemas)

Desvincular un tercero de la actividad (M5, N:M). Misma restricción de área del dueño de proceso que el PATCH (matriz §3.2)

Crear una transferencia internacional de la actividad (arts. 27-28, 1:N propio). Sin gateo de rol propio, pero el dueño de proceso restringido solo opera sobre actividades de sus áreas (matriz §3.2). Rechaza (400) un mecanismo de hipótesis específica (art. 27 inciso 2°) marcado como habitual

Editar (parcial) una transferencia internacional de la actividad. Misma restricción de área que crearTransferencia

Eliminar una transferencia internacional de la actividad. Misma restricción de área que crearTransferencia

Listar todas las versiones (cualquier estado) de la actividad lógica a la que pertenece :id, ordenadas por versión ascendente (HU-M1-14)

Exportar el RAT vigente como evidencia (HU-M1-13): actividades vigentes con versión, fecha de revisión y aprobador, más fecha de exportación y versión de la fuente normativa. Solo DPO / administrador / auditor (matriz §3.2)

Panel de completitud del RAT (HU-M1-02, solo DPO): actividades vigentes con datos sensibles y evaluación de necesidad de EIPD sin resolver (art. 15 ter)

Listar el catálogo de áreas del tenant (HU-M1-12). Sin gateo de rol: lo necesita cualquier autenticado (p. ej. dueño de proceso al elegir su área)

Crear un área (HU-M1-12, solo administrador)

Renombrar un área (HU-M1-12, solo administrador)

Eliminar un área (HU-M1-12, solo administrador). Si está referenciada por usuario_rol o por actividad_tratamiento (FK area_id), la FK bloquea el borrado (400)

Obtener el plan comercial del tenant actual (arco/cumplimiento/full). Sin gateo de rol ni de plan

Listar el catálogo de sistemas del tenant (M4 básico, planes Cumplimiento/Full). Sin gateo de rol: lo necesita cualquier autenticado (p. ej. al vincular sistemas a una actividad del RAT)

Crear un sistema (M4 básico, solo administrador, planes Cumplimiento/Full)

Actualizar un sistema (M4 básico, solo administrador, planes Cumplimiento/Full)

Eliminar un sistema (M4 básico, solo administrador, planes Cumplimiento/Full). Si está vinculado a alguna actividad del RAT, la FK bloquea el borrado (400)

Listar el catálogo de terceros del tenant (M5: encargados y cesionarios, planes Cumplimiento/Full). Sin gateo de rol: lo necesita cualquier autenticado (p. ej. al vincular terceros a una actividad del RAT)

Crear un tercero (M5, solo administrador, planes Cumplimiento/Full): encargado de tratamiento (art. 15 bis) o cesionario (art. 15), con referencia y vigencia de su contrato

Actualizar un tercero (M5, solo administrador, planes Cumplimiento/Full)

Eliminar un tercero (M5, solo administrador, planes Cumplimiento/Full). Si está vinculado a alguna actividad del RAT, la FK bloquea el borrado (400)

Registrar el resultado de la due diligence de un tercero (M5, solo administrador, planes Cumplimiento/Full): estado + observaciones; la fecha la estampa el servidor. Criterio operativo de accountability, no plazo legal

Crear un usuario del tenant con su primer rol (HU-M1-10, solo administrador). El tenant sale del JWT del actor, nunca del body

Listar las asignaciones usuario→rol del tenant (HU-M1-10, solo administrador)

Asignar un rol adicional a un usuario existente del tenant (HU-M1-10, solo administrador). Con rol=dpo ES la designación formal de DPO de HU-M1-11 (queda trazada en LogAuditoria)

Crear un documento en estado generado (HU-M1-03). El contenido llega YA ESCRITO (humano o pegado a mano — la capa de agentes no existe todavía); los metadatos de generación (§6.3) son opcionales

Listar los documentos del tenant, filtrables por tipo y/o estado (HU-M1-03)

Obtener un documento por id

Aprobar un documento en revisión (HU-M1-03, CA-HU-M1-03.1, solo DPO): en_revision → aprobado, estampando el SHA-256 del contenido exacto aprobado (§6.3)

Cadena de aprobación de una política publicada (HU-M1-17, auditor/DPO): quién la generó (metadatos §6.3), quién la aprobó y cuándo, hash del contenido registrado al aprobar (con verificación contra el contenido actual, CA-HU-M1-17.1), y quién la publicó y cuándo. 400 si el documento no es una política o nunca se publicó

Enviar un documento generado a revisión del DPO (§6.2: generado → en_revision). Sin gateo de rol especial

Publicar un documento aprobado (HU-M1-04, §6.4, solo DPO): aprobado → publicado con fecha de publicación. Para tipo=politica_tratamiento asigna además versión correlativa y traspasa la marca de versión pública vigente (la anterior queda archivada pero consultable, CA-HU-M1-04.1)

Rechazar un documento en revisión con observaciones obligatorias (HU-M1-03, §6.5, solo DPO): en_revision → rechazado

Ficha del modelo de prevención (HU-M1-18): versión vigente (si existe), delegado designado, resumen de información tratada y procesos de riesgo derivados del RAT vigente, y documentos de protocolo/régimen sancionatorio interno asociados. Sin gateo de rol (lectura abierta al tenant, incl. auditor)

Crear una nueva versión del modelo de prevención en borrador (HU-M1-19, solo DPO)

Editar medios/facultades del delegado y/o mecanismo de reporte interno de un borrador (HU-M1-19, solo DPO). Rechaza si la versión ya no está en borrador

Aprobar un borrador (HU-M1-20, CA-HU-M1-20.1, solo DPO): borrador → vigente; si había una versión vigente previa, pasa a histórico

Historial completo de versiones del modelo de prevención (HU-M1-21, cualquier estado), solo lectura

Listar solicitudes de derechos ARCO+ del tenant, filtrables por estado y/o derecho. Cada fila incluye plazoVencido/diasRestantes computados al leer

Crear una solicitud de derecho ARCO+ en estado recibida. Estampa plazo_limite según el derecho: bloqueo → +2 días hábiles (art. 11 inciso sexto); resto → +30 días corridos (art. 11 inciso segundo, Ley 19.628 texto fijado por la Ley 21.719)

Obtener una solicitud de derecho por id

Pasar la solicitud a en_analisis. EXIGE identidad_verificada = true (registrada vía :id/verificar-identidad) — sin identidad acreditada la transición se rechaza con 400 (art. 11 inciso primero letra a))

Pasar la solicitud a en_verificacion_identidad (progreso de tramitación, libre entre estados no terminales)

Prorrogar el plazo de la solicitud: +30 días corridos desde el plazo_limite actual, por una sola vez (art. 11 inciso segundo). Segunda prórroga o solicitud en estado terminal → 400

Rechazar la solicitud (→ rechazada) con fundamento obligatorio (art. 11 inciso cuarto: la denegación debe fundarse)

Resolver la solicitud (→ resuelta) con resolución obligatoria y evidencias opcionales (respaldos de la respuesta, art. 11 inciso tercero)

Registrar la verificación de identidad del titular (art. 11 inciso primero letra a): marca identidad_verificada con método, verificador y fecha. Solo procede en estado en_verificacion_identidad (400 en cualquier otro). Si la identidad NO puede acreditarse, usar :id/rechazar con su fundamento — no hay estado nuevo

Alertas de vencimiento (dashboard): solicitudes abiertas cuyo plazo_limite cae dentro de los próximos N días (default 5) o ya venció, ordenadas por plazo ascendente. Solo consulta — no envía notificaciones

Crear una solicitud ARCO+ como titular anónimo (portal público). Valida que el tenant exista (404 si no), estampa plazo_limite según el derecho (mismo dominio/plazos-legales.ts que la creación interna) y devuelve el codigoSeguimiento — el dato que el titular DEBE guardar para consultar el estado después

Consultar el estado de una solicitud por código de seguimiento + identificación del titular. Coincidencia exacta de la tripleta (tenant, código, identificación); si cualquiera falla → el mismo 404 genérico (anti-enumeración). Devuelve solo la vista del titular: estado, plazos, prórroga y resolución si ya cerró

Listar el catálogo de propósitos de consentimiento del tenant, TODAS las versiones (las no-vigentes siguen consultables: prueban qué texto aceptó quien las consintió). Sin gateo de rol

Crear un propósito de consentimiento como versión 1 vigente (solo administrador). textoVersion es el texto EXACTO que se mostrará al titular (art. 12 inciso segundo, Ley 19.628 texto fijado por la Ley 21.719)

Actualizar un propósito (solo administrador). textoVersion DISTINTO del vigente → publica la versión N+1 y la anterior queda no-vigente pero consultable (mismo patrón de versionado que documentos); solo nombre/descripcion → update in situ sin versión nueva

Listar consentimientos de titulares del tenant (historial completo: otorgados y revocados), filtrable por identificación exacta del titular y/o propósito. Cada fila embebe la versión consentida del propósito — la prueba de qué texto aceptó (art. 12 inciso final)

Otorgar consentimiento a la versión VIGENTE de un propósito (portal público, art. 12 Ley 19.628 texto fijado por la Ley 21.719). Valida que el tenant y el propósito existan (404 si no). Si el titular ya tenía un consentimiento activo de una versión anterior, el nuevo lo reemplaza atómicamente (el anterior queda revocado, nunca borrado); si ya consintió exactamente la versión vigente, la operación es idempotente. Devuelve la evidencia (hash) como recibo

Centro de preferencias del titular: estado de consentimiento (otorgado/revocado/sin_respuesta) frente a TODOS los propósitos vigentes del tenant, identificándose por identificación + email (par EXACTO). Anti-enumeración: si el par no coincide, la respuesta es idéntica a la de un titular que nunca respondió — no revela si falla la identificación o el email

Revocar el consentimiento otorgado vigente del titular para un propósito (art. 12 inciso cuarto: en cualquier momento, sin expresión de causa, sin efectos retroactivos — la fila pasa a revocado, nunca se borra). Coincidencia por identificación + email exactos; sin coincidencia → 404 genérico (anti-enumeración)

Listar los propósitos de consentimiento VIGENTES del tenant (nombre, descripción y texto exacto de la versión vigente) para que el titular sepa qué puede consentir. Catálogo público por diseño: no expone datos personales. 404 si el tenant no existe

Listar las EIPD del tenant, filtrables por actividad (GET /m6/eipd?actividadId=). Sin los riesgos embebidos — la ficha completa es GET /m6/eipd/:id

Iniciar una EIPD en en_elaboracion para una actividad (la evaluación es PREVIA al inicio de las operaciones, art. 15 ter inciso primero). 400 si la actividad ya tiene una EIPD en elaboración; 403 si la actividad no es de las áreas del dueño de proceso (matriz §3.2)

Ficha completa de una EIPD: contenido mínimo (art. 15 ter inciso tercero) + riesgos, cada uno con nivelRiesgo computado al leer con la matriz 3×3 (metodología de producto)

Editar el contenido mínimo (descripción sistemática / necesidad y proporcionalidad) mientras la EIPD está en_elaboracion. 400 si ya está concluida

Concluir la EIPD con un resultado. 400 si no está en_elaboracion, sin riesgos, o sin el contenido mínimo completo. Al concluir marca requiere_eipd = true y eipd_concluida = true en la actividad vinculada (regla de integridad #2)

Agregar un riesgo (probabilidad × impacto + medida de mitigación). La respuesta incluye nivelRiesgo calculado con la matriz 3×3 de dominio. Solo con la EIPD en_elaboracion

Editar un riesgo. Con la EIPD en_elaboracion todo es editable; con la EIPD concluida SOLO estadoMitigacion (marcar la medida como implementada)

Listar incidentes del tenant, filtrables por estado. Cada fila incluye diasDesdeDeteccion/nivelUrgencia computados al leer (tiempo transcurrido — la ley no fija plazo numérico de notificación)

Registrar un incidente en estado abierto (ficha de la skill gestion-brechas; es el registro del art. 14 sexies inciso segundo). fechaDeteccion default ahora, nunca futura

Obtener la ficha de un incidente por id

Cerrar el incidente. 400 si la notificabilidad no está evaluada o si es notificable (Agencia/titulares) y la notificación respectiva no está registrada — no se cierra un incidente notificable sin notificar

Marcar el incidente como contenido (hito de contención; solo desde abierto)

Correr el árbol de notificabilidad (skill gestion-brechas) y guardar riesgo_titulares/notificable_agencia/notificable_titulares/fundamento_riesgo. Sensibles/NNA se leen de la ficha; el resto de factores viene en el body. Re-evaluable mientras no esté cerrado

Registrar la notificación a la Agencia (art. 14 sexies inciso primero): estampa fecha_notificacion_agencia. 400 si no es notificable, si aún no se evalúa o si ya se notificó

Registrar la comunicación a los titulares (art. 14 sexies inciso tercero): estampa fecha_notificacion_titulares. 400 si no es notificable, si aún no se evalúa o si ya se notificó

Incidentes urgentes (dashboard): NO cerrados, con gestión pendiente (evaluar notificabilidad, o notificar cuando correspondía) y detectados hace más de minDias días (default 2). Tiempo transcurrido, no cuenta regresiva. Solo consulta

Listar el catálogo de cursos del tenant, TODAS las versiones (las no-vigentes siguen consultables: prueban qué material recibió quien las completó). Sin gateo de rol

Crear un curso como versión 1 vigente (solo administrador). El contenido es el material texto/markdown que probará cada completación; rolesObjetivo vacío u omitido = dirigido a todos los roles

Actualizar un curso (solo administrador). contenido DISTINTO del vigente → publica la versión N+1 y la anterior queda no-vigente pero consultable (mismo patrón de versionado que M3/documentos); solo metadatos → update in situ sin versión nueva

Quién completó esta versión del curso y cuándo (supervisión del cumplimiento del equipo). Solo DPO / administrador / auditor — mismo criterio que los endpoints de supervisión de M9

Registrar que el ACTOR autenticado completó esta versión del curso (self-report, sin motor de evaluación). 400 si ya la completó — re-tomarlo tras una versión nueva es otro registro. Queda en LogAuditoria

Cursos vigentes DIRIGIDOS al actor (roles_objetivo incluye alguno de sus roles, o vacío = todos), con la marca de si ya completó cada versión. Sin gateo de rol: cada usuario ve sus propias asignaciones

Dashboard de madurez de cumplimiento del tenant (M9): conteos por estado de RAT/solicitudes/documentos, usuarios sin rol y score de madurez explicado componente a componente. Solo DPO / administrador / auditor (matriz §3.2, mismo criterio que exportar/informe-evidencia)

GAP automatizado de cumplimiento (M9): brechas concretas y accionables con entidad afectada, descripción y fundamento (legal u operativo, siempre declarado). Solo DPO / administrador / auditor (matriz §3.2)

Consultar el log de auditoría del tenant, filtrando por entidad, usuario, acción y rango de fechas (HU-M1-15)

Crear una API key de integración (solo administrador). La respuesta incluye la key en texto plano UNA SOLA VEZ — no es recuperable después (se persiste solo su hash SHA-256 + prefijo visible)

Listar las API keys del tenant (solo administrador): nombre, prefijo visible, último uso y estado — nunca el hash ni la key completa

Revocar una API key (solo administrador): baja lógica (activa=false), inmediata para las requests externas (401 desde ese momento). Idempotente; nunca DELETE — la fila revocada es evidencia

Registrar o actualizar un sistema del inventario (M4) desde un sistema externo. Upsert POR NOMBRE dentro del tenant de la API key: si el nombre ya existe se actualiza la descripción, si no se crea. Requiere header X-Api-Key; 401 si la key no existe o está revocada