Resolver el consentimiento vigente

GET/v1/consent-rules/resolve

Para desarrolladores

Descripción

Responde la pregunta operativa del consentimiento: ¿le puedo enviar a esta persona, por este canal, para esta finalidad?

Dado un canal, una finalidad y los identificadores que se conozcan del titular, aplica la misma precedencia que el envío y devuelve el veredicto vigente. Es la única forma correcta de consultarlo: el listado de eventos es historial, y derivar el veredicto de él por su cuenta puede dar otra respuesta.

Guía relacionada

• Consentimiento — Registre y consulte el consentimiento de sus contactos.

Autenticación

Authorizationbearer tokenheaderobligatorio

API key con scope consent:read. Formato: Bearer <API_KEY>.

X-Instance-Slugstringheaderobligatorio

Identificador de su instancia. Ver Autenticación.

Request

Query params:

channelstring, enum: `mail | sms | wsp | call | push`obligatorio

Canal del envío.

purpose_idintegerobligatorio

Finalidad del envío (ver `GET /v1/consent-purposes`).

contactstring (repetible)obligatorio

Identificador del titular. Se repite para consultar por varios identificadores de la misma persona.

contact_typestring (repetible), enum: `email_address | phone_number | uniquecode`obligatorio

Tipo de cada contact, en el mismo orden y con la misma cantidad.

contact y contact_type se emparejan por posición:

GET /v1/consent-rules/resolve?channel=mail&purpose_id=1&contact=[email protected]&contact_type=email_address&contact=RUT-123&contact_type=uniquecode HTTP/1.1

Pase todos los identificadores que conozca de la persona. El vínculo entre una dirección de correo y un código propio no existe en Fidelizador: solo quien llama sabe que son la misma persona, así que la precedencia solo puede aplicarse sobre lo que venga en la consulta. Si dos identificadores de la misma persona sostienen reglas opuestas, gana la que deniega.

Response

200 OKmatched indica si existe una regla para alguno de los identificadores; action y rule vienen solo cuando es true.

matchedbooleansiempre presente

true si existe una regla para alguno de los identificadores consultados.

actionstring, enum: `allow | deny` | null

El veredicto que gobierna. Ausente cuando matched es false.

ruleobject | null

La regla que ganó la precedencia, con el evento que la originó. Ausente cuando matched es false.

Nota

Sin ninguna regla registrada para los identificadores consultados, la respuesta es { "matched": false }, sin action ni rule.

Errores

Código	Cuándo
409	contact y contact_type no traen la misma cantidad de valores (consent_contact_pairs_mismatch).

Notas

• matched: false no es lo mismo que allow. Significa que no hay ninguna regla registrada. Si el remitente exige la finalidad en modo opt_in, la ausencia de regla impide el envío; en modo opt_out, lo permite. Configure el remitente desde el panel (ver Campos, formularios y consentimiento).
• Las direcciones de correo se comparan en forma canónica, así que consultar [email protected] devuelve la regla registrada para [email protected]. Los uniquecode se comparan tal cual: ABC y abc son códigos distintos.
• El veredicto es por finalidad. Si el remitente declara más de una, el envío requiere que todas pasen: basta una denegada para que el correo no salga.

Request

curl -G "https://$API_HOST/v1/consent-rules/resolve" \
-H "Authorization: Bearer $API_KEY" \
-H "X-Instance-Slug: $SLUG" \
--data-urlencode "channel=mail" \
--data-urlencode "purpose_id=1" \
--data-urlencode "[email protected]" \
--data-urlencode "contact_type=email_address"

Response

{
"matched": true,
"action": "deny",
"rule": {
  "consent_event_id": 42,
  "channel": "mail",
  "contact_type": "email_address",
  "contact": "[email protected]",
  "purpose_id": 1,
  "action": "deny"
}
}