A representative set of event types you’ll handle:
- DELIVERED, the message reached the user’s device.
- READ / seen, the user opened/viewed the message.
- Inbound message, the user sent free-form text or media to your agent.
- Suggestion response, the user tapped a suggested reply or action; carries postbackData.
- IS_TYPING, the user is composing a reply.
- Failed / fallback, RCS delivery failed or the recipient wasn’t RCS-capable (message handled via SMS/MMS).
- Subscribe / unsubscribe, opt-in or opt-out signals for consent management.
What each event should actually trigger in your system:
| Event | What it means | What to do with it |
|---|---|---|
| Delivered | The message reached the device | Stop fallback timers; count as delivered |
| Read | The person opened the thread | Attribute engagement; suppress a planned reminder |
| Inbound message | Free-form text or media from the user | Route to your bot or agent queue |
| Suggestion response | A tap on a reply or action, carrying postbackData | Advance the flow by intent, do not parse the text |
| Is typing | The person is composing | Hold automated sends briefly |
| Failed or fallback | RCS could not deliver | Reconcile billing to the actual channel |
| Subscribe or unsubscribe | Consent granted or withdrawn | Write to the suppression list immediately |
Two of these need caveats before you build reporting on them. Read receipts are not guaranteed: a person can turn them off, and some clients suppress them entirely, so a missing read event means unknown rather than unread. Reporting it as unread systematically understates engagement, and the effect is not evenly distributed across your audience. Typing indicators are advisory and best-effort, so use them to pace a bot rather than as an input to anything that has to be correct.
The suggestion response is the event that changes how you write the application. Because the tap carries postbackData you chose, intent arrives already resolved, and there is no natural-language parsing step to get wrong. Design that field as structured data, an intent name plus the record identifier, and the same webhook handler can serve an appointment flow and an order flow without branching on message text. RCS suggested reply examples covers the conventions.
Unsubscribe deserves its own path through the code. It is a compliance obligation rather than an analytics event, so it should hit the suppression list on receipt, ahead of any queueing or batching that the other events go through. The requirements are set out in how RCS consent works.