RCS Templates Tab: Approval and Deliverability Per Template

The RCS channel page in the dashboard has three views behind one switcher: Messages, Templates, and Analytics. The Templates view is the per-template home — approval status, per-template deliverability, and the edit/delete actions — that the RCS channel page previously only exposed through the REST contract. This guide walks the tab end to end: how to open it, how to read each row, which states a template moves through, and where the edges are.

Walk through the tab

Open Messages → RCS. The Messages / Templates / Analytics switcher at the top of the page includes a Templates value. The active view is synced to the ?tab= query parameter, so you can deep-link directly to the roster with ?tab=templates — handy for linking row-level work from a runbook or chat.
Pick the agent. Templates are registered against a specific RCS agent (bot), so the tab scopes to one agent at a time. If your tenant has more than one agent, use the agent picker at the top of the view to switch between them; the header shows the selected agent’s registration status (for example launched or pending launch) alongside a link into the Rich Card Studio. If no agent exists yet, the tab routes you to the RCS setup flow instead of showing an empty picker.
Read each row. A template renders as a card with its approval badge, message type (rich card or carousel), and deliverability inline — Sent, Delivered, Read, and Taps counts pulled from the same template-analytics aggregation the Analytics tab uses, so the two surfaces always agree. A template with no sends yet says so explicitly instead of showing zeros.
Act on a row. Every row carries two actions: Edit in Rich Card Studio, which opens the shipped builder on that template, and Delete, which removes it after a confirmation dialog. Read Limits and edge cases before deleting anything a campaign still sends.

Template states

The approval badge on each row carries one of four states. The value comes back from the carrier review, and only an Approved template can actually be sent by a campaign.

State	What the badge means	Can campaigns send it?
Approved	The carrier accepted the template definition.	Yes.
Pending review	The definition was submitted and is waiting on the carrier.	No.
Rejected	The carrier declined the definition; the `rejection_reason` shows inline on the row.	No — fix and re-submit.
Draft	Authored but not in review yet, or the carrier reported a status outside the three above (the row shows that raw status).	No.

Every update resets approval. Editing a template — in the Rich Card Studio or through PUT /api/v1/rcs/bots/:id/templates/:name — re-submits the definition and moves it back to Pending review. A campaign that goes live while its template is mid-edit sends against a definition that is back in review. Publish template edits before a dependent campaign starts, never during it.

The lifecycle mirrors the one the RCS channel page Templates section documents; the tab exists so you can read each template’s current state at a glance instead of querying the API. The rest of this guide covers how to sequence edits, move a template through the full lifecycle, and read the signals back.

1. Lifecycle governance — sequence edits around campaign launches

A template and the campaign that sends it have separate lifecycles, but they intersect everywhere that matters: editing the template re-submits the definition and resets approval to Pending review, so a campaign that goes live mid-edit can fail against a definition it did not vote for. Sequence template work so approval never resets during a launch window. The pattern that holds up: freeze before launch, land edits between launches.

Situation	What to do
Campaign is about to launch (minutes/hours away)	Freeze the template. Do not touch it until the campaign is live and sending.
Campaign is live and sending	Treat the template as read-only. Batch any edit you have in mind until after the campaign drains.
The carrier asked for a fix (rejected)	Do not rush the fix into the next launch. Land it in a review window between launches.

Pre-launch template checklist. Before a dependent campaign goes live:

The template’s badge is Approved — not Pending review, Rejected, or Draft.
If you edited it since your last approved send, allow at least one carrier review window — the tab shows the badge, but the carrier review is asynchronous.
The send path agrees with the template: your campaign references the template name exactly as it appears in the roster (name is the key for reads, updates, and sends).
The fallback is reachable — the chain lives on the organization under settings.cross_channel_fallback (see RCS channel page); the template send does not accept a fallback field.

Once a campaign is live, do not open the template in the Rich Card Studio’s edit mode by accident — the Studio saves and re-submits on save, so an exploratory session becomes a Pending review reset.

