Why RCS API Rate Limits Matter for Your Business in 2026

You've built your RCS automation. Your brand is verified. Your message templates are approved. Your campaign is ready to fire. You hit send — and within minutes, your API returns a flood of HTTP 429 errors. Messages stop delivering. Worse: your RCS agent account gets flagged or suspended. Your entire campaign grinds to a halt.

This is the rate limit problem — and it catches more businesses off guard than any other technical challenge in RCS deployment. Unlike WhatsApp, which has well-documented per-conversation pricing limits, RCS Business API (RBM) rate limits are managed across multiple layers: Google's RBM platform, your BSP, carrier-level throttling, and India's TRAI regulatory windows. Each layer has its own rules. Violating any of them can lead to message failures, account flags, or permanent suspension.

This complete guide explains exactly what RCS API rate limits are, where they come from, what happens when you exceed them, and — most importantly — the 10 proven strategies to prevent account blocking so your campaigns run cleanly, at scale, every time.

RCS API Rate Limits — 2026 Key Facts

What Are RCS API Rate Limits — Explained Simply

A rate limit is a cap on how many API requests or messages you can send within a defined time window. When you exceed this cap, the API returns an HTTP 429 error — 'Too Many Requests' — and your message is rejected until the window resets or you implement a delay.

For RCS Business API, rate limits operate at multiple levels simultaneously. Understanding each layer is critical — because exceeding any one of them triggers failures even if you are within the limits of the others.

Layer 1 — Google RBM Platform Limits

Google's RCS for Business platform (RBM API) sets the base rate limits for all agents. These limits apply per RCS agent (your verified brand sender) and are defined in terms of messages per second or requests per minute. Google does not publish a single universal rate limit — limits scale with your agent's verified status, usage history, and BSP tier.

•         New agents start with conservative limits — typically 10–30 messages per second

•         Established agents with clean history can request higher throughput limits

•         All requests return HTTP 429 when platform limits are exceeded

•         Google's RBM platform automatically retries undelivered messages for up to 30 days

•         Set message expiration for time-sensitive content (OTPs, flash sale offers) to stop stale delivery

Layer 2 — BSP (Business Solution Provider) Limits

Your BSP — Gupshup, Kaleyra, Route Mobile, Tanla, Infobip, or others — applies its own rate limits on top of Google's platform limits. These limits are set per account tier, volume contract, and use case. BSP limits are often stricter than Google's platform limits for new accounts.

•         Starter accounts: typically 5–15 messages per second

•         Growth accounts: 50–200 messages per second

•         Enterprise accounts: 500–1,000+ messages per second (negotiated)

•         BSP limits vary by message type: transactional vs promotional vs conversational

•         Contact your BSP to understand your exact current throughput limit and how to increase it

Layer 3 — Carrier-Level Throttling (Jio, Airtel, Vi)

In India, individual telecom carriers — Jio, Airtel, and Vi — apply their own throttling rules on RCS message delivery. These carrier-level limits are separate from your BSP limits and are not always publicly documented. They are particularly relevant for high-volume campaigns.

•         Carriers throttle burst traffic to protect network infrastructure

•         Festival season campaigns (Diwali, Holi) may face increased carrier throttling during peak hours

•         Carrier throttling does NOT trigger HTTP 429 at the API level — messages are delayed, not rejected

•         Your BSP should manage carrier-level pacing automatically — verify this before launch

•         Spreading campaign sends over 2–4 hours reduces carrier throttling significantly

Layer 4 — TRAI Regulatory Windows (India Specific)

India's Telecom Regulatory Authority (TRAI) mandates specific time windows for commercial messaging. Promotional RCS messages sent outside these windows are blocked at the carrier level — regardless of your API rate limits.

•         Promotional RCS messages: permitted ONLY between 9:00 AM and 9:00 PM (IST)

•         Transactional RCS messages (OTP, order confirmation): allowed 24/7

•         Service messages (account alerts, appointment reminders): allowed 24/7

•         TRAI DND registry: customers registered on DND must be excluded from all promotional sends

•         TRAI violations result in carrier-level blocking — not just message failure

