Configuración de solicitudes de derechos

Configuración de solicitudes de derechos

Personaliza el comportamiento del módulo de ejercicio de derechos para adaptarlo a los procesos y requisitos de tu organización. Configura aspectos como las categorías de datos del formulario, el tiempo límite de validación, los campos de contacto requeridos, las restricciones de solicitudes y el método de validación de identidad.

Algunas opciones se declaran al inicializar el Privacy Center. Las configuraciones backend se gestionan a través del objeto data_subject_request en la configuración de tu compañía.

Formulario DSR en el Privacy Center

Estas opciones se declaran en la inicialización del Privacy Center cuando habilitas solicitudes de ejercicio de derechos. Para textos y configuración común del contenedor, revisa Contenido y configuración común del Privacy Center.

Categorías de datos configurables en solicitudes DSR

Controla qué categorías de datos del usuario se muestran en las listas desplegables de solicitudes ARSOP.

• requestableDataCategories: array opcional de objetos con forma { value, label?, description? }.
  • value: debe ser una clave canónica de la taxonomía user, por ejemplo user.contact.email, user.name.first o user.labor_activity.salary.
  • label: texto visible opcional de la opción.
  • description: texto de ayuda opcional de la opción.
• Si no defines requestableDataCategories, el Privacy Center mantiene la lista agrupada por defecto.
• Si la defines, el Privacy Center usa exactamente el orden entregado en la configuración.
• Valores fuera de la taxonomía user se ignoran.
• Si una categoría configurada no tiene label o description, el componente intenta usar las traducciones existentes y luego aplica un texto legible de respaldo.
• La configuración backend blacklistedDataCategories sigue aplicando y puede ocultar categorías aunque estén configuradas en el widget.

Valores disponibles

Para revisar todos los valores posibles de la taxonomía, consulta la guía de Taxonomías de datos de Soyio. Para requestableDataCategories, usa únicamente claves de la rama user.

Configurar categorías solicitables

const privacyCenterOptions = {
  // ...
  enabledFeatures: ['DataSubjectRequest'],
  requestableDataCategories: [
    {
      value: 'user.contact.email',
      label: 'Correo principal',
      description: 'El correo que usas para esta cuenta.',
    },
    {
      value: 'user.name.first',
    },
    {
      value: 'user.labor_activity.salary',
    },
  ],
};

Ejemplos por tipo de solicitud

Puedes ajustar los ejemplos que ve el usuario en el formulario DSR con content.rightExamples.

Personalizar ejemplos de derechos

const privacyCenterOptions = {
  // ...
  enabledFeatures: ['DataSubjectRequest'],
  content: {
    rightExamples: {
      access: 'Ejemplo: Quiero conocer qué datos tienen sobre mí.',
      rectification: 'Ejemplo: Quiero corregir mi dirección registrada.',
      suppression: 'Ejemplo: Quiero eliminar datos que ya no son necesarios.',
      redec_update: 'Ejemplo: Quiero actualizar la información de mi deuda.',
    },
  },
};

Las claves soportadas son access, opposition, rectification, suppression, portability, redec_update, redec_rectification, redec_complementation y redec_cancellation. Para configurar solicitudes REDEC, revisa Solicitudes de ejercicio de derecho REDEC.

Tipos de solicitud habilitados

Define qué tipos de solicitud aparecen en el formulario dentro del grupo de derechos activo.

• enabledKinds: array opcional de tipos de solicitud. Valores soportados: "access", "opposition", "rectification", "suppression", "portability", "redec_update", "redec_rectification", "redec_complementation", "redec_cancellation".
• Aplica solo los tipos que pertenecen al grupo activo — los tipos REDEC se ignoran cuando el grupo activo es arsop, y viceversa.
• Muestra todos los tipos del grupo activo cuando enabledKinds está vacío o no contiene valores válidos.

Mostrar solo acceso y oposición

const privacyCenterOptions = {
  // ...
  enabledFeatures: ['DataSubjectRequest'],
  enabledRights: ['arsop'],
  enabledKinds: ['access', 'opposition'],
};

Archivo de respaldo obligatorio por categoría en rectificación

En solicitudes de rectificación, los usuarios pueden adjuntar un archivo de evidencia (cédula, contrato, comprobante) por cada dato que piden rectificar. El archivo es opcional por defecto.

Usa rectificationFileRequiredCategories para declarar qué categorías exigen un archivo de respaldo. El caso típico es cambio de nombre o apellido, donde se necesita un documento de identidad.

Exigir archivo para cambios de identificación

const privacyCenterOptions = {
  // ...
  enabledFeatures: ['DataSubjectRequests'],
  rectificationFileRequiredCategories: [
    'user.identification.names',
    'user.identification.last_names',
  ],
};

