Inbound messaging on Sent has one governing rule: consent is enforced by the platform before the application sees the event. An inbound has already flipped the contact's flag by the time arrives. The application's job is to record it, reflect it in its own UI, and never attempt to send around it.

Ten keywords ship as defaults:

STOP

CANCEL

UNSUBSCRIBE

QUIT

END

START

UNSTOP

SUBSCRIBE

HELP

INFO

Matching requires the entire trimmed message body to equal a keyword, case-insensitively. "Please stop messaging me" does not match; "stop" does. Custom keywords are configured in the Sent Dashboard under Compliance, Opt Keywords, with an action of Opt Out, Opt In, or Help, and each must be a single exact token.

Do not claim keywords that are not in the documented set. In application code, mirror the same exact-match rule only to update local subscriber state and audit evidence; never use that matcher to apply consent to Sent a second time. Keep custom dashboard keywords synchronized with the local mirror, and reconcile against the contact's field when uncertain.

An opt-out sets on the contact record. Consent is contact-level and channel-agnostic: a sent over SMS suppresses WhatsApp and RCS for that contact as well. Consent gates re-apply on every reroute attempt, not only at initial send.

Restoring consent requires the recipient's own action. A user-initiated opt-in keyword clears suppression. accepts , but writing on a contact who opted out through a keyword is a compliance decision, not a technical one: only do it with documented evidence of fresh consent, and record who authorized it and why.

Downstream, a suppressed send does not fail with an error. It is accepted and finalizes as , so consent problems appear as filtered messages rather than as responses. Details are in references/consent-and-keywords.md.

The SMS caveat matters before promising two-way behavior: a deployment sending from an alphanumeric sender ID cannot receive at all, which changes the compliance design rather than merely limiting a feature.

Every outbound RCS message receives an appended STOP chip. Taps carry an opt-out postback handled directly by the consent engine with no keyword matching, and they arrive at the application as with the chip's reply text in . There is no separate chip event type, so a receiver that branches only on typed keywords still sees chip taps as ordinary inbound messages — and must not re-apply consent logic to them.

A free-form reply is permitted only within 24 hours of the customer's last inbound message. Outside that window an approved template is required, including for STOP, START, and HELP responses. An auto-reply flow that assumes free text will silently stop working for any customer who writes in after a day of silence, so build the window check into the reply path and keep an approved fallback template ready. See references/inbound-flows.md for the reply-path decision tree.

Two read-only operations exist:

GET /v3/conversations

GET /v3/conversations/{id}

Both require (at least 1) and (1 to 100); out-of-range values return . The field is always null on these endpoints, so per-message activity must come from . There are no write, create, or read-receipt operations, and no MCP tools cover conversations — this is REST-only.

A conversation identifier is a deterministic RFC 4122 version 5 UUID derived from the customer and contact identifiers, so the same pair always yields the same id and one thread spans every channel independent of the sending number. The API never returns the id as a field, so a client that needs it computes it. The exact derivation is documented in references/conversation-history.md.

Use for signature verification, retries, and dedupe mechanics; for contact CRUD and message summaries; for why an outbound message was ; for authoring the approved templates that out-of-window replies require; and for the campaign-level opt-in, opt-out, and help keyword declarations that US carriers require.