Agents and channels
RCS on this platform is built around two related concepts that appear in different contexts:| Concept | Field | Where it appears |
|---|---|---|
| Agent | agent_id | Send requests (POST /v1/messages), RCS management API, conversation.* webhook events |
| Channel | channel_id | Message log responses (GET /v1/messages), billing records |
agent_id.
The platform maps each agent to a channel internally. Message history and log endpoints expose channel_id for consistency across all channel types (Email, RCS, SMS) — even though you sent via agent_id. Both are visible in the dashboard; they identify the same configured sender from different angles.
You send with
agent_id. You query history with channel_id. See Identifiers for the full ID reference.Agent lifecycle
Production agents go through submission and Google / carrier review. The lifecycle is:DRAFT → PENDING_REVIEW → APPROVED (or REJECTED). After approval, the agent is launched on carriers before you can reach subscribers.
The Test Agent is a shared, already-approved agent that lets developers send real RCS to one verified handset before investing in full agent setup. See RCS sandbox quickstart.
Content and traffic types
- Message types
- Traffic types
- Capabilities
| Type | When to use |
|---|---|
MESSAGE | Outbound-initiated sends — text, rich cards, carousels |
CONVERSATION | Follow-up within an active 24-hour session opened by a user reply |
NEWSLETTER | Opted-in subscriber broadcasts — requires newsletter_enabled: true on the agent |
Billing (high level)
RCS uses Basic vs Single for outbound sends, Conversation for session-based two-way messaging, and MAU for newsletter-style subscriber broadcasts. Every successful API response includesbilling metadata inline.
Details: Billing (RCS) and Billing units.
Related
- Introduction to the API — request path from API key to provider
- RCS agents — agent creation, profile, newsletter enablement
- Our philosophy — time-to-first-message and readable errors