2. Author and submit end to end

The Rich Card Studio builds the definition visually and is the fastest path for a single template; use PUT /api/v1/rcs/bots/:id/templates/:name (or POST /api/v1/rcs/bots/:id/templates to create) when the flow is programmatic — a template rendered by your build, or an update that lands from CI. The shape is the same either way: a single rich card or carousel under rich_template_data, validated on submission (deepLink/fallbackUrl pairs are rejected with a 422 before the definition reaches the RCS platform).

Create

cURL

curl -X POST https://api.orbit.devotel.io/api/v1/rcs/bots/bot_abc/templates \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rich_template_data": {
      "name": "order-update",
      "title": "Your order has shipped",
      "body": "Track your package — expected delivery {{delivery_date}}.",
      "actions": [
        {
          "type": "open_url",
          "label": "Track it",
          "deepLink": "orbitshop://order/{{order_id}}",
          "fallbackUrl": "https://orbit.shop/track/{{order_id}}"
        }
      ]
    }
  }'

The response returns 201 with the submission result. The template is stored as pending and the badge in the Templates tab shows Pending review — a campaign still cannot send it.

Update (replace, not merge)

A PUT replaces the whole definition — there is no field-level merge. Send the complete rich_template_data, keep the same name, and let approval reset:

cURL

curl -X PUT https://api.orbit.devotel.io/api/v1/rcs/bots/bot_abc/templates/order-update \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "rich_template_data": {
      "name": "order-update",
      "title": "Your order has shipped",
      "body": "Track your package — expected delivery {{delivery_date}}. Tap to see the map.",
      "actions": [
        {
          "type": "open_url",
          "label": "Track it",
          "deepLink": "orbitshop://order/{{order_id}}",
          "fallbackUrl": "https://orbit.shop/track/{{order_id}}"
        }
      ]
    }
  }'

The template flips back to Pending review. Do not launch a dependent campaign against it until the badge returns to Approved.

Send

Once approved, a campaign references the template by name on POST /api/v1/messages/rcs — see RCS channel page. The inline counters on the row (Sent, Delivered, Read, Taps) accumulate as long as the definition stays put.

Read back

GET /api/v1/rcs/bots/:id/templates/:name returns the stored definition plus the current approval status — use it to preview before sending or to compare the live definition against the one you are about to publish.

3. Versioning and rollback signals

Orbit does not version templates internally — the definition is a single row under a name, and PUT replaces it. Version discipline lives in how you read the Analytics counters against the edit history you keep. The tab’s per-template counters (Sent, Delivered, Read, Taps) come from the same aggregation the Analytics tab and the template analytics endpoint use, so the rollup and the row agree. Use that to map dips to a specific edit:

After a UI-visible edit (Studio or PUT), snapshot the row’s counts. If deliverability drops sharply on the next sends, the last edit is the first suspect — not the campaign.
Rollback is re-publish. There is no revert button; to back out an edit, PUT the previous definition back under the same name so the carrier reviews the old card again. Keep the prior body under version control so the rollback is a re-publish, not a rewrite.
For automation, read GET /api/v1/templates/{id}/analytics from the template analytics guide and compare delivery_rate before and after an edit window.

Treat the counters as the version signal: they only move when sends move, and they only drop when the definition changed.

4. Common carrier rejections

A Rejected badge carries the rejection_reason inline on the row — the carrier’s own words. The most common reasons and how to re-submit:

Rejection reason (typical patterns)	What it means	Re-submit
Missing or unreachable link	A `deepLink` / `fallbackUrl` pair was malformed or the fallback URL is not HTTPS-reachable.	Fix the URL in the Studio or in the payload; re-submit.
Unclear opt-out or missing sender identity	The card’s body or sender profile lacks required identity/disclosure.	Add the missing disclosure; re-submit.
Unsupported content type	A media tier or rich-link action the carrier does not support for this agent/profile.	Downgrade the interaction (e.g. open_url instead of deep link); re-submit.
Prohibited content	Copy violates the carrier’s content policy.	Rewrite; re-submit.

