RCS Panel API

Everything the panel at rcs.splashifypro.com can do, as a REST API. Register bots, design templates, upload audiences, run broadcasts, recharge the wallet, and pull stats.

The RCS Panel API is the programmatic surface for RCS-only customers, the accounts created at rcs.splashifypro.com. It is separate from Splashify's partner API and app-panel API: different credentials, different routes, different data. A token issued here works only here.

Base URL:  https://api.splashifypro.com
Routes:    /api/v1/rcs/*
Auth:      Authorization: Bearer <jwt-or-rcs_pk_live_key>

Looking for the panel instead?

If you are here to use the product rather than integrate it, the user manual walks the same capabilities screen by screen, with no code.

Conventions

The API is JSON over HTTPS. There are no XML, form-encoded or GraphQL surfaces.

Content type: Send Content-Type: application/json on every request with a body. File uploads to POST /rcs/apply/upload are the one exception and use multipart/form-data.
Success flag: Every response, success or failure, carries a boolean success. Branch on that rather than on the HTTP status alone; the two always agree, but success is the one that is present in every payload.
Identifiers: All ids (bot_id, template_id, broadcast_id, list_id, member_id, key_id) are UUID strings. Treat them as opaque, do not parse or sort by them.
Timestamps: ISO-8601, always UTC, always with the Z suffix: 2026-07-16T18:07:52Z. The one place local time appears is recurring-broadcast scheduling, which runs in IST and says so explicitly.
Phone numbers: E.164 with the country code and a leading +, +919876543210. A number without the +, or with spaces or dashes, is rejected by the validator rather than normalised.
Money: Rupees, as a decimal number (0.35), not paise and not a string. Wallet balances and per-message prices use the same representation.

Multiple bots per account

One account can operate several bots. Each a separately-verified RCS sender with its own KYC, its own carrier-side identity and its own send-rate budget. The wallet is shared: every bot debits the same balance.

Most write endpoints therefore take a bot_id. For clients written before multi-bot support, GET /rcs/me returns default_bot_id and omitting bot_id falls back to it, but new integrations should always pass the id explicitly.

Bots reference

Applying for a bot, listing them, and what each status means.

Roles

Every account has an owner, the email that signed up. The owner can invite other emails as operators (send and edit) or viewers (read-only), each scoped to a subset of the account's bots.

Role	Can do	Cannot do
Owner	Everything, on every bot.	,
Operator	Send, broadcast, edit templates and lists, on assigned bots only. Read stats and reports for those bots.	Billing, invoices, wallet, team management, applying for a bot, editing bot credentials.
Viewer	Read broadcasts, templates, contacts, stats and reports, assigned bots only.	Any mutation. Anything owner-only.

Three distinct 403s tell you which gate you hit:

`code`	Meaning
`not_owner`	The route is owner-only and the caller is an operator or viewer.
`not_operator`	The route mutates something and the caller is a viewer.
`bot_not_assigned`	The caller's role is fine, but this bot is outside their scope.

A valid token is not the same as a permitted one

The most common integration surprise on this API is a perfectly valid operator JWT getting a 403 from /rcs/wallet or /rcs/invoices. Authentication and authorisation are separate gates, check the code field before assuming the credential is broken.

Read paths do not 403 on scope. Listing broadcasts as an operator returns the broadcasts for that operator's bots, filtered server-side, rather than an error.

Team reference

Invites, the accept flow, role changes, and the multi-account login switcher.

Account status gates

Some endpoints stay closed until the account is provisioned, or reopen only when a suspension is lifted.

Status	Meaning	Effect
`pending`	Signed up, no bot provisioned yet	Sending blocked
`active`	At least one bot live	Full access
`suspend`	Account suspended	New sends blocked; everything else stays readable

A suspension is deliberately narrow. Only broadcast creation and one-off sends are blocked, templates, contact lists, invoices and past broadcasts all stay accessible, so you can keep reconciling while it is resolved.

{
  "success": false,
  "code":    "account_suspended",
  "message": "Account suspended. <reason>. Reply to your suspension email to discuss."
}

GET /rcs/me returns the live status and suspend_reason, so a dashboard can render the banner without waiting for a send to fail.

Sending additionally requires the wallet to cover the first message, a prepaid account at zero balance is active but cannot start a broadcast.

Response shapes

A simple error is two fields:

{ "success": false, "message": "human-readable explanation" }

An RCS gateway failure carries more, because there is usually something the caller should do about it:

{
  "success":   false,
  "message":   "Recipient has opted out of RCS",
  "detail":    "Remove them from the list, don't retry.",
  "category":  "recipient",
  "retryable": false
}

category is one of content, media, recipient, config, quota or gateway. retryable: true means the platform will retry on its own, do not build a second retry loop on top of it.

Validator failures on template creation return every problem at once, so a UI can highlight them all in one pass rather than making the user resubmit six times:

{
  "success":  false,
  "message":  "Template violates RCS limits. Fix the issues below and resubmit",
  "errors":   ["Carousel card 3: title is 217 characters, max 200"],
  "warnings": ["Rich card: 3 buttons. We recommend ≤ 2"]
}

errors block the request; warnings do not.

HTTP status codes

Code	Meaning
`200`	Success
`400`	Bad request, invalid body, missing field, or validator rejection
`401`	Missing, expired or invalid JWT / API key
`403`	Role, account-state or wallet gate failed, read `code` for which
`404`	Not found, or not owned by you (the two are deliberately indistinguishable)
`409`	Conflict, duplicate name, or an action that is already in progress
`429`	Rate limit exceeded, see `Retry-After`
`502`	RCS gateway rejection, with a friendly title and resolution hint
`500`	Server error, send us the response body

Errors reference

Every gateway error code mapped to a title, a cause and a fix.

Where to next

Authentication

JWT versus API key, scopes, rate limits, and how to rotate without downtime.

Templates

Create messages, poll the review verdict, and the full validator rule set.

Broadcasts

Schedule, start, cancel, and read per-recipient delivery.

Webhooks

Receive delivery, read, click and reply events at your own URL.

RCS Panel API

Conventions#

Multiple bots per account#

Roles#

Account status gates#

Response shapes#

HTTP status codes#

Where to next#