Guía: mostrar a un usuario su propio historial

Deja que una persona con sesión iniciada vea a qué dio su consentimiento y cuándo, llamando desde tu backend a los endpoints de historial del lado del servidor.

Una página de «Tus decisiones de privacidad» que lista a qué dio su consentimiento una persona, cuándo y cómo cambió de opinión genera confianza, y responde sin abrir un ticket a la petición de acceso más habitual. El historial ya está en la bóveda; solo tienes que leerlo y mostrarlo.

Los dos endpoints

Ambos requieren una clave secreta (sk_) —con el scope subjects:read, si has limitado los scopes de la clave— y {ref} es el identificador de la persona, por ejemplo external_id:u_9241 (codificado para URL). Leer nunca crea un sujeto: si no existe, devuelve 404.

Llámalo desde tu backend

curl -H "Authorization: Bearer $TC_SECRET_KEY" \
  "https://api.tripticonsent.tripticode.com/v1/subjects/external_id%3Au_9241/consent/history?purpose=marketing_email"

import { TripticonsentClient } from '@tripticonsent/sdk';

const tc = new TripticonsentClient({
  baseUrl: 'https://api.tripticonsent.tripticode.com',
  apiKey: process.env.TC_SECRET_KEY!, // sk_live_… — solo servidor
});

// p. ej. dentro de GET /api/mi-historial-de-privacidad, tras autenticar la petición
export async function myHistory(userId: string) {
  const subject = 'external_id:' + userId; // NUNCA lo tomes de la petición
  const [consent, prefs] = await Promise.all([
    tc.getConsentHistory(subject),
    tc.getPreferenceHistory(subject),
  ]);
  return { consent, prefs }; // …o quédate solo con los campos que muestra tu interfaz
}

Qué devuelve

Historial de consentimiento: { subjectId, count, legalBasis, records }. legalBasis asocia cada clave de propósito con su base legal. Cada registro trae:

• purposeKey, purposeVersion, state (GRANTED, DENIED, WITHDRAWN o EXPIRED, escrito por el sistema)
• collectedAt, expiresAt, channel, locale, pageUrl
• source: API (actuó la persona), IMPORT / MIGRATION (lo afirmaste tú) o CONSOLE (lo escribió el sistema, como una caducidad)
• metadata: lo que tú enviaste al escribir, devuelto tal cual
• proof: el hash de la cláusula exacta con la que se registró; supersedesId: el registro al que sustituyó

Historial de preferencias: { subjectId, count, records }, con fieldKey, value, templateVersion, collectedAt, source, channel, pageUrl, supersedesId y confirmationState en cada registro. Se incluyen las solicitudes de doble opt-in pendientes: confirmationState es PENDING hasta que la persona pulsa el enlace (después CONFIRMED, o EXPIRED / CANCELLED), así que fíltralas o etiquétalas si solo quieres mostrar decisiones confirmadas.

Qué no se devuelve

• Direcciones IP y user agents: permanecen en la bóveda y en la exportación de la solicitud de acceso. La proof del doble opt-in en el historial de preferencias se recorta a sus campos no personales (doubleOptIn, confirmationId, requestedAt, method).
• Datos de otras personas: un historial se limita a un sujeto (y sigue las fusiones hacia él).
• Nada más allá de las 500 filas más recientes por llamada; filtra por purpose o field en historiales largos.
• Ids de justificante: las filas del historial no los llevan. Guarda el receiptId que recibiste al registrar el consentimiento si quieres ofrecer una prueba descargable (GET /v1/receipts/{id}).