Clientes

Resuelve el sujeto dentro de tu tenant antes del consentimiento o dentro del flujo que lo necesita.

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

Las dos combinaciones de identifier

Consensa acepta exactamente dos:

`system`	`type`	Valor
`cl`	`rut`	RUT chileno, con o sin puntos y con guion. Uno por request.
`email`	`email`	Dirección de correo. Un cliente puede tener varias.

Cualquier otra combinación responde 400 con unsupported_identifier y los valores recibidos en error.details. system y type no distinguen mayúsculas.

Resolve explícito

Usa POST /v1/customers/resolve desde el backend cuando quieras obtener el customerId antes de iniciar Embed, Consentimiento, Autorización 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" },
      { "system": "email", "type": "email", "value": "cliente@ejemplo.cl" }
    ]
  }'

La primera resolución responde 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.

{
  "customerId": "customer-tenant-4f1",
  "userReference": "customer-4821",
  "created": true,
  "identifiers": [
    { "system": "cl",    "type": "rut",   "verified": false },
    { "system": "email", "type": "email", "verified": false }
  ]
}

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 con customer_resolution_conflict. El campo público customerId siempre representa el sujeto del tenant, no un Customer global.

Si incluyes identifiers[].verification, necesitas además el scope consent:identity-assert y debes enviar provenance real:

{
  "system": "cl",
  "type": "rut",
  "value": "12.345.678-5",
  "verification": {
    "method": "bank_kyc",
    "sourceReference": "kyc-4821",
    "verifiedAt": 1787702400000
  }
}

No puedes enviar verified ni provider: los controla Consensa.

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, y es lo que usan los flujos de integración.

Backend → resolve explícito → customerId → Embed / Consentimiento / Autorización / REDEC
Backend → Embed 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.

curl "$CONSENSA_API_URL/v1/customers/$CUSTOMER_ID/consents" \
  --header "Authorization: Bearer $CONSENSA_API_KEY"

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.

Evaluar un consentimiento lógico

Para saber si un ConsentTemplate está satisfecho antes de iniciar un flujo:

curl --get "$CONSENSA_API_URL/v1/customers/$CUSTOMER_ID/consent-compliance" \
  --data-urlencode "templateKey=credit-evaluation" \
  --header "Authorization: Bearer $CONSENSA_API_KEY"

templateKey es obligatorio; sin él la respuesta es 400 customer_id_and_template_key_required.

{
  "status": "partially_compliant",
  "acceptedVersion": { "templateKey": "credit-evaluation", "version": 2 },
  "evaluatedVersion": { "templateKey": "credit-evaluation", "version": 3 },
  "pendingRequirements": [
    { "requirementKey": "credit-bureau-query", "dataCategoryCode": "financial.credit_history", "dataUseCode": "risk_assessment" }
  ],
  "pendingVersionChanges": [
    { "kind": "requirement_added", "requirementKey": "credit-bureau-query", "dataCategoryCode": "financial.credit_history", "dataUseCode": "risk_assessment" }
  ]
}

status distingue complies, partially_compliant y non_compliant. Esta consulta no es autorización: otro template que comparta permisos no cuenta como aceptación, y una fuente expirada no satisface la versión evaluada. Para decidir si puedes tratar los datos usa /v1/authorization/check.

Lo que no existe

No hay GET /v1/customers, ni eliminación de Customers, ni administración de identidad en la Integration API. Los derechos del titular sobre sus datos se ejercen desde el Centro de Privacidad y se gestionan en Solicitudes del titular.