Fix the reason, then re-submit with PUT (same name — approval resets to Pending review, the badge clears, and the campaign can go live again once the carrier returns Approved).

5. Cross-reference: the RCS Analytics tab

The counters shown here are a window onto the analytics surface. For a template-level faucet across every campaign — delivery rate, open rate, click rate, per-campaign funnels — see template analytics. Use the tab for “what is happening right now” and the analytics endpoint for the cross-campaign rollup.

Limits and edge cases

Constraint	Where it bites
The tab requires an existing RCS agent.	Without a bot it shows a setup CTA, not an empty roster — complete RCS onboarding first.
The roster is scoped per agent.	Tenants with several agents switch between them in the picker; one agent’s templates never appear in another agent’s list.
Editing resets approval to Pending review (see the state table).	Re-approval is a carrier round-trip, so plan a review window between an edit and a campaign launch.
Delete is destructive for live traffic.	Deleting removes the template from the carrier directory, so any campaign or flow still sending it starts failing. Check campaign references before you confirm.
Deliverability appears only after sends.	Until a template has traffic, the row says there are no sends yet — empty counters are not a malfunction.

Troubleshooting

Symptom	Why it happens	Fix
Skeleton rows that never resolve	The agent list is still resolving.	Wait a moment; if nothing settles, refresh the page.
”Couldn’t load RCS templates. Try again.” with a Retry button	The agent list, template roster, or per-template counters came back failed.	Click Retry — it re-requests the template roster and the agent roster together, so a failed agent list recovers fully instead of retrying the templates call against a still-broken roster.
”Templates didn’t load” inside the header card	Only the template store call failed.	Click Retry on that card; the handler re-fires both queries.
”No RCS agent yet”	No bot is registered on your tenant.	Complete the RCS onboarding flow, then return.
”No templates on this agent”	Templates live under a different agent, or none exist yet.	Switch agents in the picker, or click Open Rich Card Studio to author the first one.
The agent badge shows `pending launch` or `provisioning`	The agent has not finished carrier registration.	Templates queue but cannot send until the agent reports `launched` — finish launch in onboarding.
A row shows “No sends with this template yet”	No traffic has used the template.	Send once (a campaign, a flow, or a test) and the counters appear.

RCS channel page — message shapes, the template REST contract, and the template-analytics endpoint the tab visualizes.
RCS onboarding guide — brand, agent, verification, and launch; the path to reach-sizing before your first campaign.
Template analytics — cross-campaign per-template rollup with delivery/open/click rates.

WhatsApp

Developer console

Contact center

Guides

Messaging Controls

Audience & Support Tools

RCS Templates tab: approval, deliverability, and lifecycle

RCS Templates Tab: Approval and Deliverability Per Template

Walk through the tab

Template states

1. Lifecycle governance — sequence edits around campaign launches

2. Author and submit end to end

Create

Update (replace, not merge)

Send

Read back

3. Versioning and rollback signals

4. Common carrier rejections

5. Cross-reference: the RCS Analytics tab

Limits and edge cases

Troubleshooting

​RCS Templates Tab: Approval and Deliverability Per Template

​Walk through the tab

​Template states

​1. Lifecycle governance — sequence edits around campaign launches

​2. Author and submit end to end

​Create

​Update (replace, not merge)

​Send

​Read back

​3. Versioning and rollback signals

​4. Common carrier rejections

​5. Cross-reference: the RCS Analytics tab

​Limits and edge cases

​Troubleshooting

​Related

RCS Templates Tab: Approval and Deliverability Per Template

Walk through the tab

Template states

1. Lifecycle governance — sequence edits around campaign launches

2. Author and submit end to end

Create

Update (replace, not merge)

Send

Read back

3. Versioning and rollback signals

4. Common carrier rejections

5. Cross-reference: the RCS Analytics tab

Limits and edge cases

Troubleshooting

Related