Understanding HTTP 429 Error — The RCS Rate Limit Error

When your RCS API requests exceed the allowed rate, the server returns:

The Retry-After header tells you exactly how many seconds to wait before retrying. Always read and respect this header — retrying immediately after a 429 will trigger another 429 and can escalate to a temporary account block.

What to Do When You Get HTTP 429

•         STOP retrying immediately — do not loop or retry without a delay

•         Read the Retry-After header value — wait exactly this many seconds before next attempt

•         If no Retry-After header: implement exponential backoff (see Section 5)

•         Log all 429 errors with timestamp and request volume — identify the pattern

•         Alert your engineering team if 429 errors exceed 5% of total requests — reduce send rate

•         Never use a different API key to bypass the 429 — this violates BSP terms and triggers suspension 

10 Proven Strategies to Prevent RCS Account Blocking

1. Implement Exponential Backoff — The Right Way to Handle 429 Errors

Exponential backoff is the gold-standard strategy for handling rate limit errors. Instead of retrying immediately (which makes the problem worse), you wait progressively longer between each retry attempt.

•         Retry 1: Wait 1 second, then retry

•         Retry 2: Wait 2 seconds, then retry

•         Retry 3: Wait 4 seconds, then retry

•         Retry 4: Wait 8 seconds, then retry

•         Retry 5: Wait 16 seconds — if still failing, pause and alert engineering

2. Use a Message Queue — Never Send Directly From Application Code

The single most effective architectural decision you can make for RCS at scale is using a message queue (RabbitMQ, AWS SQS, Redis Queue, or Google Pub/Sub) between your application and the RCS API. The queue controls throughput, absorbs spikes, and retries failed messages automatically.

•         Application pushes messages to queue — not directly to RCS API

•         Queue worker dequeues at a controlled rate — e.g., 20 messages per second

•         On 429: message goes back to queue with backoff delay — no message lost

•         Queue gives you visibility: how many messages pending, processing, and failed

•         Horizontal scaling: multiple queue workers — each respecting rate limits independently

3. Spread Campaign Sends — Never Blast All at Once

The most common cause of RCS account blocking is a campaign blast — sending hundreds of thousands of messages simultaneously. Even if your per-second rate limit is high, sudden burst traffic triggers carrier throttling, BSP flags, and Google agent suspicion.

•         For campaigns over 10,000 messages: spread the send over 2–4 hours minimum

•         For campaigns over 100,000 messages: spread over 6–12 hours

•         Schedule festival campaigns to start at 9:00 AM IST — not all at once at midnight

•         Use your BSP's campaign scheduler — most support rate-limited batch sending natively

•         Monitor delivery rates in real time — if delivery drops, pause and investigate

4. Respect TRAI Time Windows — No Promotional Messages Outside 9 AM–9 PM

India's TRAI mandates that promotional messages can only be sent between 9:00 AM and 9:00 PM IST. Sending promotional RCS messages outside this window causes carrier-level blocking — and repeated violations can result in your RCS agent being permanently blacklisted by Indian carriers.

•         Hard-code a time-check in your campaign scheduler: block any promotional send before 9 AM or after 9 PM IST

•         Set your BSP platform to automatically queue and hold messages until 9 AM if triggered early

•         Transactional messages (OTP, order confirmation, delivery alert) are exempt — allowed 24/7

•         When in doubt about message type: classify as promotional and apply the 9 AM–9 PM rule

•         Review TRAI DND registry monthly — always exclude DND numbers from promotional sends

5. Monitor and Respect Retry-After Headers

Every HTTP 429 response from the RCS API includes (or should include) a Retry-After header specifying exactly how long to wait. Respecting this header is not optional — it is the API's direct instruction on when to safely retry.

•         Parse the Retry-After value from every 429 response before any retry logic

•         If Retry-After is absent: default to exponential backoff starting at 2 seconds

•         Store the Retry-After timestamp — ensure all retry workers respect it, not just the current request

•         Alert on Retry-After values over 60 seconds — this indicates serious throttling

•         Log Retry-After values over time — a pattern of increasing values signals your send rate is consistently too high

6. Set Message Expiration for Time-Sensitive Content

