Gestión del consentimiento por API
Gestionar el consentimiento de forma programática: las operaciones de subscription-manage (suppress, reactivate, opt-out, opt-in), por qué cada operación es por canal, la excepción SMS/RCS y cómo las apps conectadas declaran una política de cumplimiento que Instasent aplica.
El consentimiento no se gestiona solo a mano desde el perfil del contacto: también se puede gestionar de forma programática. Ahora bien, las mismas cuatro operaciones existen en los dos lados —el panel y la API—, así que esta página no es una lista de acciones "solo de API". Lo que explica es qué operaciones existen, quién está autorizado a hacer cada una y cómo las apps conectadas se mantienen conformes sin que tengas que hacer nada.
Las cuatro operaciones
El consentimiento se cambia mediante la acción subscription-manage, que expone cuatro
operaciones:
| Operación | Efecto | Eje |
|---|---|---|
| suppress | Bloquea al contacto de todo el marketing del canal (marca la supresión). | Supresión de canal |
| reactivate | Quita el bloqueo; recupera al contacto. | Supresión de canal |
| opt-out | Registra que el contacto rechazó marketing. | Preferencia de marketing |
| opt-in | Registra que el contacto aceptó marketing. | Preferencia de marketing |
Estas operaciones se corresponden directamente con los dos
ejes: opt-out / opt-in mueven la
preferencia de marketing, y suppress / reactivate mueven el estado de supresión.
Siempre por canal — con la excepción SMS/RCS
Cada operación apunta a un canal. Dar de baja a un contacto de SMS no toca su consentimiento de WhatsApp. La única excepción es el consentimiento compartido de SMS/RCS: actuar sobre SMS afecta también a RCS, porque son un único estado (ver Consentimiento compartido).
Es cuestión de autorización, no de "solo API"
Las cuatro operaciones están disponibles también en el panel — desde la tarjeta Preferencias de canal del perfil del contacto. Lo que cambia entre operaciones es quién puede hacerlas:
- suppress / reactivate — tu equipo (en el panel) o la API. Un contacto no puede suprimirse ni reactivarse a sí mismo.
- opt-out / opt-in — tu equipo o la API y también el propio contacto, respondiendo STOP / START o usando un enlace de baja.
Así que la distinción de fondo no es "panel frente a API" — es que algunas operaciones están reservadas a un operador autorizado (suppress, reactivate) mientras que otras pueden venir del contacto (opt-out, opt-in). Las reglas de reactivación de Bajas y reactivación se derivan de esto.
Apps conectadas y la política de cumplimiento
Cuando una app conectada o un agente de IA envía en tu nombre, no aplica las reglas de
consentimiento por su cuenta — declara una política de cumplimiento por envío e Instasent se
encarga de aplicarla: excluye a los contactos que la política filtra y aplica la consecuencia del
opt-out automáticamente. La política es una de basic, opt-out u opt-in. Si un
envío directo por la API del proyecto la omite, Instasent usa basic por defecto — que
siempre respeta las supresiones.
Cada política excluye un conjunto distinto de contactos en el momento del envío:
compliancePolicy | Excluye al enviar |
|---|---|
basic | Solo los contactos suprimidos. |
opt-out | Los suprimidos y los que hicieron opt-out. |
opt-in | Suprimidos, de baja y los que no tienen preferencia (solo reciben los opt-in explícitos). |
Es el mismo ajuste que la Política de consentimiento de una campaña — las tres políticas son las mismas tres. La vista del lado de la campaña, incluido qué hace un STOP bajo cada una, está en Políticas de cumplimiento.
Dónde se documenta el contrato técnico
Esta página es el modelo de consentimiento detrás de las operaciones. Las estructuras de petición y respuesta, los endpoints y la autenticación para gestionar el consentimiento y enviar con una política de cumplimiento pertenecen a la documentación de desarrolladores — consulta la visión general de Apps conectadas para la parte del panel, y la referencia de la Product API para el contrato en sí.