atrusDocs
Guía de integración›Derechos›El portal de derechos del titular

El portal de derechos del titular

El portal de derechos (/t/<token>) es la pieza donde una persona ejerce sus derechos probando que controla el dato sobre el que los ejerce, en vez de escribir quién es. Entra con su teléfono (código por SMS), su correo (código con tu marca) o su RUT (verificación facial con proveedor, hoy simulada y rotulada; siempre con vía sin cámara en sucursal). Con eso abre una sesión corta, acotada a ese dato en tu empresa, y ve lo asociado a él: sus autorizaciones, lo que tú declaras tener y sus solicitudes. Las solicitudes que abre llegan a Derechos ya acreditadas, por el canal portal_titular.

Sin cruces, por construcción. Un teléfono abre lo del teléfono; un RUT, lo del RUT. No hay una operación que vincule uno con otro: los números se reciclan y los teléfonos se comparten. «Sobre todos mis datos» exige la puerta del RUT (documento o biometría), como en la consola.

Declarar lo que tienes de un identificador

Lo que tu empresa sabe de un dato vive en tus sistemas, no en Datrus. Con PUT /data-subjects/summary dejas un resumen por identificador: categorías, una descripción, en qué sistemas y desde cuándo. La persona lo ve al entrar con ese dato, y si en Derechos › Ajustes enciendes «responder el acceso en el acto», una solicitud de acceso «sobre este dato» se responde sola con él y queda en el expediente como aprobada por el sistema.

curl -X PUT https://www.datrus.cl/api/v1/data-subjects/summary \
  -H "Authorization: Bearer dtr_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier": { "type": "phone", "value": "+56 9 1234 5678" },
    "summary": {
      "items": [
        { "category": "Datos de contacto", "description": "Número para avisos de despacho y campañas.", "systems": ["CRM", "Mensajería"], "since": "2025-03-12" },
        { "category": "Historial de compras", "description": "Pedidos asociados a este número en los últimos 24 meses.", "systems": ["Tienda"], "since": "2025-03-12" }
      ],
      "note": "Se actualiza cada noche desde nuestros sistemas."
    }
  }'

La respuesta trae la identifierHint enmascarada y la fecha. El identificador se normaliza, se convierte en huella y se descarta: el resumen se guarda contra la huella, nunca contra el valor. PUT reemplaza el resumen completo de ese identificador; POST /data-subjects/summary/lookup lo lee de vuelta; DELETE /data-subjects/summary lo retira. Los tres reciben el identificador en el cuerpo, nunca en la URL. Permiso: data-subjects:write (lectura con data-subjects:read), módulo Derechos.

Un buen ritmo es dejarlo por lotes desde tu CRM o tu ERP (una noche, un PUT por identificador) y volver a dejarlo cuando cambie. No hace falta borrarlo antes: el PUT es idempotente por identificador.

La respuesta, derecho por derecho

Cuando tu equipo resuelve un derecho (en la consola o con POST /data-subject-requests/{id}/processes/{processId}/resolve), puede escribir una response: lo que se le dice a la persona sobre ese derecho. Al cerrar la solicitud, Datrus manda al correo que la persona dejó un aviso con el enlace al portal —sin la respuesta adentro— y la persona la lee con su sesión, derecho por derecho, junto con el fundamento si algo se denegó. Si le entregas un archivo (el listado del acceso, la copia portable), súbelo a la evidencia con la etiqueta delivered_to_data_subject: es la única etiqueta que el portal muestra y deja descargar, y su contenido se retira a los 30 días del cierre.

La solicitud te devuelve responseSentTo (la pista del correo al que salió el aviso) y responseViewedAt (cuándo la persona abrió la respuesta en el portal). Son tu constancia de remisión y de recepción del art. 11.

El modo autenticado

Si la persona ya está dentro de tu app (tu login la verificó), no tiene sentido pedirle un código. POST /rights-portal/sessions abre su sesión del portal para ese identificador con el nivel que declaras, y te devuelve la URL de entrada; ábrela en su navegador. Tú respondes por ese nivel: queda registrado con proveedor api:<llave>, y las solicitudes que abra lo heredan en su expediente.

curl -X POST https://www.datrus.cl/api/v1/rights-portal/sessions \
  -H "Authorization: Bearer dtr_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "identifier": { "type": "rut", "value": "12.345.678-5" }, "verificationLevel": "id_document" }'

201 { "url": "https://www.datrus.cl/t/<portal>/entrar?s=<sesión>", "expiresAt": "2026-10-17T12:30:00.000Z" }
verificationLevelQué abre
identifier_control (por defecto)Todos los derechos sobre ese identificador. Equivale al código por SMS o correo.
id_documentLo anterior, y además acceso, rectificación, supresión y portabilidad sobre toda la persona.
biometricsTodo. Declara este nivel sólo si tu app verificó a la persona con biometría o equivalente.

Requiere el portal encendido (Derechos › Ajustes, o la pieza «Portal de derechos del titular» en En tu sitio); apagado, responde 409 conflict. Permiso: rights:write. La sesión dura lo que la empresa configuró (10 a 120 minutos) y la URL de entrada mueve el token de sesión a una cookie httpOnly acotada a /t/<token>, para que no quede en el historial.

Lo que llega a tu bandeja

Una solicitud abierta desde el portal es una data-subject-request como cualquier otra, con dos campos más que verás en la consola y en los webhooks: el alcance (identificador o persona) y la marca de prueba si entró por el enlace de prueba. Las de prueba no cuentan en cifras, avisos ni webhooks y se purgan desde Derechos › Ajustes.

Lo que viene

Código por WhatsApp (cuando Meta habilite la plantilla de autenticación) y el proveedor real de verificación facial contra el Registro Civil, con el costo por verificación a cargo de la empresa. Ninguno cambia el contrato de esta página.