Google's RBM platform will attempt to deliver undelivered messages for up to 30 days. For time-sensitive content — flash sale offers, OTPs, appointment reminders — this means customers can receive an expired offer days later. Worse: the retried delivery counts against your rate limits when you are already under pressure.

•         Set expiration on all promotional messages: 4–12 hours maximum

•         Set expiration on OTP messages: 5–10 minutes (OTPs are invalid after this anyway)

•         Set expiration on festival sale messages: duration of the sale (e.g., 24 hours for Diwali sale)

•         Set expiration on appointment reminders: 1 hour before appointment time

•         Messages that expire cleanly free up your delivery queue — preventing backlog buildup

7. Use Batch Endpoints — Reduce API Calls by 10–50x

Sending individual API calls for each message is the most rate-limit-intensive approach possible. Many BSPs provide batch endpoints that allow you to submit 10–1,000 messages in a single API call — dramatically reducing your per-message API overhead and rate limit consumption.

•         Check your BSP documentation for batch message submission endpoints

•         Batch size: start with 50 messages per API call — increase based on 429 frequency

•         Batching reduces API calls by 50x — 50,000 messages in 1,000 API calls vs 50,000 individual calls

•         Each batch call is atomic — if it fails, all messages in the batch retry together

•         Combine batching with queue architecture for maximum throughput and reliability

8. Manage Opt-Outs Rigorously — The #1 Account Blocking Trigger

The most common cause of RCS account blocking is NOT technical — it is sending messages to users who have opted out. High spam complaint rates and opt-out violations trigger both carrier-level blocks and Google RBM agent suspension. Managing opt-outs rigorously is not just good practice — it is an account survival requirement.

•         Process opt-out requests within 24 hours — remove from all send lists immediately

•         Include opt-out instruction in every promotional RCS message: 'Reply STOP to unsubscribe'

•         Maintain a centralised DND/opt-out registry — sync across all messaging channels

•         Never re-add an opted-out contact without explicit new opt-in

•         Audit your contact lists monthly — remove contacts who haven't engaged in 6+ months

9. Monitor Rate Limit Headers Proactively — Before You Hit the Wall

Every RCS API response includes rate limit information in the response headers — not just when you exceed them. Proactive monitoring of these headers allows you to slow down BEFORE hitting the 429 error, keeping your campaign running smoothly at all times.

•         Monitor X-RateLimit-Remaining header: remaining requests in current window

•         Monitor X-RateLimit-Reset header: timestamp when the rate limit window resets

•         Alert engineering when remaining requests drop below 20% of quota

•         Auto-reduce send rate when remaining drops below 10% — preventive throttling

•         Build a real-time dashboard showing: requests/second, 429 rate, remaining quota, delivery rate

10. Request Rate Limit Increases Proactively — Not During a Crisis

If your business needs higher throughput than your current rate limits allow — for example, before a major Diwali campaign — the right approach is to request a limit increase from your BSP or Google BEFORE the campaign, not after you start hitting 429 errors during the send.

•         Contact your BSP account manager 2–3 weeks before any major campaign

•         Provide projected campaign volume: total messages, send window, messages per hour

•         Share your clean account history: low spam rate, zero TRAI violations, consistent opt-out compliance

•         BSPs and Google grant limit increases based on account health and business case — good history is essential

•         After limit increase: test at new rate with a small batch before full campaign launch

RCS API Rate Limits — Complete Reference Table 2026

Step-by-Step: Safe High-Volume RCS Sending Setup

Follow this 5-step technical setup to send RCS campaigns at scale without hitting rate limits or triggering account blocks.

7 Common Mistakes That Lead to RCS Account Blocking

Frequently Asked Questions — RCS API Rate Limits

Q1: What is the exact RCS API rate limit per second in India?

Google does not publish a single universal rate limit for the RCS for Business (RBM) API — limits are set per agent based on verification status, account history, and BSP tier. New agents typically start at 10–30 messages per second. Established agents with clean sending history can request higher limits — up to 500–1,000+ messages per second for enterprise accounts. Contact your BSP to confirm your current limit and request an increase before any major campaign.