Comportamiento en el formulario:

• Si el usuario elige una categoría incluida en la lista, el campo de archivo se vuelve obligatorio y no puede continuar sin adjuntarlo.
• Si la categoría no está en la lista (por ejemplo user.contact.phone o user.contact.email), el archivo sigue opcional como hoy.
• Solo aplica al tipo rectification. En opposition, suppression y redec_* el archivo permanece opcional sin importar la categoría.

Las claves de categoría son las mismas que usas en requestableDataCategories. Revisa la guía de Taxonomías de datos de Soyio para conocer la lista completa.

Tiempo límite de validación

Define un período de tiempo durante el cual el usuario debe validar su identidad después de crear una solicitud. Si el usuario no completa la validación dentro de este período, la solicitud expirará y deberá crear una nueva.

Cuándo usar un tiempo límite

Configura un tiempo límite cuando:

• Seguridad reforzada: Quieres asegurar que las solicitudes se validen en un período razonable para prevenir intentos fraudulentos.
• Gestión de recursos: Necesitas evitar acumulación de solicitudes pendientes sin validar.
• Requisitos legales: Tu organización tiene políticas específicas sobre el tiempo de validación de solicitudes.

Configurar el tiempo límite

Usa el campo validation_timeout_period en la configuración de tu compañía. El valor debe estar en formato ISO 8601 duration.

cURL

Configurar timeout de 24 horas

curl -X PATCH https://api.soyio.com/v1/config \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data_subject_request": {
      "validation_timeout_period": "P1D"
    }
  }'

JavaScript

Configurar timeout de 72 horas

const response = await fetch('https://api.soyio.com/v1/config', {
  method: 'PATCH',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    data_subject_request: {
      validation_timeout_period: 'P3D' // 3 días
    }
  })
});

const config = await response.json();
console.log('Configuración actualizada:', config);

Ejemplos de períodos

Período deseado	Valor ISO 8601
6 horas	P6H
24 horas	P1D
3 días	P3D
7 días	P7D
Sin expiración	null

Importante

El período total debe ser mayor a 0. Si estableces null, las solicitudes nunca expirarán y el usuario podrá validar su identidad en cualquier momento.

Campos de contacto

Personaliza qué campos de información de contacto se solicitan al usuario cuando crea una solicitud de ejercicio de derechos. Puedes controlar la visibilidad y obligatoriedad de los campos names, last_names y phone.

Campos siempre requeridos

Los siguientes campos siempre son obligatorios y no se pueden configurar:

• nin (RUT o número de identificación nacional): Necesario para identificar al titular de datos.
• email: Usado para enviar confirmaciones y notificaciones sobre la solicitud.

Campos configurables

Puedes configurar estos campos opcionales:

• names: Nombres del usuario
• last_names: Apellidos del usuario
• phone: Número de teléfono del usuario

Para cada campo configurable, puedes definir:

• visible: Si el campo se muestra en el formulario (true) o se oculta (false)
• required: Si el campo es obligatorio cuando es visible (true) o es opcional (false)

Importante

Un campo no puede ser obligatorio (required: true) si no es visible (visible: false). Primero debe ser visible para poder marcarse como requerido.

Configurar campos de contacto

Usa el campo contact_field_configs en la configuración de tu compañía:

cURL

Configurar campos de contacto

curl -X PATCH https://api.soyio.com/v1/config \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data_subject_request": {
      "contact_field_configs": [
        {
          "field_name": "names",
          "visible": true,
          "required": true
        },
        {
          "field_name": "last_names",
          "visible": true,
          "required": true
        },
        {
          "field_name": "phone",
          "visible": true,
          "required": false
        }
      ]
    }
  }'

JavaScript

Configurar campos de contacto

const response = await fetch('https://api.soyio.com/v1/config', {
  method: 'PATCH',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    data_subject_request: {
      contact_field_configs: [
        {
          field_name: 'names',
          visible: true,
          required: true
        },
        {
          field_name: 'last_names',
          visible: true,
          required: false // Opcional
        },
        {
          field_name: 'phone',
          visible: true,
          required: true // Requerido para contacto
        }
      ]
    }
  })
});

const config = await response.json();
console.log('Configuración actualizada:', config);

Casos de uso comunes

Solicitar solo información básica

Si solo necesitas nombres y email además del RUT:

{
  "contact_field_configs": [
    {
      "field_name": "names",
      "visible": true,
      "required": true
    },
    {
      "field_name": "last_names",
      "visible": false,
      "required": false
    },
    {
      "field_name": "phone",
      "visible": false,
      "required": false
    }
  ]
}

Requerir teléfono para notificaciones urgentes

Si necesitas contactar al usuario por teléfono:

{
  "contact_field_configs": [
    {
      "field_name": "names",
      "visible": true,
      "required": true
    },
    {
      "field_name": "last_names",
      "visible": true,
      "required": true
    },
    {
      "field_name": "phone",
      "visible": true,
      "required": true
    }
  ]
}

Permitir información opcional completa

Si quieres dar flexibilidad al usuario:

{
  "contact_field_configs": [
    {
      "field_name": "names",
      "visible": true,
      "required": false
    },
    {
      "field_name": "last_names",
      "visible": true,
      "required": false
    },
    {
      "field_name": "phone",
      "visible": true,
      "required": false
    }
  ]
}

Limitaciones y alcance de solicitudes

Controla cómo los usuarios pueden crear solicitudes de ejercicio de derechos, incluyendo restricciones sobre cuántos campos pueden modificar en una sola solicitud y si deben asociar las solicitudes a sucursales específicas.

Solicitudes de un solo campo vs. múltiples campos

Determina si los usuarios pueden solicitar modificaciones (rectificación, supresión, oposición) de múltiples categorías de datos en una sola solicitud, o si deben crear una solicitud separada para cada categoría.

Cuándo permitir múltiples campos

Permite múltiples campos (allow_many_data_categories_mutations: true) cuando:

• Tu organización puede procesar cambios en múltiples categorías de datos simultáneamente
• Quieres simplificar la experiencia del usuario reduciendo el número de solicitudes
• Tus sistemas de backend están preparados para gestionar actualizaciones masivas

Limita a un solo campo (allow_many_data_categories_mutations: false) cuando:

• Necesitas revisar y aprobar cada cambio individualmente
• Tus procesos internos requieren trazabilidad granular por categoría de dato
• Quieres evitar solicitudes complejas que puedan ser difíciles de gestionar

Configurar limitación de campos

cURL

Permitir solo un campo por solicitud

curl -X PATCH https://api.soyio.com/v1/config \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data_subject_request": {
      "allow_many_data_categories_mutations": false
    }
  }'

JavaScript

Permitir múltiples campos por solicitud

const response = await fetch('https://api.soyio.com/v1/config', {
  method: 'PATCH',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    data_subject_request: {
      allow_many_data_categories_mutations: true
    }
  })
});

Nota

Esta configuración solo afecta a solicitudes de tipo rectification, opposition y suppression. Las solicitudes de tipo access no se ven afectadas por esta configuración.

Alcance por ramas de la empresa

Define si las solicitudes deben estar obligatoriamente asociadas a una rama específica de tu organización. Esto es útil para organizaciones con múltiples filiales que necesitan segmentar la gestión de solicitudes por sucursal.

Sobre las ramas

Las ramas o branches representan divisiones o unidades de negocio específicas dentro de tu compañía. Puedes crear y gestionar ramas usando los endpoints de la API de branches. Los consentimientos están también asociados a estas ramas.

Cuándo requerir selección de sucursal

Requiere que los usuarios seleccionen una sucursal cuando:

• Tu organización opera en múltiples ubicaciones físicas
• Cada sucursal gestiona sus propios datos de clientes de manera independiente
• Necesitas enrutar solicitudes al equipo responsable de cada ubicación
• Cumples con requisitos legales de privacidad regionales específicos

Configurar alcance por sucursales

cURL

Requerir selección de sucursal

curl -X PATCH https://api.soyio.com/v1/config \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data_subject_request": {
      "appliable_scopes": ["branch"]
    }
  }'

JavaScript

Solicitudes sin asociación a sucursal

const response = await fetch('https://api.soyio.com/v1/config', {
  method: 'PATCH',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    data_subject_request: {
      appliable_scopes: [] // Sin restricción de sucursal
    }
  })
});

Recomendación

Si tu organización tiene una estructura centralizada de gestión de datos, deja appliable_scopes como array vacío ([]) para permitir solicitudes de alcance general sin restricción de sucursal.

Validación con registro civil

Habilita la verificación gubernamental sin biometría para validar una solicitud DSR con el RUT y número de documento del titular. Este modo omite selfies, cámara y escaneo del documento. Es útil cuando prefieres una validación más simple o cuando tus usuarios no pueden completar la validación biométrica.

Diferencias entre modos de validación

Aspecto	Validación biométrica (tradicional)	Validación con registro civil
Captura de selfie	Requerida	No requerida
Verificación de vivacidad	Requerida	No requerida
Datos del documento	Opcional	Requerido (número de documento)
Validación contra registro gubernamental	No	Sí
Experiencia del usuario	Requiere cámara y buena iluminación	Solo requiere número de documento
Nivel de seguridad	Alto (biometría)	Medio (datos gubernamentales)

Cuándo usar validación con registro civil

