Tipos aceptados
Los endpoints POST /requests y POST /consents aceptan exactamente cuatro valores de subjectType.
subjectType |
Normalización aplicada |
|---|---|
email |
Elimina espacios de los extremos y convierte a minúsculas. Exige exactamente un @, sin espacios internos, y un dominio con al menos un punto y segmentos no vacíos. |
rut |
Elimina puntos, guiones y espacios, convierte k a K, valida el dígito verificador módulo 11 y devuelve cuerpo-DV. |
phone |
Conserva + solo si era inicial, elimina otros caracteres no numéricos y exige al menos 7 dígitos. No infiere país ni garantiza formato E.164. |
custom |
Solo elimina espacios de los extremos. Conserva mayúsculas y minúsculas; un valor vacío es inválido. |
El valor de entrada puede tener hasta 512 caracteres antes de la normalización.
Ejemplo de email
Entrada:
{
"subjectType": "email",
"subjectValue": " Ada@Example.COM "
}
Valor normalizado:
ada@example.com
Diferencia entre solicitudes y consentimientos
En solicitudes ARCOP, la respuesta no serializa el identificador original. Entrega subjectValueHash, un SHA-256 hexadecimal del valor normalizado.
{
"subjectType": "email",
"subjectValueHash": "b5fc85e55755f9e0d030a10ab4429b6b2944855f9a0d60077fe832becbc41d72"
}
Ese hash sirve para correlacionar; no debe describirse como anonimización ni como garantía de irreversibilidad. En la plataforma, el identificador se guarda cifrado con la clave de la organización y se busca mediante una huella HMAC distinta por organización.
En consentimientos, la respuesta sí incluye subjectValue normalizado:
{
"subjectType": "email",
"subjectValue": "ada@example.com",
"channel": "email"
}
En supresiones se entrega subjectDisplay enmascarado y subjectIdentifierHash.
Identificador inválido — 422
{
"errors": [
{
"message": "El identificador del titular no es válido.",
"rule": "dataSubjectValue",
"field": "subjectValue"
}
]
}
Valida y protege el identificador antes de enviarlo. En particular, no registres el valor sensible en logs de aplicación.