Q2: What happens if I send RCS messages outside 9 AM–9 PM in India?

Promotional RCS messages sent outside the 9:00 AM – 9:00 PM IST window (mandated by TRAI) are blocked at the carrier level. The message is not delivered, and no API error is returned to your application — the message silently fails at the carrier. Repeated TRAI timing violations can result in your sender ID being blacklisted by Indian carriers (Jio, Airtel, Vi), making all future RCS messages from your brand non-deliverable.

Q3: How do I fix an HTTP 429 error in my RCS API integration?

When you receive an HTTP 429: (1) Stop retrying immediately, (2) Read the Retry-After response header and wait that number of seconds, (3) If no Retry-After header, implement exponential backoff starting at 1 second (double each retry: 1 → 2 → 4 → 8 → 16 seconds), (4) Add 0–1 second random jitter to prevent concurrent processes from retrying simultaneously, (5) Log all 429 errors with timestamps and volumes to identify the root cause, (6) If 429s persist, reduce your overall send rate or contact your BSP to increase your limit.

Q4: Can I use multiple RCS API keys to send more messages and avoid rate limits?

No — this is explicitly prohibited. Most BSPs and Google's RBM policies forbid using multiple API keys to circumvent rate limits. Detection results in immediate account suspension — not just continued throttling. The correct approach is to request a legitimate rate limit increase from your BSP by providing your campaign requirements, projected volume, and clean account history.

Q5: What triggers RCS account blocking — and can it be reversed?

RCS account blocking is typically triggered by: spam complaint rate above 0.3–0.5%, sending to opted-out contacts, TRAI timing violations, or repeated rate limit violations. Minor violations result in temporary throttling. Serious or repeated violations result in agent suspension. Account restoration requires submitting a formal appeal to your BSP with documentation of corrective actions taken. Prevention is significantly easier than recovery — a single suspension can take 2–6 weeks to resolve.

Q6: Does RCS have different rate limits for transactional vs promotional messages?

Rate limits are generally applied at the API level (per second/minute), not per message type. However, message classification (transactional vs promotional vs service) affects TRAI timing compliance, carrier routing, and BSP policy — not the raw API rate limit. Transactional messages can be sent 24/7, while promotional messages are restricted to 9 AM–9 PM IST. Your BSP may also have different throughput SLAs for transactional vs promotional traffic — verify this with your account manager.

Q7: How do I calculate the right message queue rate for my RCS campaigns?

Formula: Safe Send Rate = (Your BSP Rate Limit in msg/second) x 0.75. The 0.75 factor (75% of limit) provides headroom for carrier throttling, occasional spikes, and burst traffic without hitting the 429 threshold. Example: if your BSP limit is 100 msg/second, configure your queue worker to dequeue at 75 msg/second maximum. For festival campaigns, use 60% of your limit to account for increased carrier throttling during peak periods.

Q8: Should I enable SMS fallback and does it count against RCS rate limits?

Yes — always enable SMS fallback. When an RCS message cannot be delivered (device not RCS-capable, network issue, or recipient offline), SMS fallback ensures the customer still receives the message. SMS fallback messages are delivered via your SMS API — they do not count against your RCS API rate limits. They are billed separately as standard SMS messages. Confirm with your BSP that automatic fallback is active before any campaign launch.

RCS Rate Limit Quick Reference Card

Conclusion

RCS API rate limits are not obstacles — they are guardrails. They exist to protect carrier infrastructure, ensure fair access across all businesses, and prevent spam abuse that would degrade the channel for everyone. Understanding and working within these limits — rather than trying to bypass them — is what separates professional RCS implementations from amateur ones.

The 10 strategies in this guide — from exponential backoff and message queues to TRAI compliance and proactive monitoring — give you everything you need to send RCS campaigns at any volume without hitting rate limits or risking account blocking. Implement them before your first major campaign, not after your first suspension.

Maintain your account health consistently. Honour opt-outs immediately. Respect TRAI windows. Monitor your 429 rate proactively. Request rate limit increases well in advance. Do these things, and your RCS channel will be a reliable, high-performance asset for your business for years to come.