Define con tu equipo legal/privacidad en qué casos se empleará este método, algunas sugerencias:

• Restricciones técnicas: Tus usuarios acceden desde dispositivos sin cámara o con cámaras de baja calidad
• Simplicidad preferida: Prefieres una experiencia más rápida sin captura biométrica
• Contexto de uso: Los usuarios acceden desde entornos con iluminación deficiente o restricciones de privacidad
• Volumen alto: Procesas muchas solicitudes y prefieres reducir fricción en el proceso
• Suficiencia legal: Tu organización determina que la validación gubernamental es suficiente para cumplir requisitos legales

Cuándo usar validación biométrica

Define con tu equipo legal/privacidad en qué casos se empleará este método, algunas sugerencias:

• Máxima seguridad: Necesitas el nivel más alto de verificación de identidad
• Prevención de fraude: Quieres reducir al mínimo intentos fraudulentos
• Requisitos legales: Tu industria o jurisdicción requiere validación biométrica
• Datos sensibles: Gestionas categorías especiales de datos que requieren mayor protección

Configurar validación con registro civil

Configura los tres checks de validación en data_subject_request. Para usar solo verificación gubernamental, desactiva liveness_check e id_scan_check, y activa government_check:

cURL

Habilitar validación con registro civil

curl -X PATCH https://api.soyio.com/v1/config \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "data_subject_request": {
      "liveness_check": false,
      "id_scan_check": false,
      "government_check": true
    }
  }'

JavaScript

Alternar modo de validación

// Habilitar validación con registro civil
const enableGovMode = await fetch('https://api.soyio.com/v1/config', {
  method: 'PATCH',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    data_subject_request: {
      liveness_check: false,
      id_scan_check: false,
      government_check: true
    }
  })
});

// Volver a validación biométrica tradicional
const disableGovMode = await fetch('https://api.soyio.com/v1/config', {
  method: 'PATCH',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    data_subject_request: {
      liveness_check: true,
      id_scan_check: true,
      government_check: false
    }
  })
});

Experiencia del usuario

Cuando configuras solo verificación gubernamental:

1. El usuario ingresa su solicitud en el formulario del Privacy Center
2. Proporciona su RUT y el número de documento de identidad (cédula de identidad)
3. Soyio valida los datos contra el Registro Civil
4. Si la validación es exitosa, la solicitud pasa a estado validating y luego a processing
5. No se solicitan selfies ni verificación de vivacidad

Si generas el sessionToken con config[cl_carnet_rut], Privacy Center prellena y bloquea el campo RUT. El usuario solo debe ingresar el número de documento.

Limitación geográfica

La validación contra el Registro Civil actualmente solo está disponible para Chile. Si tu organización opera en otros países, consulta con el equipo de Soyio sobre opciones de validación disponibles.

Impacto en solicitudes existentes

Los campos liveness_check, id_scan_check y government_check se aplican a nuevas solicitudes. Las solicitudes creadas antes de cambiar esta configuración mantienen el método de validación con el que fueron creadas.

Consultar configuración actual

Obtén la configuración actual de tu compañía para revisar todos los ajustes de DSR:

cURL

Obtener configuración actual

curl -X GET https://api.soyio.com/v1/config \
  -H "Authorization: Bearer YOUR_API_KEY"

JavaScript

Obtener configuración actual

const response = await fetch('https://api.soyio.com/v1/config', {
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY'
  }
});

const config = await response.json();
console.log('Configuración DSR:', config.data_subject_request);

Ejemplo de respuesta:

{
  "data_subject_request": {
    "validation_timeout_period": "P1D",
    "liveness_check": false,
    "id_scan_check": false,
    "government_check": true,
    "allow_many_data_categories_mutations": true,
    "appliable_scopes": [],
    "contact_field_configs": [
      {
        "field_name": "names",
        "visible": true,
        "required": true
      },
      {
        "field_name": "last_names",
        "visible": true,
        "required": true
      },
      {
        "field_name": "phone",
        "visible": true,
        "required": false
      }
    ]
  }
}

Siguientes pasos

• Configura el Privacy Center: Ajusta textos comunes del contenedor y revisa enlaces a las demás guías.
• Personalización de apariencia: Cambia colores, tipografía, iconos y reglas visuales compartidas.
• Gestiona consentimientos: Configura el módulo de consentimiento si lo habilitas junto con solicitudes de derechos.
• Recibe solicitudes de derecho: Integra el componente Privacy Center para empezar a recibir solicitudes.
• Validación de la identidad: Entiende cómo funciona el proceso de validación de identidad.
• Gestiona las solicitudes: Aprende a procesar y responder solicitudes.
• Referencia de API: Consulta la documentación completa de la API de configuración.