RCS over API

View as Markdown

Send and receive RCS messages and events through the RCS API, Messages API, or Conversations API. The RCS API exposes the full RCS feature set for channel-specific integrations. The Messages API and Conversations API support RCS alongside other channels for omnichannel use cases.

Before you start, familiarize yourself with compliance and guidelines and message types.

Looking for technical details?
Visit the Infobip RCS API documentation for full endpoint specifications, request examples, and response parameters.

What you can do with the RCS API

Use the RCS API to:

Send rich outbound messages in text, file, card, carousel, and template formats, with optional SMS or MMS failover, validity periods, scheduled delivery, delivery time windows, and URL click tracking.
Send messaging events, such as typing indicators and read receipts.
Receive inbound messages and real-time events (user actions and typing).
Track message delivery, read status, and conversation session starts through webhooks.
Check RCS capability for destination numbers before sending.
Manage senders, test numbers, and message templates programmatically.

This API supports full-cycle communication, from transactional alerts, OTPs, and promotional messages to rich, two-way conversational experiences.

Set up authentication and configuration

Before you start sending or receiving RCS messages, complete the following setup:

Authenticate your integration using the API authentication guide. All RCS endpoints are available at your personalized base URL with the standard Infobip Authorization: App header.
Create and launch an RCS sender before sending outbound messages. See Get started with RCS for the sender creation and launch procedure.
Configure webhook notifications to receive delivery reports, seen reports, inbound messages, and events. Set up a subscription through the Subscriptions management API, or assign a global webhook URL in your Infobip web interface.
Review compliance and guidelines to meet regional regulatory and opt-in requirements before sending promotional content.

Outbound messages

Outbound messages, also known as mobile terminated (MT) messages, are messages sent from your business to end users through RCS. RCS supports multiple message formats including text, file, card, carousel, and template messages, each enabling rich, interactive communication. For detailed format specifications, supported media types, and structural requirements, see message types.

For the full list of send endpoints, including bulk and template variants, see Outbound messages in the RCS API reference.

Outbound events

RCS supports conversation indicators that provide real-time feedback during message exchanges. Both iOS and Android platforms support these indicators at no additional cost.

Typing indicators signal to end users that a sender agent or chatbot is actively composing a response. The indicator displays on the end user device for five seconds.

Read receipts confirm that a sender agent has viewed a message from an end user. The end user device displays an indicator showing that the message has been seen.

For endpoint details, see Outbound events in the RCS API reference.

Inbound messages

Inbound messages, also known as mobile originated (MO) messages, are messages sent from end users to your business through RCS. Inbound messages enable two-way communication and can include text, files, location data, and suggestion responses. Inbound messages are delivered to your system through webhook notifications in real time. For details on inbound message types, see message types.

For webhook details, see Inbound messages in the RCS API reference.

NOTE

Media files sent by end users in mobile originated (MO) messages, such as JPG or PDF files, are available for 60 days. After 60 days, Rich Communication Services (RCS) deletes these files from the cache.

Inbound events

Receive webhook notifications when end users interact with suggested actions or start typing.

For webhook details, see Inbound events in the RCS API reference.

Logs and status reports

You can monitor RCS message delivery and end user engagement through delivery reports, seen reports, and detailed message logs. Delivery reports confirm that a message reached the end user device. Seen reports indicate that an end user has opened and viewed the message.

Billing transparency in webhooks

RCS webhooks include billing transparency fields that provide visibility into the billing type applied to each message. These fields help track when messages transition from non-conversational to conversational billing.

Field	Type	Description
`trafficType`	string (enum)	The billing type applied to the message. One of `BASIC`, `SINGLE`, `A2P_CONVERSATION`, `P2A_CONVERSATION`, `RICH`, or `RICH_MEDIA`. See Billing types for the mapping of each value to a billing type.
`interactionType`	string	The interaction classification for the message.
`conversation.id`	string	Unique identifier for the conversation session.
`conversation.canInitiate`	boolean	Indicates whether the message can still start a conversation or session. Returns `true` before the billing model is locked in, and `false` once the message already belongs to a conversation or session. Always `false` for senders with a `NON_CONVERSATIONAL` billing category.

