Listar el historial de consentimientos
GET
/v1/consent-eventsPara desarrolladores
Descripción
Lista el historial de consentimientos de la cuenta, del más reciente al más antiguo, con las reglas de cada evento embebidas.
Este recurso es el historial, no el estado vigente. Para saber si hoy se le puede enviar a alguien, use GET /v1/consent-rules/resolve: resuelve la precedencia y devuelve el mismo veredicto que aplicará el envío. Si deriva el veredicto de este listado, por ejemplo tomando el primer resultado, puede obtener otra respuesta. La precedencia no es solo cronológica: entre reglas contradictorias gana la que deniega.
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:
pageinteger- Número de página; la primera es la 1. Default: 1.
page_sizeinteger- Tamaño de página, 1–100. Default: 20.
term_idinteger | null- Filtra por término (ver `GET /v1/consent-terms`).
statusstring, enum: `confirmed | pending | expired` | null- Filtra por estado del evento.
contactstring | null- Filtra por identificador presente en alguna regla del evento, coincidencia exacta. Compara contra la forma en que el identificador quedó almacenado: las direcciones de correo se guardan normalizadas a minúsculas, y los
uniquecodetal cual se enviaron. Buscar[email protected]no devuelve el evento que se registró para esa dirección; buscar[email protected]sí.
Response
200 OKDevuelve una página de resultados:
data con los elementos y pagination para pedir la siguiente. Cada elemento tiene los campos que siguen.idintegersiempre presente- Identificador del evento.
term_idintegersiempre presente- Término aceptado.
term_version_idintegersiempre presente- Versión exacta que el titular aceptó. Queda congelada aunque el término publique versiones nuevas.
statusstring, enum: `confirmed | pending | expired`siempre presente- Un evento
pending(doble opt-in sin confirmar) deja evidencia pero no autoriza nada. methodstring, enum: `single_opt_in | double_opt_in`siempre presente- —
sourcestring, enum: `form | api | import | system`siempre presente- Origen del registro.
submission_idinteger | null- Envío de formulario que originó el evento. Presente solo cuando
sourceesform. Un mismo envío puede producir varios eventos, uno por término aceptado. Por eso este campo permite reconocer entre sí los eventos de un mismo acto. form_idinteger | null- Formulario del que provino el envío. Presente solo cuando
sourceesform. form_namestring | null- Nombre de ese formulario al momento de la consulta. Se mantiene aunque el formulario haya sido eliminado: es evidencia de dónde salió el consentimiento.
confirmed_atstring (date-time) | null- —
expired_atstring (date-time) | null- —
created_atstring (date-time)siempre presente- —
rulesarraysiempre presente- Las reglas que ese evento declaró:
id,channel,contact_type,contact,purpose_id,actionycreated_at. Una revocación se ve acá como una regla conaction: deny.
Notas
- El listado no colapsa el historial: si un titular otorgó y después revocó, aparecen los dos eventos.
- Para registrar un consentimiento nuevo, use
POST /v1/consent-events.
Request
curl -X GET "https://$API_HOST/v1/[email protected]&term_id=4" \
-H "Authorization: Bearer $API_KEY" \
-H "X-Instance-Slug: $SLUG"
Response
{
"data": [
{
"id": 42,
"term_id": 4,
"term_version_id": 7,
"status": "confirmed",
"method": "double_opt_in",
"source": "api",
"submission_id": null,
"form_id": null,
"form_name": null,
"confirmed_at": "2026-05-08T14:22:31Z",
"expired_at": null,
"created_at": "2026-05-08T14:22:31Z",
"rules": [
{
"id": 91,
"channel": "mail",
"contact_type": "email_address",
"purpose_id": 1,
"action": "allow",
"created_at": "2026-05-08T14:22:31Z"
}
]
}
],
"pagination": {
"page": 1,
"page_size": 20,
"has_more": false,
"total_items": 1,
"total_pages": 1
}
}