# 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.

**Language:** en
**Audience:** platform
**Translation key:** platform.consent.managing-via-api
**Search keywords:** manage consent api, subscription-manage, suppress, reactivate, opt-out api, opt-in api, consent api, compliance policy, compliancePolicy, enforcement, connected apps consent, agent consent, per channel operation, authorization, who can suppress
**Related pages:** /platform/es/consent/managing-via-api, /platform/en/consent, /platform/en/consent/opt-outs-reactivation, /platform/en/campaigns/compliance-policies, /platform/en/developers-and-apps
**Docs index (every page):** https://docs.instasent.com/llms.txt
**This zone's index:** https://docs.instasent.com/platform/en/llms.txt
**This page:** https://docs.instasent.com/platform/en/consent/managing-via-api/ (HTML) · https://docs.instasent.com/platform/en/consent/managing-via-api.md (Markdown)
**Other language (es):** https://docs.instasent.com/platform/es/consent/managing-via-api.md

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](/platform/en/consent/marketing-preference-vs-suppression):
`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](/platform/en/consent/rcs-sms-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](/platform/en/consent/opt-outs-reactivation) follow from this.

{/* VERIFY: the premise that some operations are "API-only" does not hold — all four exist in the panel; this page frames the axis as authorization instead */}

## Connected apps and the compliance policy

> **Note**: **`compliancePolicy` is the API name for the setting the dashboard calls
> Consent policy.** Same three policies, same effect — the field is named after
> the section, the selector after the setting. Whenever this page says
> *compliance policy*, it is that field.

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](/platform/en/campaigns/compliance-policies).

> **Note**: **Instasent enforces the policy; the app only declares it.** An app never needs to fetch
> the audience and filter it for consent — it states the policy it intends, and the platform
> guarantees the exclusions and records the consequence of an opt-out.

## 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](/platform/en/developers-and-apps) overview for the panel-side picture, and the
Product API reference for the contract itself.

---

This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://docs.instasent.com/llms.txt — start there for full context.