These fields appear in delivery report (DLR) webhooks, mobile originated (MO) message webhooks, and event webhooks.

View example DLR webhook payload with billing transparency fields

NOTE

For details on webhook payload structure and field definitions, see the Receive RCS delivery reports webhook reference.

Conversation Started webhook event

A dedicated webhook event notifies you in real time when a 24-hour conversational billing session begins. This event is triggered for both A2P (business-initiated) and P2A (user-initiated) conversation sessions.

The event is triggered in each of the following scenarios:

A2P Conversation: When an end user responds to a business message within 24 hours, creating a conversation session.
P2A Conversation: When a business responds to an unsolicited end user message within 24 hours, creating a conversation session.

The Conversation Started event retroactively updates the original qualifying message once a conversation or session is established. In the Global conversational billing model, it updates the message that switched into an A2P or P2A conversation. In the US, it updates the qualifying messages that became part of the Interactive Session once the session trigger is met.

Field	Description
`messageId`	Reference to the original message being updated.
`trafficType`	The new billing state after the update.
`conversation.id`	The conversation or session identifier. Matches the conversation ID in subsequent message webhooks during the 24-hour session window.
`conversation.type`	Type of conversation or session that started. One of `A2P`, `P2A`, or `INTERACTIVE_SESSION`.
`conversation.startTime`	ISO 8601 timestamp for when the conversation or session started.
`conversation.endTime`	ISO 8601 timestamp for when the conversation or session ends.
`sender`	The sender name for outbound (MT) messages, or the end user phone number for inbound (MO) messages.
`to`	The destination phone number for outbound (MT) messages, or the sender name for inbound (MO) messages.
`direction`	Direction of the message that triggered the event. Values: `OUTBOUND` (MT message) or `INBOUND` (MO message).

IMPORTANT

To receive webhook notifications, configure your webhook URL in the Infobip web interface. For setup steps, see Set up webhook notifications for messaging events.

For endpoint and webhook details (delivery reports, message logs, seen reports, and the Conversation Started event), see Logs and status reports in the RCS API reference.

Capability check

Verify RCS availability for specific phone numbers before sending messages. Use capability check to implement fallback logic to SMS when RCS is not available. Both synchronous and asynchronous (webhook) capability checks are supported.

NOTE

The capability check API requires a launched RCS sender. Launch the sender before running capability checks.

For endpoint and webhook details, see Capability check in the RCS API reference.

Sender management

Manage RCS senders, their configuration, and launch requests. Sender management covers creating senders, updating configuration and platform parameters, tracking launch status, and receiving webhook notifications on state changes. It also covers requesting a launch for a specific country, submitting the launch request with all required information, and viewing launch requirements per provider and country where RCS launch is available.

When requesting a launch for a single country, you can select specific providers. If you select more than one country, provider selection is not available.

You can request a re-launch of a sender in the following scenarios:

A provider rejected the initial launch request.
A provider was excluded from the original launch request.
An additional provider became available in a country where the sender is already launched.

When additional providers become available, the sender status changes to Launch - Partial success. You can then submit a launch request for the additional provider without creating a separate sender. Subscribe to webhook notifications to receive updates about provider availability and sender status changes.

NOTE

In India, a sender cannot be launched with multiple providers. A single provider offers full country coverage, including all carriers in India.

Use the Sender management API to:

Create and update a sender before launch.
Track sender and sender launch statuses.
View available RCS providers.
Request launch to additional providers for already-launched senders.

Use the Resource Request API to:

Query launch information.
Submit and update launch requests.
Track the launch request lifecycle.
Receive feedback on launch and sender information.
Opt in to structured feedback for launch rejections by including the structuredFeedback flag in the submit request.

For endpoint and webhook details, see Sender management in the RCS API reference.

Sender verification and launch approval

Infobip requests the RCS technology provider or MNO to verify your sender. Some MNOs may require you to complete additional checks to use their services. Contact your Infobip account manager or support for more information.

If a launch request is rejected, the rejection identifies which fields have issues and how to resolve them. To receive structured feedback, include the structuredFeedback flag when submitting a launch request through the Resource Request API. Structured feedback provides per-field error codes instead of free-form text. For details, see Structured launch feedback.

After launch approval:

