Crea plantillas de consentimiento

Las plantillas de consentimiento (consent templates) te permiten estandarizar las solicitudes de consentimiento en todos tus flujos digitales. En la plantilla defines el contenido y las propiedades de la solicitud de consentimiento que se presenta a tus usuarios. Puedes crear tantas plantillas como necesites, cada una con sus propias características y usarlas en diferentes flujos de tu aplicación.

Crea tus plantillas de consentimiento usando el dashboard de administración o usando la API de Soyio con el endpoint POST /api/v1/consent_templates.

Configuración de la plantilla

Define el título

Define un título corto y descriptivo que será lo primero que vea el usuario.

{
  "title": "Quiero recibir ofertas y promociones"
}

Mejores prácticas:

Usa lenguaje claro y directo
Evita términos técnicos o legales complejos
Mantén el título conciso (máximo 50 caracteres)

Define la cláusula legal

Redacta el texto legal del consentimiento. Te recomendamos mantenerlo breve, que sea claro y que comience con acciones afirmativas.

{
  "text": "Acepto el tratamiento de mis datos personales para fines de marketing y promociones."
}

Mejores prácticas:

Comienza con verbos afirmativos: "Acepto", "Autorizo", "Estoy de acuerdo"
Usa lenguaje simple y comprensible
Evita ambigüedades o dobles negaciones

Usa tooltips para añadir aclaraciones

Añade aclaraciones o definiciones con tooltips inline para evitar textos muy largos. Encierra el término en dobles corchetes [[ ]] y su explicación en paréntesis ( ), sin espacios entre ambos:

[[término]](explicación)

{
  "text": "Acepto el tratamiento de mis datos para [[fines de marketing]](Esto incluye el envío de correos promocionales y publicidad personalizada)."
}

Soyio muestra el término con subrayado punteado. La explicación aparece al pasar el cursor o al tocar el término en móvil:

Acepto el tratamiento de mis datos para fines de marketing.

Reglas de la notación:

Abre el paréntesis inmediatamente después de ]]. Cualquier espacio o carácter intermedio rompe la notación.
La explicación termina en el primer ). Evita paréntesis dentro del texto del tooltip.
Escribe siempre una explicación. Con la explicación vacía, el resultado varía según la superficie.
El término no puede contener ]] ni anidar otro tooltip.
El término y la explicación se muestran como texto plano: **negrita**, *cursiva* y {{documento}} no se interpretan dentro de un tooltip.
Soyio recorta los espacios sobrantes al inicio y al final del término y de la explicación.
Si la notación queda incompleta o malformada, Soyio muestra el texto literal tal como lo escribiste.
Usa tantos tooltips como necesites en un mismo texto, tanto en párrafos como en ítems de lista.

Mejores prácticas:

Mantén la explicación en una o dos frases
Aclara términos técnicos o legales, no reemplaces la cláusula
No dejes contenido legal crítico solo dentro del tooltip: el usuario debe entender a qué consiente sin abrirlo

Si prefieres no escribir la notación a mano, usa el botón Insertar tooltip del editor de texto enriquecido del dashboard. Genera la misma notación por ti.

La regla es simple: Soyio interpreta la notación solo en el campo text de la plantilla y solo cuando Soyio renderiza el texto.

Superficie	Interpreta la notación
Consent embed (SDK web y móvil)	Sí
Centro de privacidad	Sí
Formularios de consentimiento (públicos y embebidos)	Sí
Previsualización de la plantilla en el dashboard	Sí
`title` de la plantilla	No, se muestra como texto plano
`duration_clause_text` y `duration_clause_tooltip`	No, se muestran como texto plano. La vigencia tiene su propio tooltip configurable
Tu propia interfaz sin SDK	No, debes procesar la notación en tu interfaz
Recibos PDF y correos generados por Soyio	No, el texto no se procesa

Si construyes tu propia interfaz de consentimiento con la API, revisa Manejo de texto formateado en las cláusulas para procesar la notación por tu cuenta.

La evidencia guarda el text de la plantilla tal como lo escribiste, con la notación incluida. Considéralo si procesas la evidencia con tus propias herramientas.

Referencia documentos de privacidad

Enlaza tus políticas de privacidad, términos y condiciones u otros documentos relevantes usando dobles llaves {{ }}. Si necesitas referenciar una versión específica del documento, puedes hacerlo agregando el número de la versión después de la llave.

Puedes definir el texto visible del enlace agregando | y el label que quieres mostrar. Si no defines un label, Soyio mostrará el nombre del documento configurado.

