RCS Prerequisites
RCS (Rich Communication Services) Business Messaging lets your business send rich, interactive messages — images, carousels, suggested replies, and more — through the native Android messaging app. Before you can send production RCS messages through EnableX, you must complete the steps below. The setup process involves both technical configuration and a carrier-managed registration and verification workflow that takes days to weeks.
EnableX Account and Project
All RCS messaging is tied to an EnableX project. If you do not have an account yet, sign up at portal.enablex.io.
Create a Project and Obtain API Credentials
Follow these steps to create a project and enable the RCS channel:
1. Log in to the EnableX Portal and navigate to My Projects.
2. Click CREATE PROJECT.
3. Enter a project name and description.
4. In the Channels section, enable RCS services.
5. Click CREATE PROJECT to confirm.
On successful creation, a confirmation popup displays your APP ID and APP Key. These credentials are also emailed to your registered address. Save them securely — every RCS API call requires them in the Authorization header.
| Credential | Where to Find It | How It Is Used |
|---|---|---|
| APP ID | Project dashboard or creation confirmation email | Username in HTTP Basic auth; used to generate Bearer Tokens |
| APP Key | Project dashboard or creation confirmation email | Password in HTTP Basic auth; used to generate Bearer Tokens |
RBM Agent Registration
In RCS, your business does not send messages from a phone number — it sends from a verified RBM (Rich Business Messaging) Agent. An RBM Agent is a verified identity registered with Google's RCS Business Messaging platform. The agent carries your brand name, logo, description, and contact details, all of which appear directly in the user's messaging thread.
Every RCS API call you make includes an agent parameter that references your registered agent name. EnableX provisions and manages the agent registration on your behalf — you do not interact with Google's platform directly.
What Is an RBM Agent?
An RBM Agent is the business identity that users see when they receive an RCS message from you. Unlike SMS — where the sender appears as a phone number or alphanumeric Sender ID — the RBM Agent shows:
- Your business name
- Your brand logo
- A short business description
- Contact information (website, phone, email)
- A verified badge confirming the business identity
This verified, branded presence builds user trust and distinguishes RCS from unbranded SMS.
How to Register Your RBM Agent
To register your business as an RBM Agent through EnableX:
1. Contact EnableX support or your EnableX account manager to initiate the agent registration request.
2. Provide the following information for your agent profile:
| Field | Description |
|---|---|
| Agent Name | The business name displayed to users (e.g., "MyBrand Support") |
| Logo URL | Public HTTPS URL for your brand logo (square format recommended, minimum 256×256 px) |
| Agent Description | Short description of your business and the purpose of the RCS channel |
| Contact Website | Your official business website |
| Contact Phone | Business phone number |
| Contact Email | Business support or contact email |
| Privacy Policy URL | URL to your privacy policy page |
| Terms of Service URL | URL to your terms of service page |
3. EnableX submits the agent registration request to Google's RBM platform on your behalf.
4. Once submitted, the agent enters a review queue managed by Google and participating carriers.
Agent Verification and Launch
After your agent registration is submitted, it goes through a two-stage process before it can send production messages: verification and launch.
Verification Stage
During verification, Google and the relevant carriers review your agent profile to confirm that:
- The business identity is legitimate and matches the provided documentation
- The agent's use case complies with RCS Business Messaging policies
- The brand assets (logo, name) are consistent with the registered business
The verification outcome is one of: approved, rejected, or requires changes. If changes are required, EnableX will relay the feedback and help you resubmit.
Launch Stage
Verification alone does not enable production messaging. After verification, the agent must be launched by the participating carriers in your target markets. The launch process activates the agent on carrier infrastructure so that messages can be delivered to end users on those networks.
Test Mode During Verification
While your agent is awaiting verification and launch, you can still develop and test your RCS integration using test mode. In test mode:
- Messages can be sent to a limited set of pre-registered test phone numbers
- The full RCS message experience is available — text, rich cards, carousels, and suggestions all render normally on test devices
- Test messages are not subject to production carrier routing or template requirements
Contact EnableX to obtain test device numbers and enable test mode for your agent during the verification period.
Message Templates
Template requirements for RCS differ significantly by country. Understanding these rules before you build your integration prevents surprises at send time.
India — Templates Are Mandatory
In India, business-initiated messages require a pre-approved template. You cannot send any message to initiate a new conversation without a template — the API will reject the request.
Once a user responds to your message, a 24-hour session window opens. Within this window, you can send any message type (text, rich card, carousel) without a template. When the session expires, the next business-initiated message again requires a template.
To create and submit templates for approval:
1. Use the EnableX RCS Template API (POST /rcs/v1/templates) to define your template content.
2. Templates support three content types: text, card (rich card), and carousel.
3. Text templates can include dynamic placeholders using square bracket syntax — for example, [name] or [order_id].
4. Submit the template for RBM approval. Templates are typically reviewed within minutes to 24 hours.
POST /rcs/v1/templates. You send a message using an approved template via POST /rcs/v1/messages/templates. See the RCS API — Template System section for complete payload details.
Outside India — Templates Are Optional
Outside India, there is no mandatory template requirement for initiating conversations. You can send any supported message type — text, rich card, or carousel — at any time without prior template approval.
However, templates are still recommended for branding consistency. Using templates for your standard message types ensures that the content, structure, and tone remain uniform across all sends, and makes it easier to manage campaigns at scale.
| Scenario | India | Outside India |
|---|---|---|
| Business-initiated message (new conversation) | Template required | Template optional |
| Within 24-hour session window | No template needed | No template needed |
| Templates recommended for consistency | Yes | Yes |
Fallback Strategy
RCS is not universally supported. It requires Android devices running a compatible version of Google Messages (or another RCS-capable messaging app) on a network where RCS has been activated. Users on iOS, older Android devices, or unsupported carriers will not receive RCS messages.
To ensure these users still receive your message, you must configure a fallback SMS text. When the EnableX API detects that the recipient's device does not support RCS, it automatically delivers the fallback text as a standard SMS — no separate API call is needed.
How Fallback Works
Include the fallback_text parameter in every RCS API call:
{
"type": "card",
"phone": "+919876543210",
"agent": "your-agent-name",
"card": {
"title": "Your order has shipped",
"description": "Tap to track your delivery.",
"url": "https://example.com/shipment-banner.jpg",
"suggestions": [
{
"type": "open_url",
"text": "Track Order",
"url": "https://example.com/track/ORD-78432",
"postback": "track_order"
}
]
},
"fallback_text": "Your order ORD-78432 has shipped. Track it at https://example.com/track/ORD-78432"
}
If the recipient can receive RCS, they see the rich card. If not, they receive the plain SMS fallback text. The same message_id is used for delivery tracking regardless of which channel was used.
fallback_text in every RCS API call. Omitting it means users on non-RCS devices receive nothing. The EnableX API handles channel selection automatically — you do not need to check RCS capability yourself.
Fallback Content Guidelines
- Keep fallback text under 160 characters when possible to avoid multi-segment SMS charges
- Include all key information from the rich message — the user on SMS should receive equivalent value
- For cards and carousels with URLs, include the most relevant URL in the fallback text
- Avoid formatting markup in fallback text — it renders as plain characters in SMS
Webhook Configuration
RCS is a two-way messaging channel. Your webhook receives asynchronous events from the EnableX platform: delivery status updates, incoming user messages, suggestion responses, read receipts, and template status notifications.
Webhook Requirements
Your webhook endpoint must meet the following requirements:
| Requirement | Details |
|---|---|
| Protocol | HTTPS only. HTTP endpoints are not supported. Self-signed TLS certificates are not accepted. |
| Method | HTTP POST — all events are delivered as JSON payloads via POST |
| Acknowledgement | Your endpoint must return HTTP 200 to acknowledge each event. Any other status code causes the platform to retry delivery. |
| Response time | Respond within the timeout window. Processing-heavy logic should be handled asynchronously after acknowledging the event. |
Events Delivered to Your Webhook
Configure your webhook URL in the EnableX Portal under your RCS project settings. The following event types will be posted to your endpoint:
| Event Type | Description |
|---|---|
| Delivery notifications | Status updates for messages you sent — SENT, DELIVERED, READ, and FAILED events arrive as the message moves through the delivery pipeline |
| Incoming messages | Free-form text replies, file shares (images, documents), and location shares sent by the user in response to your messages |
| Template updates | Notifications when a submitted template changes status — approved, rejected, or pending — so your system can react to approval decisions without polling |
| Suggestion / chip responses | Postback events when a user taps a suggested reply or suggested action chip; includes the postback value you defined in the suggestion and the originating message_id |
| Read receipts | A READ event posted when the user opens and reads your delivered message in their messaging app |
message_id field present in all webhook events to correlate incoming events back to the specific API call that triggered them. Store the message_id returned by the send API alongside your own reference data.
Setting Up Your Webhook
1. Deploy your webhook endpoint at a publicly accessible HTTPS URL.
2. Log in to the EnableX Portal and navigate to your RCS project settings.
3. Enter your webhook URL in the designated field and save.
4. Send a test message via the portal or API to verify that events arrive at your endpoint.
5. Confirm your endpoint returns HTTP 200 for each received event.
Supported Regions
RCS availability is determined by three factors: country-level RCS rollout status, carrier support within that country, and whether the user's device and messaging app are RCS-capable.
Coverage varies significantly by market:
| Factor | Details |
|---|---|
| Country coverage | RCS is commercially active in many markets including India, the United States, the United Kingdom, Germany, France, Brazil, and others — but is still being rolled out in additional countries |
| Carrier support | Within a country, individual carriers control RCS activation. A user on a supported carrier receives RCS; a user on an unsupported carrier receives the SMS fallback |
| Device support | RCS requires Android devices with a compatible messaging app. iOS does not currently support RCS Business Messaging. Older Android devices without an RCS-capable app receive the SMS fallback. |
fallback_text parameter for every RCS message. In markets with partial carrier coverage, a significant percentage of your target audience may fall back to SMS — the fallback is not an edge case.
For coverage details in your specific target markets — including which carriers have launched RCS and what percentage of users are RCS-enabled — contact EnableX support. Coverage data changes as carriers continue their RCS rollouts.
Setup Checklist
Use this checklist to track your progress before going live with RCS:
| # | Step | Status |
|---|---|---|
| 1 | Create an EnableX account and project with RCS channel enabled | Required |
| 2 | Obtain APP ID and APP Key from the project dashboard | Required |
| 3 | Submit RBM Agent registration request through EnableX | Required |
| 4 | Complete agent verification review (managed by Google and carriers) | Required |
| 5 | Agent launched by target-market carriers | Required for production |
| 6 | Configure HTTPS webhook URL for delivery events, incoming messages, and suggestion responses | Required |
| 7 | Create and get templates approved (mandatory for India; recommended elsewhere) | Required (India) |
| 8 | Add fallback_text to all RCS API calls | Required |
| 9 | Confirm RCS coverage with EnableX for target markets | Recommended |
| 10 | Test end-to-end flow using test mode during verification period | Recommended |
What's Next
Once your RBM Agent is verified and launched, you are ready to start sending production RCS messages. The following pages cover the API details and advanced configuration:
| Page | What You Will Find |
|---|---|
| RCS API | Complete API reference: authentication, sending text messages, rich cards, carousels, interactive suggestions, template management, and utility APIs |
| RCS Webhooks | Detailed payload schemas for all webhook event types: delivery status, incoming messages, suggestion responses, template updates, and read receipts |
| RCS Rich Media | Media specifications for rich cards and carousels: supported formats, size limits, card heights, orientation options, and the full suggestions field reference |