Your sender is live and approved for production traffic.
You can send RCS messages and campaigns without limits to destinations where your sender has been launched.
You do not need to invite the contacts as testers or safelist their numbers.

NOTE

Once your sender is launched in a country, test devices from that country are removed. You can still add test devices for this sender in all other countries.

Sender management webhooks

RCS sender management provides webhook notifications for sender status changes, provider availability updates, and launch status updates. Subscribe to these events through the Subscriptions management API.

Event	Description
`SENDER_UPDATE`	Sender status changed. Includes a `reason` field.
`PROVIDER_UPDATE`	An additional RCS provider became available in a country. Market-level event, not sender-specific.
`RCS_SENDER_LAUNCH_STATUS_UPDATE`	Launch request status changed. Delivers structured feedback when opted in.

Sender update webhook

The SENDER_UPDATE webhook notifies you when a sender status changes. Each event includes a reason field that explains why the status changed.

Reason	Description
`SENDER_SUBMITTED`	Sender creation or edit was submitted and is being processed.
`SENDER_CREATED_OR_EDITED`	Sender creation or edit completed. The sender is ready for validation.
`LAUNCH_REQUEST_SUBMITTED`	A launch request was submitted. The sender is locked and cannot be edited.
`LAUNCH_REQUEST_RESULT`	Launch request processing finished. Covers success, partial success, and failure outcomes.
`NEW_PROVIDER_AVAILABLE`	An additional provider became available in a country where the sender is launched. The sender status changes to Launch - Partial success.

For the full list of sender statuses and how each status affects sender editing, test devices, and production traffic, see Sender statuses.

Example payload

json

2 "event": "SENDER_UPDATE",

3 "senderName": "DemoSender",

4 "senderStatus": "LAUNCHED_PARTIAL_SUCCESS",

5 "reason": "NEW_PROVIDER_AVAILABLE",

6 "updatedAt": "2026-07-27T09:12:00.000+0000"

Provider update webhook

The PROVIDER_UPDATE webhook notifies you when an additional RCS provider becomes available in a country. This is a market-level event, not a sender-level event. It fires regardless of whether any sender is launched in that country.

Subscribe to this event with events: ["PROVIDER_UPDATE"]. No sender resources are required for the subscription.

Field	Description
`event`	Event type. Value: `PROVIDER_UPDATE`.
`countryCode`	ISO country code identifying the market where the provider became available.
`providers`	Array containing a single provider object with `name`, `status`, and `updatedAt` fields.
`updatedAt`	ISO 8601 timestamp for when the event was emitted.

If multiple providers become available at the same time in the same country, a separate event is sent for each provider.

Example payload

json

2 "event": "PROVIDER_UPDATE",

3 "countryCode": "US",

4 "providers": [

5 {

6 "name": "Verizon",

7 "status": "AVAILABLE",

8 "updatedAt": "2026-07-27T09:12:00.000+0000"

9 }

10 ],

11 "updatedAt": "2026-07-27T09:12:00.000+0000"

12}

Structured launch feedback

When submitting a launch request through the Resource Request API, include the structuredFeedback opt-in flag. When a launch request is rejected, the system delivers feedback through the RCS_SENDER_LAUNCH_STATUS_UPDATE webhook event and the GET RCS sender launch status API response. Feedback includes structured error codes instead of free-form text.

Structured feedback provides per-field rejection reasons with the following structure:

externalRequirementKey identifies the launch data field (for example, optInUrl).
requirementKey identifies the sender data field (for example, description).
errors contains an array of error objects, each with a key, reason, and details.

The feedback array replaces the previous free-form rejectionReason field in each provider's coverage entry.

For the structured feedback payload format, see the Receive RCS sender launch update events API reference.

Test number management

Manage test numbers used to validate an RCS sender before launch. Test number management covers adding and removing test numbers, setting the primary test number, refreshing availability, and receiving webhook notifications when test number state changes.

For endpoint and webhook details, see Test number management in the RCS API reference.

Template management

Create, update, and submit RCS message templates for approval. Template management covers listing templates, creating and editing templates, submitting them for approval, checking approval status, and receiving webhook notifications when template state changes.

For endpoint and webhook details, see Template management in the RCS API reference.

Was this page helpful?