Vi RCS Template Whitelisting – Complete Guidelines

1. Agent / Message Category

Vi-RBM broadly supports these business communication use cases:

TypeTypical usageKey restriction
OTPOTP, authentication, verificationNo promotional content
TransactionalOrder, payment, delivery, booking, service alertsMust be genuinely transactional
Promotional / MarketingOffers, campaigns, discounts, product promotionPromotional hours and message-frequency limits apply

Vi's public policy specifically defines Promotional Agents as agents used for sales, marketing and promotional communication. (Virbm)


2. Promotional / Marketing RCS

This is one of the most important areas for template approval.

Promotional initiation window

For promotional traffic, Vi currently specifies:

10:00 AM – 9:00 PM, 7 days a week

Brands should initiate promotional conversations only within this window. (Virbm)

Promotional message limit

Vi currently specifies:

  • Maximum 4 A2P promotional messages per brand per end user per month

  • The limit applies across all Promotional Agents of the same brand

  • P2A messages are not counted toward this limit

  • When the user responds, the brand gets 2 additional messages. (Virbm)

Marketing template examples

Allowed type:

"Get 20% off on your next purchase. Shop now."

or:

"Your exclusive weekend offer is here. Get ₹500 off. Limited period."

The template should clearly represent promotional intent.

Avoid

Don't submit a template as transactional and then use it for:

  • Discounts

  • Cross-sell

  • Upsell

  • New product promotion

  • Promotional offers

  • "Buy now"

  • "Limited-time offer"

if the actual communication is promotional.


3. Transactional Templates

Transactional messages are intended for an existing customer interaction or service event.

Examples:

  • Order confirmation

  • Order shipped

  • Delivery update

  • Payment confirmation

  • Booking confirmation

  • Appointment reminder

  • Account/service notification

  • Ticket confirmation

  • Service request update

Vi identifies transactional messaging separately from promotional messaging, and its public site describes RCS for reminders, transactional alerts and service updates. (Virbm)

Example

Hi [1], your order [2] has been confirmed. Expected delivery is [3].

Variables:

  • [1] = Customer name

  • [2] = Order ID

  • [3] = Delivery date

Important

Don't mix promotional content into a purely transactional template unless the applicable policy/approval permits it.

For example, this can create a classification issue:

Your order [1] has been shipped. Buy another product and get 20% OFF!

The first sentence is transactional; the second is promotional.


4. OTP Templates

OTP messages should be restricted to authentication/verification purposes.

Example

Your OTP for [1] is [2]. This OTP is valid for [3] minutes. Do not share it with anyone.

Where:

  • [1] = Service/application

  • [2] = OTP

  • [3] = Validity

Avoid adding marketing language such as:

Your OTP is [1]. Also get 20% off on your next purchase.

Keep OTP communication focused on authentication.

Vi's policy specifically distinguishes OTP agents from transactional/promotional agents. (Virbm)


5. Text Template

For a simple text template:

Variable format

Use:

[1]
[2]
[3]

Example:

Hello [1], your appointment with [2] is scheduled for [3].

Variable rules

  • Use square brackets.

  • Number variables sequentially.

  • Maintain the same variable mapping during execution.

  • Don't change the variable type after approval.

  • Don't insert an additional variable during live traffic without updating the approved template.


6. Rich Card Template

A Rich Card can contain:

  1. Image/GIF/video/PDF

  2. Title

  3. Description

  4. Suggested replies/actions

Google's current RCS specification allows up to 200 characters for the title, 2,000 characters for the description, and up to 4 suggestions/actions within a rich card. (Google Developers)

Example

Title:

Premium Data Plans

Description:

Get more data with our latest plans. Choose the plan that suits your usage.

CTA:

View Plans

CTA URL:

Static or dynamic whitelisted URL

Rich Card variables

Example:

Hi [1], get [2]% off on your next purchase.

The variables must be mapped consistently.


