sent-two-way-messaging
Designs inbound and conversational Sent flows — opt-out and opt-in keyword handling, consent state on contacts, auto-replies inside the WhatsApp 24-hour window, RCS STOP chips, conversation history retrieval, and per-channel inbound capability. Use when handling message.received events, implementing STOP or HELP behavior, restoring consent after an opt-out, building a support inbox or chatbot on Sent, or paginating conversation history.
Security Assessment
About sent-two-way-messaging
Sent Two-Way Messaging is a design reference for building inbound and conversational flows on the Sent platform, with compliance as its organizing principle. Its governing rule is that consent is enforced by the platform before the application ever sees an event: an inbound STOP has already flipped the contact's opt_out flag by the time message.received arrives, so the application's job is to record it, reflect it in its own UI, and never attempt to send around it. This solves the common and legally risky problem of applications re-implementing or overriding consent logic.
The skill documents the ten default opt-out, opt-in, and help keywords and their strict exact-match semantics (the entire trimmed body must equal a keyword, case-insensitively), how custom keywords are configured in the Sent Dashboard, and how consent state is contact-level and channel-agnostic so a STOP over SMS suppresses WhatsApp and RCS too. It covers per-channel inbound reality (SMS conditional on an MO-capable provider, RCS full with an appended STOP chip, WhatsApp full only inside the 24-hour customer service window), how suppressed sends surface as FILTERED rather than 4xx errors, and how to restore consent only with documented evidence of fresh consent. Reference files add reply-path decision trees, conversation-history pagination, and audit expectations.
It targets developers building support inboxes, chatbots, or notification systems on Sent who handle message.received events, implement STOP/HELP behavior, or need to reason about consent restoration and per-channel limits. This is security- and compliance-conscious guidance, not offensive tooling.
FAQ
Do I need to apply consent myself when I receive a STOP?
No. The platform enforces consent before the event reaches you; the opt_out flag is already set when message.received arrives. Your application should mirror it into local state and UI for audit, but must never issue a second consent write back to Sent.
How strict is keyword matching?
Very strict. The entire trimmed message body must equal a keyword, compared case-insensitively. 'stop' matches; 'please stop messaging me' does not. This is deliberate to avoid opting out customers who use the word incidentally, and it means real opt-out intent in a sentence should be routed to a human queue.
Is consent per channel or per contact?
Consent is contact-level and channel-agnostic. A STOP received over SMS suppresses WhatsApp and RCS for that contact as well, and consent gates re-apply on every reroute attempt, not only at initial send.
Can I clear a contact's opt_out to re-subscribe them?
PATCH /v3/contacts/{id} technically accepts opt_out, but clearing it for a keyword opt-out is a compliance decision, not a data fix. It should only be done with documented evidence of fresh consent and a record of who authorized it; the clean path is a user-initiated opt-in keyword.
Why can't my SMS deployment receive STOP messages?
SMS inbound is conditional on an MO-capable provider and a supported number type. Alphanumeric sender IDs and SMPP paths without an inbound route never deliver inbound messages, which changes the compliance design rather than merely limiting a feature.
Install sent-two-way-messaging
Quick Setup:
- Copy the skill folder to
.claude/skills/ - Claude will automatically detect and use the skill
Repository
sentdm/sent-plugin