Middleware de Consentimientos

Empresas SB · Gerencia de Tecnología

Simulador de canal

Un canal de ejemplo que usa el middleware de consentimiento para decidir si muestra un formulario y para registrar lo que la persona elige. Las decisiones las toma este simulador, no el middleware. A la derecha de cada paso, el endpoint del middleware y las llamadas a OneTrust que hace el middleware detrás.

Lógica del canal: cómo integrar un canal de venta por API

El middleware informa estado y registra decisiones; la regla de cuándo pedir el consentimiento es del canal. Esta es la lógica recomendada, la misma que aplica este simulador. Los números coinciden con los pasos de la página; a la derecha, la función clave tal como la ejecuta.

0. Canal y encabezados

  • Token: el backend del canal lo pide a Gravitee (client_credentials) con el cliente de su empresa y canal. Nunca llega al navegador ni a la app.
  • Encabezados: X-Company-Id y X-Channel-Id iguales a los que autoriza el token, un X-Request-Id (UUID) por acto y X-Program-Id cuando aplique.

1. Sincronizar formularios

  • GET /collection-points con If-None-Match, al iniciar y cada 1 a 2 horas; con 304 nada cambió.
  • Cada formulario trae sus propósitos con id, nombre, texto y versión: con eso se arma el formulario, sin otra llamada.

2. Consultar a la persona

  • RUT: 12345678-5, sin puntos, con guion, DV en mayúscula, sin ceros a la izquierda; módulo 11 validado en el front. Solo en el cuerpo; nunca en la URL, en el almacenamiento del navegador ni en logs.
  • POST /subjects:check con los purposeIds del formulario elegido. CACHED por defecto; STRICT si la decisión no admite caché.

3. Decidir si se muestra el formulario

Mostrarlo si hay al menos un propósito del formulario no aceptado; si todos están aceptados, no mostrarlo. Siempre con la respuesta de la consulta, nunca antes.

  • Un opcional aceptado sin el T&C puede existir; si vale para el negocio lo define el holding.
  • Sin recaptura por versión por ahora.

4. Formulario de captura y registro

Las casillas salen del formulario (una por propósito) y su estado, del mapa de estados de la consulta:

Estado del propósitoCasilla
GRANTEDMarcada y bloqueada; no se reenvía
NOT_COLLECTED, UNKNOWN o ausenteEditable, sin marcar
WITHDRAWNEditable, sin marcar
Obligatorio no aceptadoEditable; no se guarda sin aceptarlo
  • POST /consents con collectionPointId y solo lo editable, cada uno GRANTED o WITHDRAWN.
  • interactionDate = el momento en que la persona confirmó; un X-Request-Id nuevo por acto, y en un reintento se reenvían los dos sin cambios.
  • Con 201, aplicar el nuevo estado en pantalla: el proveedor puede tardar segundos en reflejarlo. Cambiar un consentimiento ya dado es del centro de preferencias.

5. Recibo

  • GET /receipts/{receiptId} muestra la evidencia en el proveedor; uno recién emitido puede responder 404 unos segundos.

6. Centro de preferencias

  • POST /subjects:preference-center-link y abrir la URL en otra pestaña. Es de un solo uso: no guardarla ni loguearla.

Transversal · Respuestas y errores

RespuestaQué hace el canal
201 / 202Registrado / en camino (consultar el pendiente)
400Corregir según code e invalidParams
401 / 403Renovar el token o revisar encabezados
429Esperar Retry-After
retryable: trueReintentar luego, mismo X-Request-Id
502 PLATFORMNo reintentar; mostrar el traceId
  • Decidir por status y retryable; un code desconocido nunca rompe el canal.
  • Si meta.stale es true, el dato no es en tiempo real.

Ejecución

Sin ejecuciones todavía. Cada acción de la página aparece aquí. Detalle completo ↓

    0. Canal y encabezados

    Encabezados que el canal envía en cada llamada. El token no se ingresa: lo agrega el backend del canal y nunca llega a la página.

    1. Sincronizar formularios

    Una sola llamada: cada formulario trae sus propósitos (id, nombre y versión), que es todo lo que el canal necesita para consultar a una persona. Se refresca con ETag: si nada cambió, el middleware responde 304 sin consultar al proveedor.

    2. Consultar a la persona

    Respuestas del middleware

    Tal cual llegan: status, headers relevantes y cuerpo. Numeradas en orden de ejecución, la más reciente arriba; cada una indica el paso que la originó.