7. Rich Card Image Guidelines

Google currently supports image formats including:

  • JPG/JPEG

  • PNG

  • GIF

It also supports video formats and, specifically for India on Google Messages, PDF files in rich cards. (Google Developers)

For vertical rich cards, the documented media heights are:

  • Short: 112 DP

  • Medium: 168 DP

  • Tall: 264 DP

Recommended aspect ratios are:

Practical whitelisting recommendation

Keep the image:

  • Relevant to the message

  • Consistent with the brand

  • Clear and readable

  • Free from misleading claims

  • Consistent with the approved template

Don't submit one creative for approval and then send a substantially different creative under the same template.


8. Rich Card CTA / Buttons

A Rich Card can have up to 4 suggestions/actions within the card. Google currently limits suggestion text to 25 characters. (Google Developers)

Examples:

  • Shop Now

  • View Details

  • Track Order

  • Book Now

  • Call Us

  • Know More

CTA text should accurately represent what happens when the user taps it.

Example

CTA: Track Order

URL: tracking URL

Don't use:

CTA: Track Order

and redirect the user to an unrelated promotional landing page.


9. Dynamic URL

For a dynamic URL, use a variable.

Example:

Track your order here: [2]

If the platform/Vi portal requires the URL to be identified separately, maintain the appropriate URL variable mapping.


10. Dynamic Shortened URL in CTA

Based on the Vi portal convention you provided, use:

[2_sh_code]

The _sh_code suffix identifies the dynamic shortened URL.

Example

CTA:

Track Now

CTA URL variable:

[2_sh_code]

Where:

  • 2 = variable index

  • _sh_code = dynamic shortened URL identifier

This is an important convention to retain when preparing Vi templates.


11. Static Shortened URL

If the shortened URL doesn't change, put the URL directly into the template.

Example:

Click here to know more: https://abc.in/offer

Don't unnecessarily convert a static URL into [1_sh_code].


12. Dynamic URL + Static Domain

For example:

https://example.com/order/123456

If 123456 changes dynamically, the template should represent the dynamic component as a variable according to the Vi portal's accepted format.

Conceptually:

https://example.com/order/[1]

Where:

[1] = Order ID

The domain/base URL should remain consistent with the approved/whitelisted URL.


13. Carousel Template

A carousel contains multiple Rich Cards.

Google currently supports:

Minimum: 2 cards
Maximum: 10 cards. (Google Developers)

Example:

Card 1

1 GB Data Plan
₹99
Buy Now

Card 2

2 GB Data Plan
₹149
Buy Now

Card 3

5 GB Data Plan
₹249
Buy Now

Carousel rules

  • Cards should belong to the same overall use case.

  • Keep card structure consistent.

  • Keep CTA behavior consistent where possible.

  • Each card can have its own variables/content.

  • Don't mix unrelated products/services in one carousel.

  • Don't use a carousel to disguise unrelated promotional content.

Google documents carousel cards as vertical rich cards and allows up to 10 cards. (Google Developers)


14. Carousel Card Variables

Example:

Card 1

[1] GB Plan
₹[2]
Valid for [3] days

Card 2

[4] GB Plan
₹[5]
Valid for [6] days

If the same variable represents the same logical value across cards, retain the same variable mapping.


15. Carousel CTA

Each card can have suggestions/actions.

Example:

CardCTA
Plan 1Buy Now
Plan 2Buy Now
Plan 3Buy Now

CTA URLs may be:

  • Static

  • Dynamic

  • Dynamic shortened URLs

Use the corresponding approved variable/URL format.


16. Suggested Replies

Suggested replies allow users to respond to the agent.

Examples:

  • Yes

  • No

  • Track Order

  • Talk to Agent

  • View Plans

  • Cancel

Google currently specifies a maximum of 25 characters per suggestion. (Google Developers)


17. Suggested Actions

RCS supports actions such as:

  • Open URL

  • Dial a number

  • View location

  • Share location

  • Create calendar event

