# Troubleshoot RCS delivery and rendering

Start with one message ID and your test recipient. Keep channel delivery, a navigator's overall result, and the customer's application action separate so each check answers the right question.

## The message is not sent

Check the HTTP status and response body before looking for a delivery receipt. The [RCS Channels API](/docs/engagement-platform/api/channels-api/supported-channels/programmable-rcs/sending-messages) uses `https://api.bird.com`, `Authorization: AccessKey …`, and a workspace/channel path. Verify the key's permissions and that both IDs belong to your installed agent.

Send either `body` or `template` on a direct-channel request. A single card uses a `carousel` body with one item. A template needs the published project/version/locale and its declared parameter values. A template publication problem does not explain a request that sends an inline `body`.

For test traffic, check that the device accepted the agent's invitation. For customer traffic, inspect the configured launch countries and carriers. Follow [agent testing and launch](/docs/engagement-platform/guides/channels/channels/supported-channels/google-rcs/testing-and-launching-your-agent).

## The API or workflow accepted it, but the phone shows nothing

Fetch the message with the [quickstart's read request](/docs/get-started/send-your-first-rcs-message#4-inspect-the-result), or locate it in the channel's message logs by recipient and time. Inspect its `status`, `reason` and `failure`. The [status reference](/docs/engagement-platform/api/channels-api/message-status-and-interactions) distinguishes the sending stages:

| Result                    | What it establishes                             | Next check                                                  |
| ------------------------- | ----------------------------------------------- | ----------------------------------------------------------- |
| `accepted` / `processing` | Bird has accepted or is processing the message. | Continue tracking this attempt.                             |
| `sent`                    | Handoff to the downstream platform.             | Wait for the reported delivery outcome.                     |
| `sending_failed`          | Sending failed before successful handoff.       | Read the failure code and sender/content configuration.     |
| `delivered`               | Reported delivery to the destination.           | Check handset rendering and application actions separately. |
| `delivery_failed`         | The downstream delivery failed.                 | Inspect reach, launch scope and the failure details.        |
| `read` interaction        | A read indication was reported for the message. | It is not a message status or proof of a booking.           |
| `clicked` interaction     | A supported button interaction was reported.    | Inspect its payload and your application handler.           |

Use the [failure-code reference](/docs/engagement-platform/api/channels-api/message-status-and-interactions/message-failure-codes) for the exact error. An unsupported destination is not proof that every feature is absent from that phone; check the agent's network launch as well.

For a [navigator send](/docs/guides/rcs/capability-and-fallback), read the navigator message and `navigatorData.attempts`. An RCS leg can fail while the chain succeeds over SMS. Monitor `navigator.outbound` for the complete outcome. Do not create a second fallback send while the navigator is still working.

## The card looks wrong

Compare the submitted body or resolved template against the actual phone. Check image accessibility, crop, long text and action labels. Use the editor's [cross-platform previews](/docs/engagement-platform/guides/channels/channels/supported-channels/google-rcs/rcs-cross-platform-optimization) for Android and iOS when creating templates, then test representative handsets.

A published template and an inline message are distinct content sources. Confirm which was sent before updating a template that the request never referenced. Keep the exact request, template version if used, message ID and a screenshot for a repeatable rendering problem.

## The button does not finish the task

For a URL action, open the destination directly and inspect login redirects, expired links and the booking record. For a postback, check `metadata.button.payload` on the click interaction, or `body.text.actions[].postback.payload` on the inbound message. Match the stable payload to the saved task; button position and visible translated text are not a durable action identity.

If a reply appears in channel messages but never reaches your handler, inspect the `rcs-google.inbound` subscription, its channel filter and webhook delivery logs. Verify signatures using the original URL and raw body. A navigator's outbound subscription does not subscribe you to incoming replies.

Run the [reply processing example](/docs/guides/rcs/rich-messages#choose-an-action-or-a-reply) twice with the same input and check that one task remains. Then test a second distinct click, an unknown payload and an already changed appointment. Confirm the handler's business outcome in your application, separately from the interaction receipt.

## Information to include when asking for help

Provide the workspace and agent/channel references, message ID, timestamp with time zone, device and messaging app, HTTP response or failure code, and expected result. For navigator sends include its ID, message ID and attempt list. For reply problems include the inbound message or interaction ID and webhook request reference. Remove access keys and unrelated personal content.

[Return to RCS resources](/rcs/resources).

## Related resources

- [What Is RCS for Business?](/explained/rcs/what-is-rcs-messaging) (answer)
- [RCS](/rcs-business-messaging) (product)

[Get an implementation brief](/learn/workspace?topic=rcs)