Manage consent via API
Managing consent programmatically: the subscription-manage operations (suppress, reactivate, opt-out, opt-in), why every operation is per channel, the SMS/RCS exception, and how connected apps declare a compliance policy that Instasent enforces.
Consent isn't only set by hand from the contact profile — it can also be managed programmatically. That said, the same four operations exist on both sides — the panel and the API — so this page isn't a list of "API-only" actions. What it covers is which operations exist, who is authorized to perform each, and how connected apps stay compliant without you having to do anything.
The four operations
Consent is changed through the subscription-manage action, which exposes four
operations:
| Operation | Effect | Axis |
|---|---|---|
| suppress | Blocks the contact from all marketing on the channel (sets suppression). | Channel suppression |
| reactivate | Removes the block; brings the contact back. | Channel suppression |
| opt-out | Records that the contact declined marketing. | Marketing preference |
| opt-in | Records that the contact accepted marketing. | Marketing preference |
These map directly onto the two axes:
opt-out / opt-in move the marketing preference, suppress / reactivate move the
suppression state.
Always per channel — with the SMS/RCS exception
Every operation targets one channel. Opting a contact out of SMS does not touch their WhatsApp consent. The one exception is the shared SMS/RCS consent: acting on SMS also affects RCS, because they're a single state (see Shared consent).
It's about authorization, not "API-only"
All four operations are available in the panel too — from the Channel preferences card on the contact profile. What differs between operations is who may perform them:
- suppress / reactivate — your team (in the panel) or the API. A contact cannot suppress or reactivate themselves.
- opt-out / opt-in — your team or the API and the contact themselves, by replying STOP / START or using an unsubscribe link.
So the meaningful distinction isn't "panel versus API" — it's that some operations are reserved for an authorized operator (suppress, reactivate) while others can originate from the contact (opt-out, opt-in). The reactivation rules in Opt-outs & reactivation follow from this.
Connected apps and the compliance policy
When a connected app or AI agent sends on your behalf, it doesn't apply consent rules itself
— it declares a compliance policy per send, and Instasent enforces it: it
excludes the contacts the policy filters out, and applies the opt-out consequence
automatically. The policy is one of basic, opt-out or opt-in. If a direct
project-API send omits it, Instasent defaults to basic — which always respects
suppressions.
Each policy excludes a different set of contacts at send time:
compliancePolicy | Excludes at send |
|---|---|
basic | Suppressed contacts only. |
opt-out | Suppressed contacts and those who opted out. |
opt-in | Suppressed, opted out and those with no preference (only explicit opt-ins receive). |
It is the same setting as a campaign's Consent policy — the three policies are the same three. The campaign-side view, including what a STOP does under each, is in Compliance policies.
Where the technical contract is documented
This page is the consent model behind the operations. The request and response shapes, the endpoints and authentication for managing consent and sending with a compliance policy belong to the developer documentation — see the Connected apps overview for the panel-side picture, and the Product API reference for the contract itself.