{
  "text": "He leído y acepto la {{politica-de-privacidad:1|política de privacidad}} de la empresa."
}

Formatos soportados:

{{politica-de-privacidad}}: usa la versión 1 y muestra el nombre del documento.
{{politica-de-privacidad:2}}: usa la versión 2 y muestra el nombre del documento.
{{politica-de-privacidad:2|política de privacidad}}: usa la versión 2 y muestra política de privacidad como texto del enlace.

Formato de texto enriquecido

Puedes dar formato al texto de tus plantillas utilizando una sintaxis similar a Markdown.

Negrita y Cursiva:

Para negrita, usa **texto**.
Para cursiva, usa *texto*.

Listas:

Para listas no ordenadas, comienza la línea con - , * o + .
Para listas ordenadas, comienza la línea con un número seguido de un punto, como 1. .

Párrafos:

Separa los párrafos con una línea en blanco.

{
  "text": "Al aceptar, permites:\n\n- El envío de **promociones**.\n- El uso de cookies *esenciales*.\n\nConsulta nuestra política para más detalles."
}

Los documentos de privacidad deben estar previamente configurados en la plataforma para poder referenciarlos. Revisa la sección Configuración de la empresa para más información.

Define categorías de datos y usos

Define explícitamente las categorías de datos para las cuales solicitas consentimiento seleccionando las opciones desde nuestra taxonomía. Para cada categoría de datos, puedes especificar uno o más usos de los datos. Puedes ver la lista completa de categorías de datos y usos en la sección de taxonomía.

Recomendaciones:

Sé lo más granular posible, es decir, usa subcategorías siempre que sea posible.
Analiza tus procesos internos para solicitar solo los datos necesarios. Esto te ayudará a cumplir con el principio de minimización de datos.
Escoge usos que representen tus procesos internos y que sean coherentes con la cláusula legal de la plantilla.
Usa una sola categoría principal de uso por plantilla y crea una plantilla por cada categoría que necesites. Además de ser un requisito de los componentes actuales, ayuda a cumplir con el principio de granularidad y especificidad.

Una sola categoría principal de uso por plantilla

Los componentes actuales de Soyio soportan una categoría principal de uso por plantilla. La categoría principal es el primer segmento del uso, antes del punto: en marketing.advertising es marketing. Combina varios subusos de la misma categoría principal si lo necesitas, pero no categorías distintas. Revisa las categorías disponibles en la taxonomía.

Si mezclas categorías principales:

El componente de captura de consentimiento no renderiza la solicitud y muestra un mensaje de plantilla multi-uso no soportada. Revisa los errores de integración frecuentes
El centro de privacidad y los formularios de consentimiento muestran solo la categoría predominante, así que los demás usos quedan invisibles para el usuario

El render antiguo, con un ícono y un label por cada uso, es legacy y los componentes actuales no lo soportan. No lo tomes como referencia.

La API tampoco te protege: acepta la plantilla y responde 201 aunque mezcles categorías. La única validación de cardinalidad es la de REDEC, así que ese 201 no garantiza que el componente renderice la plantilla.

Crea una plantilla por categoría principal, cada una con su propia cláusula legal y vigencia.

¿Te ayudamos?

Si tu empresa no tiene una definición específica en sus políticas, contáctanos para ayudarte a determinarlas adecuadamente. Profundiza en estos conceptos revisando nuestra documentación sobre la taxonomía.

Ejemplo
{
  "data_category": "user.contact.email",
  "data_uses": ["marketing.communications", "marketing.advertising"]
}

Ejemplo de usos que el componente no soporta
// ❌ Mezcla tres categorías principales: essential, marketing y third_party_sharing
{
  "data_category": "user.contact.email",
  "data_uses": ["essential", "marketing", "third_party_sharing"]
}

data_category se infiere automáticamente solo cuando key corresponde a una de estas llaves: name, last_name, date_of_birth, email, phone_number, gender, nationality, cl_carnet_rut, cl_carnet_doc_number, cl_carnet_expiration_date, cl_carnet_issue_date, national_id_front_photo o national_id_back_photo.

Para cualquier otra key (por ejemplo address), debes especificar data_category explícitamente. Si lo omites, la API responderá un error de validación.

Ejemplo con key no inferible
{
  "key": "address",
  "data_category": "user.contact.address",
  "data_uses": ["essential.service.delivery"]
}

Define la vigencia del consentimiento

Puedes establecer la vigencia del consentimiento de dos formas: Duración Fija o Duración Condicional.

Duración Fija (Por defecto)

Establece un período de duración específico usando el formato ISO 8601. Es la opción por defecto si no especificas duration_type.

