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 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.
The API or workflow accepted it, but the phone shows nothing
Fetch the message with the quickstart's read request, or locate it in the channel's message logs by recipient and time. Inspect its status, reason and failure. The status reference 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 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, 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 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 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.
Related resources
Continue with the documentation, guides and examples for this topic. Resources are in English.