Sending rules and limits
RCS is a carrier channel, and the carrier sets rules that Splashify cannot waive. Most of them only bite on promotional traffic, but when one does, it surfaces as a send failure with a terse code. This page is what those codes mean.
Read this before your first promotional campaign
Three of the rules below have no equivalent in SMS or email, and every one of them has surprised somebody: promotional messages are capped per recipient per month, they can only be sent between 7am and 10pm, and the cap moves up or down with a reputation score you do not control directly. None of them apply to transactional or OTP traffic.
Content that is not allowed
Four business categories cannot be sent over RCS in India at all. This is not an allowance you can raise, and unlike everything else on this page it is not limited to promotional traffic. Opt-in does not change it either. The content itself is refused.
A bot applied for in one of these categories is rejected at registration. Sending the content on a bot that is already approved is the worse outcome: it is treated as misrepresenting the sender, and it suspends the bot. A suspension takes down everything else that bot sends, including OTPs.
There is no version of this that works
Declaring a different use case does not help, because the carrier judges the message that reaches the handset and not the label you filed. Neither does moving the traffic to a second bot on the same account, or wording an offer as news. A message that reads as harmless but links to a landing page in one of these categories is judged on where the link goes.
If your business sits next to one of these, ask before you build
A regulated lender or a licensed operator is a different conversation from an instant-loan app, and the answer can depend on your licences and on which provider your bot is provisioned through. Confirm it with [email protected] before you design a campaign around it. Finding out at registration costs you a review cycle. Finding out after launch costs you the bot.
Rules by use case
Every bot declares a use case when you apply for it, OTP, Transactional or Promotional. That declaration is what decides which rules apply, and it is enforced by the carrier, not by us.
The Can broadcast? column is the one rule we enforce ourselves, before the send rather than after it: a bot registered OTP or Transactional cannot run a broadcast, a recurring broadcast or a retarget. Everything one-off still works. See What your bot is registered to send.
"Block & report" is the option the recipient sees inside the conversation. On an OTP bot it is hidden, because a one-time passcode is a message the user just asked for. On the other two it is always available, and a recipient using it is a stronger signal against you than an opt-out.
Do not declare a promotional bot as transactional to dodge the limits
The carrier judges the message that reaches the handset, not the label you filed. Sale copy on a transactional bot is what gets a verified sender suspended, and a suspension takes down whatever else that bot sends. If you need both kinds of traffic, run two bots. That is exactly what multi-bot accounts are for, and it also means a promotional suspension cannot stop your OTPs.
It also will not work in the other direction: a transactional bot cannot run a broadcast at all, so the label does not buy you a cheaper way to send campaigns.
The promotional time window
Promotional conversations may only be initiated between 7:00am and 10:00pm, seven days a week.
Splashify now enforces this for you. It used to be the carrier that stopped you, at send time, and the result was a wall of failures rather than a warning. Three things happen instead:
- A single send outside the window is refused with
403 outside_promotional_window, and the message names the time it can go. - A broadcast cannot be started outside the window.
- A broadcast already running at 10:00pm pauses itself and moves to
scheduledfor 7:00am the next morning. It resumes on its own with its remaining recipients intact. Nobody has to press anything, and nothing is lost.
That last one is the case that used to hurt. A 200,000-message campaign takes long enough that starting it at 9:00pm meant sending through the night, and the window was only ever checked at the moment you pressed Start.
A paused broadcast is not a failed broadcast
Its status reads scheduled with a start time of 7:00am, the same as one you had scheduled
yourself. The recipients it has not reached yet are still queued against it. It is not a partial
send you need to rebuild, and re-running it would message the earlier recipients twice.
Recurring broadcasts still need your attention
A recurring broadcast fires unattended, and a schedule set outside the window is refused every single run. Recurring broadcasts run on IST, so set the hour once and it holds, but check it, because nothing will tell you until you read the report.
The window does not apply to transactional or OTP messages. An order notification or a passcode goes out at 3am if that is when it is needed, and none of the enforcement above touches those bots.
Which rule you get follows the traffic type your bot was registered under, not the category of the template you are sending. A bot registered Promotional is inside the window even when the message looks transactional.
The promotional message cap
A promotional bot may send a limited number of messages to the same recipient per month, a rolling 28-day period, counted per bot.
The exact allowance depends on your bot's reputation score:
A new bot starts in the middle of that range. The RCS network keeps the score, based on how your messages perform and how well you follow the rules. It is not something you set, and not something Splashify can raise on request.
Replies buy you more messages
The cap counts A2P messages, the ones you initiate. It does not count P2A messages, the ones a recipient sends you.
Every time a recipient replies, you may send two additional messages beyond the cap. That is the mechanism the channel is built around: a conversation is not rationed the way a broadcast is.
This is the strongest argument for reply buttons
A message with a suggested reply that people actually tap is not just better engagement. It literally raises how many messages you are allowed to send that person. A one-way promotional blast burns the cap and earns nothing back. Adding buttons →
What hitting the cap looks like
The send fails. In the panel you will see it on the broadcast's Recipients tab, with Failed picked in its filter, as:
Monthly limit reached. This number already got the most messages allowed from this bot this month.
There is nothing to retry. Those recipients are unreachable from that bot until their 28-day window rolls over, and re-sending only produces the same failure.
A high failure count on a repeat campaign is usually this
If a promotional broadcast to a list you have used recently comes back with a large block of failures, and the same list worked a month ago, check the failure reason before assuming the list has gone stale. The cap and an unreachable number look identical in the headline count and completely different in the reason.
Protecting your reputation
You cannot set the score, but everything that moves it is under your control:
- Send to people who opted in
The single largest factor. A list bought or scraped will generate blocks and reports quickly, and the score falls faster than it recovers.
- Honour opt-outs immediately
STOP is handled automatically, so this mostly means not working around it. Opt-out list →
- Match content to the declared use case
Promotional copy on a transactional bot is the most common cause of a manual review.
- Send something worth opening
Read rate and click rate feed the score. Four relevant messages a month beat eight ignored ones, and cost less.
- Check reachability before a big send
A campaign that mostly fails is a bad signal as well as a wasted one. Reachability checks →
Billing categories
Separately from the use case, every bot carries a billing category that describes how it interacts with recipients. It is set when your bot is provisioned, and it is part of what determines your per-message price.
- Basic message
One-way messages of 160 characters or less, plain text, with no reply expected. The cheapest category. It is priced like an SMS because it does the same job.
- Single message
One-way messages that are richer than a basic message, a rich card, a carousel, or plain text over 160 characters, still with no reply expected.
- Conversational
Multi-step, two-way conversations. Billed per session rather than per message, so it is the right category for anything with auto-replies or a genuine back-and-forth.
You do not choose this in the panel
The category is agreed when your bot is provisioned and is reflected in the per-message price shown on its card under Settings → Bots. If your traffic has changed shape. You built a conversational flow on a bot provisioned for one-way notifications. That is worth a conversation with support rather than something to work around. Contact support →
Payload limits
These are hard ceilings enforced at the carrier, above and beyond the per-field limits the template validator checks:
In practice the media limits bite long before either of these, images are capped at 2 MB and video at 10 MB by the template validator, precisely because a 200 MB video is not a message anybody will wait for on mobile data.
Send rate
Each bot has a TPS (transactions per second) budget. Accounts start with a default allocation at account level, shared across every bot you run.
Broadcasts are paced to stay inside it, which is why a large send completes over minutes. Raising it is a request to support and takes a few working days. It is not a panel setting. More on TPS →
These rules come from the carrier, not from Splashify
Splashify delivers RCS through carrier partners, and the numbers above are theirs. They are consistent across the Indian RCS ecosystem, but a specific allowance can differ depending on which provider a bot is provisioned on. When a limit matters to your planning, confirm it for your bot with [email protected] rather than assuming.