Formato: P[n]Y[n]M[n]DT[n]H[n]M[n]S

Ejemplos:

P1Y = 1 año
P6M = 6 meses
P2Y3M = 2 años y 3 meses
P1Y6M3D = 1 año, 6 meses y 3 días

Duración Condicional

Establece una condición lógica para la vigencia del consentimiento. Esto es útil cuando la duración depende de eventos externos o estados legales.

Para usar este tipo de duración, debes configurar duration_type: "conditional" y especificar el tipo de cláusula en duration_clause_type.

Al crear o actualizar templates por API, considera estos campos:

duration_type: usa "conditional" para activar vigencia condicional.
duration_clause_type: define la cláusula condicional.
duration_clause_text: requerido cuando duration_clause_type es "custom".
duration_clause_tooltip: opcional; se muestra como tooltip junto a la duración para explicar su significado. Envíalo solo con duración condicional; con duración fija la API responderá un error 422. Queda registrado en cada versión del template, por lo que forma parte de la evidencia.
duration: úsalo cuando duration_type sea "fixed" (ISO 8601).
duration_basis: envíalo como null cuando duration_type sea "conditional". El valor por defecto calendar solo aplica a duración fija; si envías calendar o business_days junto con "conditional", la API responderá un error 422.

Opciones disponibles para duration_clause_type:

Valor	Descripción
`while_contractual_relationship`	Mientras dure la relación contractual.
`while_legal_obligation`	Mientras exista una obligación legal.
`until_purpose_fulfilled`	Hasta que se cumpla la finalidad.
`until_revoked`	Hasta que sea revocado por el usuario.
`custom`	Personalizado (requiere enviar el texto en `duration_clause_text`).

Ejemplo de configuración (JSON):

{
  "duration_type": "conditional",
  "duration_basis": null,
  "duration_clause_type": "while_contractual_relationship",
  "duration_clause_tooltip": "Mientras mantengas un contrato vigente con nosotros."
}

Ejemplo personalizado:

{
  "duration_type": "conditional",
  "duration_basis": null,
  "duration_clause_type": "custom",
  "duration_clause_text": "Hasta que el usuario cancele su suscripción."
}

Consideraciones:

Una vez expirado, cuando consultes el consentimiento, aparecerá como "no otorgado". Por lo tanto, no podrás continuar tratando los datos para esa finalidad.
Deberás solicitarlo nuevamente si necesitas seguir tratando los datos.
Considera el ciclo de vida de tu relación con el usuario.

Si usas duración condicional basada en eventos de negocio (por ejemplo, término de contrato u obligación legal cumplida), implementa la revocación desde backend usando Revocación de consentimiento (iniciada por la compañía).

La duración definida será mostrada al usuario en un formato legible (ej. "8 meses") en el widget de consentimiento.

Define el alcance del consentimiento

Por defecto, un template de solicitud de consentimiento se asocia a toda tu compañía. Para acotar su alcance, puedes asociarlo a uno o más productos o filiales usando el parámetro scopes.

scopes es un arreglo de objetos. Cada objeto representa un alcance específico y debe incluir:

scope_type: tipo de alcance. Valores permitidos: "product" o "branch".
scope_id: token público del producto o filial.
scope_version (opcional): versión específica del producto o filial. Si no lo envías, la API resuelve latest al momento de crear/actualizar y persiste esa versión en el template.

Ejemplo de template multi-alcance:

{
  "title": "Consentimiento para marketing",
  "scopes": [
    { "scope_type": "product", "scope_id": "prod_1B2M2Y8AsgTpgAmY7PhCfg" },
    { "scope_type": "branch", "scope_id": "branch_1B2M2Y8AsgTpgAmY7PhCfg" }
  ]
}

Compatibilidad hacia atrás

Los parámetros product_id y branch_id siguen siendo soportados por retrocompatibilidad, pero se recomienda migrar a scopes para aprovechar la funcionalidad multi-alcance.

Si envías scopes junto con product_id o branch_id, prevalece scopes.

Para habilitar la selección granular de alcance (donde el usuario puede elegir qué productos/filiales autorizar), revisa la sección de Personalización de Apariencia y Comportamiento.

Los productos y filiales deben estar previamente configurados en el perfil de tu compañía en la plataforma. Revisa la sección Configuración de la empresa para más información.

Ejemplos de plantillas

Plantilla de marketing

