Customers

Un Customer identifica al sujeto operativo dentro del tenant autenticado. Resolverlo no crea consentimiento, grants ni autorización, y Consensa no ofrece búsqueda global cross-tenant.

Resolve explícito

Usa POST /v1/customers/resolve desde el backend cuando quieras obtener el customerId antes de iniciar Embed, Consent, Authorization o REDEC.

curl --request POST "$CONSENSA_API_URL/v1/customers/resolve" \
  --header "Authorization: Bearer $CONSENSA_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "userReference": "customer-4821",
    "identifiers": [{
      "system": "cl",
      "type": "rut",
      "value": "12.345.678-5"
    }]
  }'

La primera resolución puede responder 201 con created: true; una resolución compatible posterior responde 200 con el mismo customerId. La respuesta sólo informa tipo, sistema y estado de verificación de los identifiers: nunca hashes, ciphertext ni material interno de identidad.

userReference es una referencia estable del integrador dentro de su tenant. El mismo userReference e identifiers compatibles resuelven al mismo sujeto; una referencia o identidad incompatible falla cerrado. El campo público customerId siempre representa el sujeto tenant-scoped, no un Customer global.

Si incluyes identifiers[].verification, necesitas además consent:identity-assert y debes enviar provenance real (method, sourceReference, verifiedAt).

Resolve inline

POST /v1/embed/sessions y POST /v1/redec/consent-interactions aceptan userReference, customerId e identifiers según sus contratos y resuelven el Customer internamente. Es una alternativa válida cuando no necesitas el customerId por adelantado.

Backend → resolve explícito → customerId → Embed / Consent / Authorization / REDEC
Backend → Embed o REDEC con userReference/identifiers → resolve inline

Consultar sus consentimientos

Después de resolver o crear el Customer, usa GET /v1/customers/{customerId}/consents para consultar sus consentimientos generales y REDEC. La respuesta incluye referencias públicas, estado efectivo y fechas relevantes; no expone filas, identidad cifrada ni mecánicas internas.

Customer → resolve/create → consultar sus consentimientos

El customerId siempre se interpreta dentro del tenant de la API key. Un Customer de otro tenant no puede utilizarse para descubrir consentimientos ni identidad.

Para evaluar un consentimiento lógico antes de iniciar un flujo, usa GET /v1/customers/{customerId}/consent-compliance?templateKey=.... La respuesta distingue complies, partially_compliant y non_compliant, e informa la versión aceptada, la evaluada, requisitos pendientes y pendingVersionChanges temporales. Esta consulta no es authorization: otro template que comparta permisos no cuenta como aceptación, y una fuente expirada no satisface la versión evaluada.

No existe GET /v1/customers, eliminación de Customers ni administración de identidad en la Integration API.