RCS: Frequently Asked Questions

This article answers common questions about how RCS works in Iterable, including sender registration, message delivery, subscriptions, and reporting.

# In this article

# Does Iterable RCS use a short code or long code?

Iterable RCS does not use short codes, long codes, or alphanumeric sender IDs. Your brand identity is verified directly with Google and mobile carriers as part of the sender registration process. For end users, your RCS messages appear as though they came straight from your brand, not from a phone number.

This also means there is no number pooling, sticky sender configuration, or third-party messaging services to manage. Your RCS sender is your brand, and that configuration lives entirely within Iterable.

# Does RCS require a separate opt-in from my existing SMS program?

RCS is a separate channel from SMS, and Iterable manages consent for each channel as separate data fields. However, whether this means you need to collect a new or separate opt-in for RCS is dependent on the language of your existing SMS opt-in. See RCS Best Practices: Impact on existing SMS opt-ins.

For RCS setup guidance, see Setting up RCS.

# Do RCS permissions differ from SMS permissions?

Yes. RCS uses its own message medium permission. Access to SMS does not grant permission to create or send RCS campaigns. To create and send RCS campaigns, you need the Manage and Launch Campaigns permission with RCS selected as an allowed message medium.

For the full list of RCS-related permissions, see RCS permissions.

# How long does it take for my RCS sender to be approved?

Plan for about 4 to 5 weeks from a clean first submission. Timing varies based on your submission, brand verification, and carrier review. Monitor your sender and destination statuses in Iterable, and respond promptly to any follow-up requests.

Iterable does not commit to a specific SLA for registration and approval processes, and neither do carriers.

For the full phase breakdown and expectation setting, see Registration timeline in the RCS Sender Registration Overview.

# Why does my sender still show Draft after I submitted a destination?

After you submit a destination, the destination can move to Pending while the sender still shows Draft for up to about one week. This is normal. External review starts when the destination is Pending, even if the sender has not moved yet.

Check both statuses on the sender detail page. Treat the destination status as the signal that review is underway.

For status definitions, see RCS Registration Statuses.

For what to monitor during the review process, see RCS Registration: Managing approvals.

# Does RCS support Quiet Hours?

Yes. You can enable Quiet Hours for blast, triggered, and journey RCS campaigns. Quiet Hours are off until you enable them. See Sending RCS Campaigns for where to turn them on.

Quiet Hours can help you avoid sending at nighttime in each recipient's local time. They do not guarantee compliance with regional sending-time rules. Check with your legal counsel. See Best Practices for RCS Compliance.

# Does Iterable process STOP, HELP, or START automatically?

No. Iterable does not automatically handle STOP, HELP, or START keywords for RCS. Use journeys to identify those replies, update subscriptions, and send confirmation messages. See Handling STOP and HELP replies.

# Does Iterable send fallback messages automatically?

No. Iterable does not automatically send a fallback message when RCS delivery fails. Use a journey to send a message on another channel after a failed RCS send. See Sending fallback campaigns for users who cannot receive RCS.

# Can I send template proofs before the sender is approved?

No. Template proofs require a launched sender (Partially approved, Update required, or Approved). While the sender is in Draft, send test messages to registered test numbers from the sender page. See Sending a test message and RCS Registration: Testing a sender.

# Why don't I see click or read metrics?

Click metrics require Shorten and track on the RCS template. Read metrics require the recipient's device to report a read receipt. A missing RCS Seen event does not necessarily mean the recipient did not read the message. See RCS Campaign Analytics and RCS System Events.

# Does RCS require a mobile data or WiFi connection to deliver?

Yes. RCS messages are delivered over the recipient's internet connection, such as mobile data or WiFi, rather than over the cellular SMS network. Recipients need an RCS-capable device with an active internet connection to receive them.

If a recipient's device is offline or RCS is unavailable, delivery may fail instead of behaving like SMS delivery.

Having fallback behavior is important for RCS because you can send a backup message to another channel, like SMS, if the RCS delivery fails. Iterable does not send this fallback automatically. Use a journey to send it after a failed RCS send. See Sending fallback campaigns for users who cannot receive RCS.

# Do data rates apply to RCS?

Yes. RCS messages travel over your recipient's internet connection rather than the cellular SMS network, so message and data rates may apply. Include this disclosure in your opt-in messaging.

# What is the character limit for RCS messages?

Text-only RCS templates can contain up to 2,500 characters. Cards, carousels, buttons, and media URLs have separate limits. For the full list, see Creating RCS Templates.

# Is Iterable RCS first-party only? Can I use it if I use a third-party SMS connector?

Iterable RCS is a first-party channel that you can add to your Iterable plan. SMS and RCS operate independently. To add RCS to your plan, contact your Iterable customer success manager.

# What happens when a recipient's device doesn't support RCS?

If the recipient's device does not support RCS or has RCS disabled, the send results in an RCS Bounce event with an errorCode value 7002. Iterable does not automatically send a fallback message. Use a journey to send a message on another channel after this bounce.

See Sending fallback campaigns for users who cannot receive RCS and Identifying users who cannot receive RCS.