{
  "name": "Marketing Básico", // Nombre descriptivo de la plantilla para tu referencia
  "title": "Quiero recibir ofertas y promociones",
  "text": "Acepto el tratamiento de mis datos para fines de marketing como enviar correos promocionales y publicidad personalizada según la {{politica-de-privacidad:1|política de privacidad}}.",
  "duration": "P2Y",
  "data_requirements": [
    {
      "key": "user.contact.email",
      "data_uses": ["marketing.communications", "marketing.advertising", "marketing.advertising.profiling"]
    },
    {
      "key": "user.contact.phone_number",
      "data_uses": ["marketing.communications", "marketing.advertising", "marketing.advertising.profiling"]
    },
    {
      "key": "user.name",
      "data_uses": ["marketing.communications", "marketing.advertising", "marketing.advertising.profiling"]
    }
  ]
}

Plantilla de analytics

{
  "name": "Análisis y Mejora", // Nombre descriptivo de la plantilla para tu referencia
  "title": "Quiero ayudar a mejorar el servicio",
  "text": "Autorizo el uso de mis datos y el uso de cookies para realizar [[análisis y mejoras]](Análisis de comportamiento y optimización del servicio) de la plataforma según la {{politica-de-privacidad:1|política de privacidad}}.",
  "duration": "P1Y",
  "data_requirements": [
    {
      "data_category": "user.device.cookie_id",
      "data_uses": ["analytics.reporting.ad_performance", "analytics.reporting.system.performance"]
    }
  ]
}

Plantilla para compartir datos con terceros

{
  "name": "Compartir con Terceros", // Nombre descriptivo de la plantilla para tu referencia
  "title": "Compartir información con socios comerciales",
  "text": "Acepto que mis datos sean compartidos con [[socios comerciales y empresas aliadas]](<Empresa 1>, <Empresa 2> y <Empresa 3>) para que me ofrezcan productos y servicios de interés a precios preferenciales.",
  "duration": "P1Y6M",
  "data_requirements": [
    {
      "data_category": "user.contact.phone_number",
      "data_uses": ["third_party_sharing"]
    },
    {
      "data_category": "user.contact.email",
      "data_uses": ["third_party_sharing"]
    },
    {
      "data_category": "user.name",
      "data_uses": ["third_party_sharing"]
    }
  ]
}

Versionado de plantillas y evidencia

Soyio genera trazabilidad con fines de auditoría y cumplimiento regulatorio. Por lo tanto, cada vez que modificas una plantilla de consentimiento, se crea una nueva versión de la plantilla que mantiene el mismo ID, pero con un número de versión diferente.

Cada vez que se levanta un flujo de consentimiento, se usa la última versión disponible para la plantilla de consentimiento especificada en la SDK.

Consulta el historial de versiones de una plantilla usando el endpoint GET /api/v1/consent_templates/{id}/versions.

Es importante considerar esto, ya que la evidencia de los consentimientos se asocia a la versión exacta de la plantilla que el usuario aceptó. Si el cambio de la plantilla afecta a los datos o usos que se solicitan, a su vigencia o al alcance del consentimiento (por ejemplo, si se asocia a otro producto o filial), el consentimiento asociado a esa plantilla puede aparecer como non_compliant o seguir en complies aunque la última acción explícita de consentimiento haya quedado registrada en una versión anterior.

Próximos pasos

Inicio rápido - Implementa consentimiento paso a paso
Captura de consentimiento - Captura el consentimiento de un usuario
Consulta de consentimiento - Consulta los consentimientos de un usuario
Gestión de consentimientos - Gestiona y revoca el consentimiento de un usuario
Taxonomía - Entiende las categorías de datos disponibles

Configuración de la plantilla​

Define el título​

Define la cláusula legal​

Usa tooltips para añadir aclaraciones​

Dónde se muestra el tooltip​

Referencia documentos de privacidad​

Formato de texto enriquecido​

Define categorías de datos y usos​

Define la vigencia del consentimiento​

Duración Fija (Por defecto)​

Duración Condicional​

Define el alcance del consentimiento​

Ejemplos de plantillas​

Plantilla de marketing​

Plantilla de analytics​

Plantilla para compartir datos con terceros​

Versionado de plantillas y evidencia​

Próximos pasos​

Configuración de la plantilla

Define el título

Define la cláusula legal

Usa tooltips para añadir aclaraciones

Dónde se muestra el tooltip

Referencia documentos de privacidad

Formato de texto enriquecido

Define categorías de datos y usos

Define la vigencia del consentimiento

Duración Fija (Por defecto)

Duración Condicional

Define el alcance del consentimiento

Ejemplos de plantillas

Plantilla de marketing

Plantilla de analytics

Plantilla para compartir datos con terceros

Versionado de plantillas y evidencia

Próximos pasos