Google documents these as native device actions. (Google Developers)

The action should match the text.

Example:

Button: Call Support

→ Should trigger a phone call.

Button: View Store

→ Should open the appropriate location/map experience.


18. Number of Buttons / Suggestions

For a Rich Card:

Maximum 4 suggestions/actions within the card.

Additional transient suggestion chips can be used outside the card, with Google currently documenting up to 11 total suggestions in the relevant message configuration. (Google Developers)

For template approval, however, I recommend keeping the number of buttons limited to the actual user actions required rather than filling all available slots.


19. 24-Hour Conversation Window

This needs to be distinguished from the promotional initiation window.

A conversation can operate as a two-way interaction when the user responds.

Google's current billing documentation defines a conversational window around a user/agent reply: once one party responds to the other, the conversation can continue within a 24-hour window. (Google Developers)

Vi additionally has its own Promotional Agent rules, including the 10 AM–9 PM initiation window and monthly promotional message limits. (Virbm)

So don't treat:

24-hour conversation window

and

10 AM–9 PM promotional initiation window

as the same rule.


20. Promotional vs Transactional Classification

This is one of the most important checks before submitting a template.

Transactional

Your order [1] has been shipped. Expected delivery: [2].

Promotional

Get 20% OFF on your next order. Shop now!

Mixed

Your order [1] has been delivered. Get 20% OFF your next purchase!

The third message contains both service information and promotion. It should be reviewed according to the applicable promotional/transactional classification rather than assuming it is purely transactional.


21. Opt-in / Consent

Vi's RBM policy requires brands to communicate with users who have explicitly opted in to receive their messages. Vi also states that SMS opt-in counts as RCS opt-in. (Virbm)

Therefore:

  • Maintain opt-in records.

  • Don't send unsolicited promotional RCS.

  • Don't purchase/share phone numbers without appropriate consent.

  • Maintain applicable opt-out and regulatory processes.


22. Spam / Frequency

Vi specifically prohibits spam and aggressive messaging.

For Promotional Agents:

Maximum 4 A2P promotional messages/user/month/brand

and this is across the brand's Promotional Agents. (Virbm)

So, for example, having multiple promotional agents does not mean each agent gets its own separate quota.


23. Template Content Consistency

The approved template and live message should remain aligned.

Don't change:

  • Message purpose

  • CTA

  • CTA URL

  • URL domain

  • Number of cards

  • Card purpose

  • Variable mapping

  • Promotional/transactional classification

  • Major creative/message content

after approval without appropriate template approval.

Vi explicitly states that RCS message templates require approval before execution. (MYVI)


24. Web URLs / CTA URLs

Before going live, verify:

  • Domain is approved/whitelisted as required.

  • HTTPS URL is valid.

  • URL resolves correctly.

  • Dynamic parameters are correctly mapped.

  • Shortened URL is configured correctly.

  • CTA label accurately describes destination.

  • Redirect doesn't unexpectedly move users to an unrelated domain.

Google's current RCS behavior also provides URL transparency for "Open a URL" persistent suggestions in supported clients. (Google Developers)


25. Variables – Recommended Standard

I recommend maintaining this internal format:

VariableMeaningExample
[1]Customer NameRahul
[2]Order IDORD123
[3]Amount₹999
[4]Date25 Sep
[5]ProductiPhone
[6_sh_code]Dynamic shortened URLDynamic
[7]OTP123456

Important: Don't reuse a variable index for a different meaning within the same approved template.


26. Marketing Creative Guidelines

For promotional cards/carousels:

Recommended

  • Clear offer

  • Clear product/service

  • Clear CTA

  • Relevant image

  • Accurate pricing

  • Valid offer period

  • Valid landing page

Avoid

  • Misleading discounts

  • Fake urgency

  • Unrelated images

  • Unclear CTA

  • Unsupported claims

  • Hidden terms

  • Unapproved URLs

  • Excessive promotional copy

  • Content that doesn't match the approved template


27. Prohibited / Restricted Content

Vi's RBM policy contains restrictions around prohibited content and behavior, including spam, fraudulent/invalid activity and misuse of the platform. (Virbm)

Businesses also need to comply with applicable Indian laws and regulations.

Vi's terms additionally restrict collecting/using certain sensitive personal and confidential information through RCS, while allowing OTP/2FA use subject to consent and applicable law. (Virbm)


28. Media / File Size

Google currently documents a 100 MiB combined attachment limit per RBM message for media and PDF attachments. (Google Developers)

For practical template approval, keep media substantially smaller where possible to improve loading and user experience.


29. Rich Card Character Limits

Current Google RCS limits:

ElementLimit
Card title200 characters
Card description2,000 characters
CTA / suggestion25 characters
Suggestions in cardUp to 4
Carousel cards2–10

(Google Developers)


30. Recommended Vi Template Submission Format

For your internal template sheet, I recommend using these columns:

FieldExample
Template IDRCS_MKT_001
Agent TypePromotional
Template TypeCarousel
Message BodyGet [1]% OFF on [2]
Variable 1Discount %
Variable 2Product
Card Count3
Card Title[1]
Card Description[2]
CTAShop Now
CTA TypeOpen URL
URL TypeDynamic Short URL
URL Variable[3_sh_code]
Domainexample.com
MediaJPG
Initiation Window10 AM–9 PM
ConsentOpt-in required

31. Final Vi RCS Whitelisting Checklist

Template

  •  Correct Agent Type

  •  Correct use case

  •  Correct template category

  •  Text finalized

  • Variables represented as [1], [2], [3]

  •  Variable mapping documented

  •  No unexpected variables

Rich Card

  •  Title finalized

  •  Description finalized

  •  Image/video finalized

  •  Correct media format

  •  CTA finalized

  •  CTA text ≤ 25 characters

  •  Maximum 4 card-level suggestions

  •  Content matches approved use case

Carousel

  •  Minimum 2 cards

  •  Maximum 10 cards

  •  Cards have consistent structure

  •  Card-level variables mapped

  •  CTA mapped for each card

  •  URLs validated

URL

  •  Static URL included directly

  •  Dynamic URL represented using variable

  •  Static/base domain whitelisted

  • Dynamic short URL uses required [n_sh_code] convention

  •  CTA URL tested

  •  Redirect tested

Marketing

  •  User has opted in

  •  Promotional classification selected

  • Initiation between 10 AM–9 PM

  • Maximum 4 A2P promotional messages/user/month/brand

  •  Content is not misleading

  •  Offer details are accurate

Transactional

  •  Message relates to an actual customer/service event

  •  No unnecessary promotional content

  •  Variables correspond to the actual transaction

  •  CTA leads to the relevant service/action

OTP

  •  OTP/authentication purpose only

  •  OTP variable correctly mapped

  •  Validity period included where appropriate

  •  No promotional content

Compliance

  •  Opt-in available

  •  Applicable opt-out process available

  •  No spam/aggressive messaging

  •  No prohibited content

  •  Applicable Indian regulations followed

  •  Privacy policy/terms available where required


One important distinction

There are two layers of rules here:

  1. Vi-specific whitelisting/business rules — e.g. promotional initiation hours, promotional message limits, approval process and the [n_sh_code] convention you provided.

  2. Google RCS technical capabilities/limits — e.g. rich-card limits, carousel 2–10 cards, 200-character titles, 2,000-character descriptions, 25-character suggestions, media specifications, etc. (Virbm)

The Vi portal's current validation behavior should take precedence if it differs from the generic Google RCS specification, because Vi states that its RBM policies can be refined/modified. (Virbm)

Vi RBM Policies
Google RCS Rich Cards specifications
Google RCS message/suggestion specifications