# RCS messaging Rich Communication Services (RCS) for business in AWS End User Messaging lets you send verified, branded text messages to recipients in the United States and Canada. RCS is the next evolution of SMS — not a separate channel. RCS messages are delivered to the same native messaging app that recipients already use for SMS, making it an in-place upgrade rather than a new app to install. Verified brand identities inspire trust, encourage conversations, and drive better business results. When RCS delivery is not possible, AWS End User Messaging can automatically fall back to SMS. **Topics** + [ # What is RCS? ](rcs-overview.md) + [ # Getting started with RCS ](rcs-getting-started.md) + [ # Managing RCS agents ](rcs-agents.md) + [ # Testing RCS messages ](rcs-testing.md) + [ # RCS to SMS fallback using phone pools ](rcs-sms-fallback.md) + [ # Sending RCS messages ](rcs-send-message.md) + [ # Receiving inbound RCS messages ](rcs-inbound.md) + [ # Launching RCS in countries ](rcs-country-launch.md) + [ # RCS CloudWatch metrics and monitoring ](rcs-monitoring.md) + [ # RCS billing and pricing model ](rcs-billing.md) # What is RCS? Rich Communication Services (RCS) for business is a messaging protocol that enhances traditional SMS with verified brand identity. With AWS End User Messaging, you can send RCS text messages to recipients in the United States and Canada, with automatic SMS fallback for devices or carriers that don't support RCS. RCS messages appear in the same messaging app that recipients use for SMS, but include your verified brand name, logo, and colors. This makes RCS an in-place upgrade rather than a new channel to adopt. Customers using the `SendTextMessage` API can start using RCS with minimal to no code changes, and end users don't change their messaging flow. Verified identities inspire trust, encourage conversations, enhance existing messaging use cases, and open the door for new use cases like conversational experiences. **Important** Google is part of the message delivery chain for delivering your RCS messages. Accordingly, your use of the RCS messaging channel in AWS End User Messaging is also subject to the [Google RCS for Business Terms of Service](https://developers.google.com/business-communications/rcs-business-messaging/terms-and-policies/tos), which includes information on how Google may use your RCS message content. **Topics** + [ ## Key benefits of RCS ](#rcs-overview-benefits) + [ ## How RCS differs from SMS ](#rcs-overview-how-rcs-differs) + [ ## Why SMS fallback is essential ](#rcs-overview-sms-fallback) + [ ## Supported RCS capabilities ](#rcs-overview-phase1-scope) + [ ## Understanding the two-level identity model ](#rcs-overview-identity-model) ## Key benefits of RCS RCS messaging through AWS End User Messaging provides the following benefits over traditional SMS: **Verified brand identity** RCS messages display your brand logo, name, and colors alongside a verified badge on Android devices. Recipients can confirm that the message is from your organization, which reduces the risk of phishing and improves engagement. **Delivery receipts (DLRs)** RCS provides device-level delivery receipts that confirm when a message has been delivered to the recipient's device. Unlike SMS, where delivery confirmation comes from the carrier network, RCS DLRs report directly from the device, giving you stronger assurance of actual delivery. This is also tied to billing. With RCS, you only pay for messages that are confirmed delivered to the device, whereas SMS charges are incurred when the message is accepted by the carrier. **Improved messaging performance** Messages delivered via RCS tend to achieve better business results compared to SMS because verified brand identity increases recipient trust and engagement. While RCS is not yet as universally available as SMS, the subset of messages delivered via RCS typically sees higher open rates and conversions. For recipients whose devices or carriers do not support RCS, automatic SMS fallback ensures your messages still reach them. **Automatic SMS fallback** When you send messages through a phone pool that contains both an AWS RCS Agent and SMS phone numbers, AWS End User Messaging automatically falls back to SMS if RCS delivery is not possible. This ensures your messages reach recipients regardless of their device or carrier support for RCS. ## How RCS differs from SMS The following table compares RCS and SMS messaging capabilities in AWS End User Messaging. **RCS compared to SMS** | Feature | RCS | SMS | | --- | --- | --- | | Brand identity | Verified brand name, logo, colors, and badge | Phone number or sender ID only | | Delivery confirmation | Device-level delivery receipts: the recipient's device reports back directly, confirming actual delivery. You are only billed for confirmed deliveries. | Carrier-level confirmation: the carrier network acknowledges receipt, but this does not guarantee the message reached the device. You are billed when the carrier accepts the message. | | Message content | Text messages | Text messages, MMS for media | | Device support | Android devices with RCS enabled, iPhone with iOS 18 or later | All mobile devices | | Supported countries | United States and Canada | Over 200 countries and regions | ## Why SMS fallback is essential Not all mobile devices and carriers support RCS. For example, older Android devices, some carriers, and iPhones running iOS versions earlier than 18 cannot receive RCS messages. For most use cases, you need a reliable way to reach all recipients regardless of their device or carrier. Phone pools solve this problem. A pool is a container of messaging identities that provides an abstraction layer between your API requests and your origination identities. Instead of putting SMS fallback number selection logic in your application, you add RCS agents and phone numbers to a pool and AWS End User Messaging handles the rest. This gives you three advantages: + Easy RCS-to-SMS fallback without worrying about which numbers work in which country. Add your identities to a pool and the service selects the right one automatically. + Number and agent selection logic stays out of your application code and in easy-to-manage configuration. You can add or remove identities without changing your sending integration. + While simple to set up, pools also allow complete control over how you use numbers and RCS agents together, including per-use-case pools for compliance-safe routing. To use SMS fallback, create a phone pool that contains both your AWS RCS Agent and one or more SMS phone numbers. When you send a message using the pool, AWS End User Messaging attempts RCS delivery first and automatically falls back to SMS if needed. We recommend pool-based sending for all messaging use cases, not just RCS, because it provides flexibility to add or change origination identities without modifying your application code. **Note** If you send a message directly to an AWS RCS Agent (without using a pool), SMS fallback is not available. Use direct sending only when you require RCS-or-nothing delivery or when you manage fallback logic outside of AWS End User Messaging. ## Supported RCS capabilities The initial launch of RCS in AWS End User Messaging supports text-only messaging in the United States and Canada. You can send and receive plain text RCS messages using the same `SendTextMessage` API that you use for SMS. RCS in AWS End User Messaging currently supports the following: + Sending and receiving text messages through RCS + Verified brand identity (logo, name, colors, and verified badge) + Delivery receipts (DLRs) + Automatic SMS fallback with pool-based sending + Two-way messaging (receiving inbound RCS text messages) + Keyword management for auto-responses + CloudWatch metrics for RCS message monitoring + Country launches in the United States and Canada + RCS testing agents for testing without carrier approval + Phone mockups in the console to preview how your brand appears on devices + A single AWS RCS Agent resource that manages country-specific registrations for both the US and Canada + Shared registration details across countries, with per-country customization + All AWS End User Messaging capabilities including configuration sets, phone pools, opt-out lists, and keywords **Note** RCS testing agents are typically created and approved within minutes, compared to SMS phone number registrations which can take days or weeks. This allows you to start testing RCS messaging quickly. ## Understanding the two-level identity model RCS in AWS End User Messaging uses a two-level identity model: the **AWS RCS Agent** (a container you create and manage) and one or more **RCS for Business IDs** (per-country agent identities created during registration). For complete details on how these identities relate, including lifecycle states and the comparison table, see [Understanding the two-level identity model](rcs-agents.md#rcs-agents-identity-model). # Getting started with RCS This guide walks you through setting up your first RCS agent in AWS End User Messaging, and sending and receiving your first RCS message. By the end, you will have a working RCS testing environment. Estimated time to complete: 15–30 minutes. Here is what this guide covers: 1. Create an AWS RCS Agent and submit a testing registration 1. Add a test device and accept the tester invitation 1. Send your first outbound RCS message 1. Test inbound (two-way) messaging with keywords For background on how RCS works in AWS End User Messaging, including the two-level identity model (AWS RCS Agent and RCS for Business IDs), see [What is RCS?](rcs-overview.md). ## Setting up and testing RCS This section guides you through creating an AWS RCS Agent, registering a test device, sending your first RCS message, and verifying delivery. After completing these steps, you can proceed to launch RCS in production countries. ### Prerequisites Before you begin, make sure you have the following: + **An AWS account with AWS End User Messaging access** — You need an AWS account with permissions to use AWS End User Messaging. If you don't have an account, see the [AWS account setup guide](https://docs.aws.amazon.com/accounts/latest/reference/welcome-first-time-user.html). + **A phone with RCS enabled** — You need an Android phone with RCS messaging enabled in the default messaging app, or an iPhone running iOS 18 or later. This phone serves as your test device for receiving RCS messages. + **(Optional) AWS CLI configured** — If you want to test using the API instead of the console, install and configure the AWS CLI or use an AWS SDK such as boto3 for Python. ### Step 1: Create your AWS RCS Agent and submit a testing registration The first step is to create an AWS RCS Agent and submit a testing registration. The testing registration creates an RCS for Business ID (testing agent) that you can use to send messages to registered test devices without carrier approval. For full details on AWS RCS Agent management, including the agent lifecycle and API operations, see [Managing RCS agents](rcs-agents.md). #### Creating an AWS RCS Agent (console) **To create an AWS RCS Agent and submit a testing registration** 1. Open the [AWS End User Messaging console](https://console.aws.amazon.com/sms-voice/home). 1. In the navigation pane, under **Configurations**, choose **RCS agents**. 1. Choose **Create RCS Agent**. This creates an AWS RCS Agent and then immediately guides you through creating a testing registration in a single workflow. 1. The next screen shows an introduction to RCS and explains the setup process. Review the information and choose **Next** to continue. 1. On the **Agent details** page, set the following: + **Friendly name** — A console-only label for your AWS RCS Agent. This is an internal name for your reference (stored as a tag) and is not the name displayed on recipients' phones. The friendly name is not available through the API. + **Deletion protection** — (Optional) Enable to prevent accidental deletion of the agent. + **Tags** — (Optional) Add tags to organize and identify your agent. 1. In the **Brand information** section of the same page, enter the following: + **Display name** — The brand name that recipients see alongside your RCS messages. + **Description** — A brief description of your brand or business. + **Use case** — Select the primary use case for your RCS messaging (for example, transactional notifications, marketing, or customer support). 1. In the **Brand assets** section of the same page, upload the following: + **Logo** — 224 × 224 pixels, PNG with transparency, under 50 KB. + **Banner image** — 1440 × 448 pixels, PNG or JPEG, under 200 KB. + **Brand color** — A hex color code (for example, `#1A73E8`) with a minimum contrast ratio of 4.5:1 against a white background. **Important** Some brand assets cannot be changed after the agent is submitted for registration. Prepare your final brand assets before creating the agent. If you want to experiment first, you can quickly create a test agent using this flow, then create a fresh AWS RCS Agent with finalized brand assets later. 1. On the **Compliance keywords** page, configure your keywords and auto-response messages. 1. On the **Review** page, verify all your settings. 1. Choose **Validate and submit** to create the AWS RCS Agent and submit the testing registration. **Note** You have successfully created an AWS RCS Agent and submitted a testing registration. Your testing agent is typically approved within minutes. Now let's enable test messaging to your device. #### Creating an AWS RCS Agent (CLI) You can also create an AWS RCS Agent using the AWS CLI. First, create the agent, then submit a testing registration. Step 1: Create the AWS RCS Agent: ``` aws pinpoint-sms-voice-v2 create-rcs-agent \ --deletion-protection-enabled ``` Step 2: Submit a testing registration for the agent. Use the `CreateRegistration` API with the registration type for RCS testing. You can use the `DescribeRegistrationFieldDefinitions` API to programmatically retrieve all available registration form fields before submitting. Provide your brand assets, description, and contact details as part of the registration form fields. For details on the registration API, see [Managing RCS agents](rcs-agents.md). ### Step 2: Add a test device After your testing registration is approved, add your phone as a test device so you can receive RCS messages from your testing agent. **Note** After you add a test device, the tester invitation is not sent immediately. The system delays activation for at least 120 seconds, and it can take up to 20 minutes for the invitation to arrive. The console shows an approximate activation time. You do not need to wait before adding the device — the system handles the delay automatically. ------ #### [ Console ] **To add a test device** 1. In the AWS End User Messaging console, navigate to your AWS RCS Agent and choose the **Testing** tab. 1. Choose **Add test device**. 1. Enter the phone number of your test device in E.164 format (for example, `+12065550100`). 1. Choose **Add**. ------ #### [ AWS CLI ] Use the `CreateVerifiedDestinationNumber` API with the `--rcs-agent-id` parameter to register a test device for your AWS RCS Agent: ``` aws pinpoint-sms-voice-v2 create-verified-destination-number \ --destination-phone-number +12065550100 \ --rcs-agent-id rcs-a1b2c3d4 ``` ------ After you add the test device, AWS End User Messaging sends a tester invitation to the phone number. The invitation comes from an RCS agent called **RBM Tester Management** and contains two buttons to accept or decline: **Make me a tester** and **Decline**. The recipient must tap **Make me a tester** to complete verification. **Note** On iOS devices (iPhone with iOS 18 or later), the tester invitation may appear in the **Unknown Senders** folder in the Messages app rather than the main inbox. If you don't see the invitation, check the Unknown Senders folder. For more details on managing test devices, including the API approach and troubleshooting, see [Testing RCS messages](rcs-testing.md). ### Step 3: Send your first RCS message After your test device has accepted the tester invitation, you can send your first RCS message. You can use the AWS End User Messaging console or the API. ------ #### [ Console ] **To send a test message using the console** 1. In the AWS End User Messaging console, navigate to your AWS RCS Agent and choose the **Testing** tab. 1. Choose **Outbound test messages**. The console displays a preview of how your message will render on the recipient's device, along with the JSON request body and CLI command. 1. Choose a verified test device from the list. 1. Enter your message text. 1. Choose **Send test message**. **Note** You can optionally set a configuration set for message events. Configuration sets let you consume granular delivery receipts (DLRs) and other message events in the event destination of your choice. This is optional for testing but recommended for production use. For details, see [RCS CloudWatch metrics and monitoring](rcs-monitoring.md). ------ #### [ AWS CLI ] Use the `send-text-message` command to send a test message. Specify your AWS RCS Agent ARN as the origination identity: ``` aws pinpoint-sms-voice-v2 send-text-message \ --destination-phone-number +12065550100 \ --origination-identity arn:aws:sms-voice:us-east-1:123456789012:rcs-agent/rcs-a1b2c3d4 \ --message-body "Hello from RCS! This is my first test message." ``` The `send-text-message` command is the same command you use for SMS. When you specify an AWS RCS Agent ARN as the origination identity, AWS End User Messaging delivers the message via RCS. ------ ### Step 4: Test inbound (two-way) messaging You can test inbound RCS messaging by configuring a keyword with an auto-response and then sending a message from your test device that matches that keyword. **To test inbound messaging with auto-response keywords** 1. In the AWS End User Messaging console, navigate to your AWS RCS Agent and configure a keyword. For example, set the keyword `RCSINBOUNDTESTING` with an auto-response message such as "Inbound test successful\$1 Your message was received." 1. On the **Testing** tab, choose **Inbound deep link**. 1. In the **Default message body** field, enter the keyword you configured (for example, `RCSINBOUNDTESTING`). 1. Choose **Generate link**. The console generates an inbound deep link URL using the GSMA standard `sms:` URI scheme. This deep link is embedded in the QR code displayed on the screen. 1. Scan the QR code with your verified tester phone. This opens the native messaging app with a pre-populated message addressed to your AWS RCS Agent. 1. Send the message from your test device. 1. Verify that you receive the auto-response message on your test device. Testing auto-response keywords does not require setting up an event destination or Amazon SNS topic. The auto-response is handled entirely by AWS End User Messaging based on the keyword configuration on your AWS RCS Agent. To receive and process arbitrary inbound messages (not just keyword matches), you need to configure an Amazon SNS topic for two-way messaging. For details, see [Receiving inbound RCS messages](rcs-inbound.md). ### What you accomplished By completing the steps in this guide, you have: + Created an AWS RCS Agent with your brand assets and submitted a testing registration + Registered a test device and accepted the tester invitation + Sent your first RCS message and verified delivery + Tested inbound messaging using auto-response keywords Your testing environment is now ready. Here are ways to integrate RCS messaging into your application or fine-tune how RCS messaging works: + **Receive and process inbound messages**: Configure an Amazon SNS topic to receive inbound RCS messages and process them with Lambda functions. See [Receiving inbound RCS messages](rcs-inbound.md). + **Track delivery events**: Set up configuration sets to consume granular delivery receipts (DLRs) and other message events in the event destination of your choice. See [RCS CloudWatch metrics and monitoring](rcs-monitoring.md). + **Enable SMS fallback**: Create a phone pool with your AWS RCS Agent and SMS phone numbers to automatically fall back to SMS when RCS delivery is not possible. See [RCS to SMS fallback using phone pools](rcs-sms-fallback.md). + **Launch in production countries**: Submit country launch registrations to send RCS messages to all recipients in the United States and Canada. See [Launching RCS in countries](rcs-country-launch.md). ## AI agent prompt for RCS setup If you use a generative AI coding assistant or AI agent, you can use the following prompt to get help creating an AWS RCS Agent, submitting a testing registration, and sending your first test message using the AWS CLI. **Note** Copy the following prompt and paste it into your AI agent or coding assistant: ``` ## RCS Setup Assistant Prompt Help me set up RCS messaging in AWS End User Messaging using the AWS CLI. The service is `pinpoint-sms-voice-v2`. Walk me through each step with exact CLI commands. Ask me for all required details before generating any commands. **Important rules for generating commands:** - All commands use the `pinpoint-sms-voice-v2` service. - Use `create-rcs-agent` exactly as spelled — NOT `create-r-c-s-agent`. - Use the term "testing" — NOT "sandbox". - There is NO `describe-messages` API. Do not generate it. - `create-rcs-agent` does NOT accept brand asset parameters (no display name, no logo, no banner, no color). Brand assets are registration fields only. - `create-verified-destination-number` uses `--rcs-agent-id`, NOT `--origination-identity`. ### Step 1: Create an RCS Agent Use `create-rcs-agent`. This creates the agent resource only. Optional parameters: `--deletion-protection-enabled`, `--opt-out-list-name`, `--tags`. The response returns `RcsAgentId` and `RcsAgentArn` — save both. ### Step 2: Create and submit a testing registration This configures brand assets and submits for approval. It requires multiple API calls in sequence: a. `create-registration --registration-type TEST_RCS_LAUNCH_REGISTRATION` → returns `RegistrationId`. Save it. b. `create-registration-association --registration-id --resource-id ` → links the registration to the agent. c. Upload images as attachments (two calls): `create-registration-attachment --attachment-body fileb://` `create-registration-attachment --attachment-body fileb://` → each returns `RegistrationAttachmentId`. Save both. d. Set ALL required registration fields using `put-registration-field-value` with `--registration-id`, `--field-path`, and the appropriate value flag (`--text-value`, `--select-choices`, or `--registration-attachment-id`). Required fields (ALL must be set or registration will be DENIED): - `agentDetails.brandName` (text, 2-65 chars) - `agentDetails.serviceName` (text, 1-100 chars) - `agentDetails.senderDisplayName` (text, 1-40 chars) - `agentDetails.useCase` (select: OTP, TRANSACTIONAL, PROMOTIONAL, MULTI_USE) - `agentDetails.agentDescription` (text, 1-100 chars) - `agentDetails.logoImage` (attachment ID from step c, 224x224 PNG) - `agentDetails.bannerImage` (attachment ID from step c, 1440x448 PNG/JPEG) - `agentDetails.accentColor` (text, hex code e.g. #0066CC) - `agentDetails.privacyPolicyUrl` (text, valid URL) - `agentDetails.termsAndConditionsUrl` (text, valid URL) - `agentDetails.averageMonthlyRcsFrequency` (select: 10, 100, 1000+) - `agentDetails.monthlyRcsVolume` (text, 1-100000) - At least ONE contact method WITH its label: agentDetails.contactWebsite + agentDetails.contactWebsiteLabel, OR agentDetails.contactPhoneNumber + agentDetails.contactPhoneLabel, OR agentDetails.contactEmailAddress + agentDetails.contactEmailLabel e. Verify all fields: `describe-registration-field-values --registration-id ` Any field showing `DeniedReason: MISSING_REQUIRED_FIELD` must be set. f. Submit: `submit-registration-version --registration-id ` g. Poll status: `describe-registrations --registration-ids ` Wait for `RegistrationStatus: COMPLETE`. **Error recovery:** If registration is DENIED, you must: 1. `create-registration-version --registration-id ` (creates new draft) 2. Re-populate ALL fields from scratch (new versions do NOT inherit values) 3. Fix the issue noted in `DeniedReasons` 4. Re-submit ### Step 3: Add a test device **Prerequisite:** Step 2 must be COMPLETE and the agent's `TestingAgent.Status` must be `ACTIVE` (check with `describe-rcs-agents`). Then wait at least 120 seconds after the agent becomes ACTIVE. Use `create-verified-destination-number --destination-phone-number --rcs-agent-id `. The device status will be `PENDING`. The user must accept the RCS tester invitation on their physical device. Check status with `describe-verified-destination-numbers` — wait for `VERIFIED`. ### Step 4: Send a test RCS message **Prerequisite:** Step 3 device must be `VERIFIED`. Use `send-text-message --destination-phone-number --origination-identity --message-body "" --message-type TRANSACTIONAL`. Returns `MessageId`. ### Step 5: Verify delivery For testing: check the test device — the message appears from the branded RCS agent. For production monitoring: set up event destinations BEFORE sending messages using `create-event-destination` (SNS, CloudWatch Logs, or Firehose). Event destinations do not retroactively capture events for already-sent messages. CloudWatch metrics in the `AWS/SMSVoice` namespace provide aggregate stats. --- **Before generating commands, ask me for:** - Brand name, service name, and sender display name - Agent description (what the agent does, what messages users receive) - Use case type: OTP, TRANSACTIONAL, PROMOTIONAL, or MULTI_USE - Logo file path (224x224 PNG) and banner file path (1440x448 PNG/JPEG) - Brand accent color hex code (e.g. #0066CC) - Privacy policy URL and terms & conditions URL - One contact method with label: website URL, phone number, or email - Estimated monthly RCS volume and per-user message frequency - Test device phone number in E.164 format (e.g. +12065550100) ``` # Managing RCS agents An AWS RCS Agent is the top-level resource in AWS End User Messaging that represents your brand for RCS messaging. It serves as the unified resource that binds together your testing agent and country launch agents (RCS for Business IDs). Keywords and two-way messaging configuration are defined on the AWS RCS Agent. Brand assets are defined on each registration (testing agent or country launch agent). For an overview of how the AWS RCS Agent relates to RCS for Business IDs, see [What is RCS?](rcs-overview.md). The AWS RCS Agent follows this lifecycle: 1. **Create** the AWS RCS Agent. 1. **Add a testing agent** (included in the console create flow; optional via CLI). 1. **Test** your RCS messaging with registered test devices. No carrier approval is required for testing. 1. **Submit a country launch** registration for each country where you want to send production RCS messages. 1. **Partially approved**: at least one carrier has approved your agent. You can start sending to recipients on approved carriers. 1. **Fully approved**: all carriers in the country have approved your agent. Full reach in that country. One AWS RCS Agent maps to one testing agent (an RCS for Business ID) plus multiple country launch agents (one RCS for Business ID per country). When you create an AWS RCS Agent in the console, the workflow immediately guides you to create a testing agent. The testing agent's brand configuration is then used to pre-populate country launch registration forms, reducing duplicative data entry. **Topics** + [ ## Understanding the AWS RCS Agent ](#rcs-agents-concept) + [ ## Understanding the two-level identity model ](#rcs-agents-identity-model) + [ ## Creating an AWS RCS Agent ](#rcs-agents-create) + [ ## Updating an AWS RCS Agent ](#rcs-agents-update) + [ ## Viewing AWS RCS Agents ](#rcs-agents-view) + [ ## Reviewing your testing agent ](#rcs-agents-review-test-agent) + [ ## Viewing country launch status ](#rcs-agents-country-launch-status) + [ ## Deleting an AWS RCS Agent ](#rcs-agents-delete) ## Understanding the AWS RCS Agent The AWS RCS Agent is distinct from the RCS for Business IDs that it manages. The following table summarizes the differences: **AWS RCS Agent compared to RCS for Business ID** | Attribute | AWS RCS Agent | RCS for Business ID | | --- | --- | --- | | Managed by | You, through AWS End User Messaging console or API | AWS End User Messaging, during the registration process | | Scope | One per brand or per use case | One per country launch, plus one testing agent | | Configuration | Friendly name, deletion protection, opt-out list, tags, keywords, two-way messaging destination | Brand assets and other settings defined during registration | | Identifier | rcs-a1b2c3d4 format | Managed internally by the RCS infrastructure provider | ### Agent ID and ARN Each AWS RCS Agent has a unique identifier in the format `rcs-a1b2c3d4` (the prefix `rcs-` followed by a hexadecimal string). You use this ID when calling API operations such as `UpdateRcsAgent` and `DeleteRcsAgent`. Each AWS RCS Agent also has an AWS resource ARN in the following format: ``` arn:aws:sms-voice:region:account-id:rcs-agent/rcs-agent-id ``` You can use the ARN when specifying the AWS RCS Agent as an origination identity in the `SendTextMessage` API or when adding the agent to a phone pool. ### Lifecycle states An AWS RCS Agent transitions through the following lifecycle states: **CREATED** The AWS RCS Agent resource has been created in AWS End User Messaging, but no registration has been submitted yet. You can update brand assets and configuration in this state. **PENDING** A registration has been submitted and is awaiting processing. The agent is not yet available for sending messages. **TESTING** The testing registration has been approved. The agent has a testing agent (RCS for Business ID) and can send messages to registered test devices. No country launch registrations have been completed. **PARTIAL** At least one country launch registration has been completed, but not all submitted country launches are active. The agent can send messages in countries where it has been approved, but only to recipients on the specific carrier(s) that have approved the agent. The `CountryStatus` for a country moves to PARTIAL as soon as at least one carrier in that country is active. **ACTIVE** All submitted country launch registrations are complete and active. The agent is fully operational in all registered countries. Note that an ACTIVE agent can return to PARTIAL status when a new country launch registration is submitted, because the new country is not yet approved. **DELETED** The AWS RCS Agent has been deleted. All associated RCS for Business IDs (testing and country launch agents) are deactivated. This action cannot be undone. ## Understanding the two-level identity model RCS in AWS End User Messaging uses a two-level identity model: the **AWS RCS Agent** and one or more **RCS for Business IDs**. **AWS RCS Agent** The AWS RCS Agent is the top-level resource that you create and manage in AWS End User Messaging. It serves as the unified resource that binds together your testing agent and country launch agents. Keywords and two-way messaging configuration are defined on the AWS RCS Agent. Brand assets are defined on each registration. Each AWS RCS Agent has a unique identifier in the format `rcs-a1b2c3d4` and an AWS resource ARN. Think of the AWS RCS Agent as the unified identity for your brand across all countries where you launch RCS. **RCS for Business ID** An RCS for Business ID is the per-country agent identity that is created with the RCS infrastructure provider during the registration process. Each country launch creates a separate RCS for Business ID under your AWS RCS Agent. You don't manage RCS for Business IDs directly. AWS End User Messaging handles the creation and lifecycle as part of the registration process. One AWS RCS Agent can have the following RCS for Business IDs: + **One testing agent** — An RCS for Business ID created during the testing registration phase. The testing agent works with registered test devices and allows you to validate your RCS integration before launching in production. Testing messages are charged at standard rates. + **Multiple country launch agents** — Each country where you launch RCS creates a separate RCS for Business ID. For example, if you launch in both the United States and Canada, your AWS RCS Agent has two country launch agents (one US RCS for Business ID and one Canada RCS for Business ID) in addition to the testing agent. The following diagram shows the relationship between these identities: ``` AWS RCS Agent (rcs-a1b2c3d4) ├── Testing agent (RCS for Business ID) ├── US country launch agent (US RCS for Business ID) └── CA country launch agent (Canada RCS for Business ID) ``` Keywords and two-way messaging destinations are configured on the AWS RCS Agent and apply to all associated RCS for Business IDs. Brand assets are specific to each registration (testing agent or country launch agent). The AWS RCS Agent also holds account-level settings such as the friendly name, deletion protection, and opt-out list. ## Creating an AWS RCS Agent You can create an AWS RCS Agent using the AWS End User Messaging console or the `CreateRcsAgent` API. When you create an agent, you provide a friendly name in the console (a console-only label stored as a tag, not visible through the API or displayed on recipients' phones) and configure optional settings such as deletion protection and opt-out list association. Brand assets are defined on the registration, not on the AWS RCS Agent itself. ### Brand asset requirements Your brand assets are displayed to recipients alongside your RCS messages. Brand assets are submitted as part of the testing registration, which the console presents as a continuation of the agent creation workflow. The following assets are required when creating an AWS RCS Agent: **Logo** A square image that represents your brand. The logo appears in the messaging app alongside your messages. + Dimensions: 224 × 224 pixels + Format: PNG with transparency + Maximum file size: 50 KB **Banner image** A wide image that appears at the top of your agent's profile in the messaging app. The banner image is only displayed on Android devices. + Dimensions: 1440 × 448 pixels + Format: PNG or JPEG + Maximum file size: 200 KB **Brand color** A hex color code (for example, `#1A73E8`) used as an accent color in the messaging app. The color must have a minimum contrast ratio of 4.5:1 against a white background to meet accessibility requirements. If the contrast ratio is not set properly, your agent may not be approved. **Important** Brand assets have limitations on changes after the agent is created. Some brand assets cannot be modified once the agent has been submitted for registration. Prepare your final brand assets before creating your AWS RCS Agent. ------ #### [ Console ] The AWS End User Messaging console presents AWS RCS Agent creation and testing registration as a single guided workflow. For step-by-step console instructions, see [Step 1: Create your AWS RCS Agent and submit a testing registration](rcs-getting-started.md#rcs-getting-started-create-agent). ------ #### [ AWS CLI ] Use the `create-rcs-agent` command to create an AWS RCS Agent. Brand assets (display name, description, logo, banner, and brand color) are not parameters of this command. They are submitted as registration fields when you create a testing registration. ``` aws pinpoint-sms-voice-v2 create-rcs-agent \ --deletion-protection-enabled ``` The following optional parameters are available: + `--deletion-protection-enabled` — Prevents the agent from being deleted until deletion protection is disabled. + `--opt-out-list-name` — Associates an existing opt-out list with the agent. + `--tags` — Key-value pairs to organize and identify your AWS RCS Agent. ------ ## Updating an AWS RCS Agent Use the `UpdateRcsAgent` API to modify the settings of an existing AWS RCS Agent. You can update the following settings: + **Deletion protection** — Enable or disable deletion protection for the agent. + **Opt-out list** — Associate or disassociate an opt-out list with the agent. + **Two-way messaging destination** — Configure the Amazon SNS topic and IAM role where inbound messages are delivered. Two-way messaging is always enabled for RCS. Customers are charged for all inbound RCS messages at standard rates. This setting controls where inbound messages are delivered, not whether they are received. **Note** Changes to your AWS RCS Agent settings through the API are available immediately. However, updates to brand assets (registration fields such as logo, banner, and display name) are reviewed by the RCS infrastructure provider and may take time to appear on recipients' devices. To verify that your API changes have been applied, use the `DescribeRcsAgents` API to confirm the current agent configuration in AWS End User Messaging. ## Viewing AWS RCS Agents You can view your AWS RCS Agents using the AWS End User Messaging console or the `DescribeRcsAgents` API. ------ #### [ Console ] To view your AWS RCS Agents in the console, navigate to the **RCS agents** page under **Configurations** in the navigation pane. The list page displays all AWS RCS Agents in your account, including their current lifecycle state, agent ID, and display name. Choose an agent to view its details, including brand assets, configuration settings, and associated registrations. ------ #### [ AWS CLI ] Use the `describe-rcs-agents` command to list all AWS RCS Agents in your account: ``` aws pinpoint-sms-voice-v2 describe-rcs-agents ``` To retrieve details for a specific agent, use the `--rcs-agent-ids` parameter: ``` aws pinpoint-sms-voice-v2 describe-rcs-agents \ --rcs-agent-ids rcs-a1b2c3d4 ``` ------ ## Reviewing your testing agent Before submitting a country launch registration, review your testing agent configuration to ensure your brand assets, keywords, and messaging settings are correct. The testing agent serves as the template for country launch registrations, so any issues should be resolved before proceeding. To review your testing agent, navigate to your AWS RCS Agent in the AWS End User Messaging console and choose the **Registrations** tab. The testing registration shows your current brand configuration, including the logo, banner image, brand color, and display name as they appear on recipients' devices. You can also use the `DescribeRegistrationFieldValues` API to retrieve the current field values for your testing registration programmatically. ## Viewing country launch status After you submit a country launch registration for your AWS RCS Agent, you can track the approval status for each carrier in that country. ------ #### [ Console ] To view the country launch status in the console, navigate to the details page for your AWS RCS Agent and choose the **Country launch status** tab. This tab displays the approval status for each carrier in each country where you have submitted a launch registration. ------ #### [ AWS CLI ] Use the `describe-rcs-agent-country-launch-status` command to retrieve the per-carrier launch status: ``` aws pinpoint-sms-voice-v2 describe-rcs-agent-country-launch-status \ --rcs-agent-id rcs-a1b2c3d4 ``` The response includes the approval status for each carrier in each country where you have submitted a launch registration. ------ Each carrier independently reviews and approves your agent. Your AWS RCS Agent can send messages in a country as soon as at least one carrier in that country has approved the agent. You do not need to wait for all carriers to approve before you can start sending RCS messages. As additional carriers approve your agent, your reach in that country increases. **Note** You can request additional country launches from the country launch status screen. Each new country launch creates a separate registration and goes through its own carrier approval process. ## Deleting an AWS RCS Agent Use the `DeleteRcsAgent` API to permanently delete an AWS RCS Agent. When you delete an agent, all associated RCS for Business IDs (including the testing agent and all country launch agents) are deactivated. **Warning** Deleting an AWS RCS Agent is permanent and cannot be undone. All registrations, country launches, and testing configurations associated with the agent are lost. Before you can delete an AWS RCS Agent, you must first delete all associated registrations (both testing and country launch registrations), and then disable deletion protection. If deletion protection is enabled, the `DeleteRcsAgent` API returns an error. To disable deletion protection, use the `UpdateRcsAgent` API with deletion protection set to `false`. **To delete an AWS RCS Agent** 1. If deletion protection is enabled, disable it by calling the `UpdateRcsAgent` API with deletion protection set to `false`. 1. Call the `DeleteRcsAgent` API with the agent ID or ARN of the AWS RCS Agent that you want to delete. 1. Verify that the agent has been deleted by calling the `DescribeRcsAgents` API. The agent should no longer appear in the results, or its status should be DELETED. # Testing RCS messages Before you launch RCS messaging in production, you can test your integration using a testing agent. The testing agent is an RCS for Business ID that is created when you submit a testing registration for your AWS RCS Agent. It provides full API access identical to production, but restricts message delivery to registered test devices only. No carrier approval is needed for testing. This chapter focuses on the testing agent itself, including how to manage test devices and how to troubleshoot common issues. For a step-by-step walkthrough of creating your first AWS RCS Agent and sending a test message, see [Getting started with RCS](rcs-getting-started.md). For details on creating an AWS RCS Agent and submitting a testing registration, see [Managing RCS agents](rcs-agents.md). **Important** Testing messages are charged at standard RCS rates. The testing agent provides a testing environment for validating your integration, but message delivery to test devices incurs the same charges as production messages. **Topics** + [ ## What is a testing agent? ](#rcs-testing-what-is) + [ ## Adding test devices ](#rcs-testing-add-devices) + [ ## Tester invitation flow ](#rcs-testing-tester-invitation) + [ ## Viewing test devices ](#rcs-testing-view-devices) + [ ## Sending test messages ](#rcs-testing-send-messages) + [ ## Testing SMS fallback ](#rcs-testing-sms-fallback) + [ ## Troubleshooting RCS testing ](#rcs-testing-troubleshooting) ## What is a testing agent? A testing agent is an RCS for Business ID that AWS End User Messaging creates when you submit a testing registration for your AWS RCS Agent. The testing agent allows you to: + Send RCS messages to registered test devices without carrier approval + Use the `SendTextMessage` API to send test messages, the same API you use in production + Configure pools, configuration sets, opt-out lists, keywords, and other AWS End User Messaging capabilities for your testing workflow + Test two-way messaging by sending messages with auto-response keywords + Test SMS fallback behavior with or without an approved SMS phone number Test devices that you register for a testing agent work across all countries for that AWS RCS Agent. You do not need to register test devices separately for each country. Conversely, the testing agent can send messages to test devices in any country, regardless of whether you have submitted a country launch registration for that country. ## Adding test devices Before you can send test RCS messages, you must register one or more test devices as verified destination numbers. You can add test devices using the AWS End User Messaging console or the `CreateVerifiedDestinationNumber` API. ------ #### [ Console ] In the console, test devices are added as part of the AWS RCS Agent creation workflow. For step-by-step console instructions, see [Step 2: Add a test device](rcs-getting-started.md#rcs-getting-started-add-test-device). ------ #### [ AWS CLI ] Use the `create-verified-destination-number` command with the `--rcs-agent-id` parameter to register a test device for your AWS RCS Agent: ``` aws pinpoint-sms-voice-v2 create-verified-destination-number \ --destination-phone-number +12065550100 \ --rcs-agent-id rcs-a1b2c3d4 ``` **Note** The `--origination-identity` parameter is not required. When you specify `--rcs-agent-id`, the command registers the phone number for RCS testing with that agent. When you omit `--rcs-agent-id` and use `--origination-identity` instead, the command sends an OTP SMS for SMS verification. The two parameters are mutually exclusive. ------ ## Tester invitation flow After you add a test device, AWS End User Messaging sends a tester invitation from an RCS agent called RBM Tester Management. The invitation contains buttons to accept or decline. For details on the tester invitation flow, including the 120-second wait requirement and iOS-specific behavior, see [Step 2: Add a test device](rcs-getting-started.md#rcs-getting-started-add-test-device). ## Viewing test devices You can view the test devices registered for your AWS RCS Agent using the AWS End User Messaging console or the `DescribeVerifiedDestinationNumbers` API. ------ #### [ Console ] To view your registered test devices in the console, navigate to the details page for your AWS RCS Agent and choose the **Testing** tab. The tab displays all verified destination numbers associated with the agent, including their verification status and phone number. ------ #### [ AWS CLI ] Use the `describe-verified-destination-numbers` command to list test devices for your AWS RCS Agent. Use the `--filters` parameter with `rcs-agent-id` to show only RCS test devices: ``` aws pinpoint-sms-voice-v2 describe-verified-destination-numbers \ --filters Name=rcs-agent-id,Values=rcs-a1b2c3d4 ``` ------ Test devices that you register for a testing agent work globally for that AWS RCS Agent. A test device registered in one AWS Region can receive test messages sent from any AWS Region where your AWS RCS Agent is available. ## Sending test messages After a test device has accepted the tester invitation, you can send RCS messages to it. You can send test messages using the AWS End User Messaging console or the `SendTextMessage` API. ------ #### [ Console ] **To send a test message using the console** 1. Open the AWS End User Messaging console. 1. In the navigation pane, under **Configurations**, choose **RCS agents**. 1. Choose the AWS RCS Agent that you want to test. 1. Choose the **Testing** tab. 1. In the **Send test message** section, choose a verified test device from the list. 1. Enter your message text. 1. Choose **Send test message**. ------ #### [ AWS CLI ] Use the `send-text-message` command to send a test message to a verified destination number. Specify the AWS RCS Agent ARN as the origination identity: ``` aws pinpoint-sms-voice-v2 send-text-message \ --destination-phone-number +12065550100 \ --origination-identity arn:aws:sms-voice:us-east-1:123456789012:rcs-agent/rcs-a1b2c3d4 \ --message-body "Hello from RCS testing!" ``` ------ ## Testing SMS fallback You can test SMS fallback behavior to verify that your messages are delivered via SMS when RCS delivery is not possible. For complete instructions on testing SMS fallback, including testing without an approved SMS number and the full end-to-end flow, see [Testing SMS fallback](rcs-sms-fallback.md#rcs-sms-fallback-testing). ## Troubleshooting RCS testing The following sections describe common issues that you might encounter when testing RCS messages and how to resolve them. ### Test device is not receiving RCS messages If your test device is not receiving RCS messages, check the following: + Verify that the test device has accepted the tester invitation. Use the `DescribeVerifiedDestinationNumbers` API with the `rcs-agent-id` filter to check the verification status of the device. + Verify that the test device has RCS enabled. On Android, check the messaging app settings for RCS or Chat features. On iPhone, RCS requires iOS 18 or later. + Verify that the test device has an active data connection. RCS messages are delivered over data, not the SMS channel. + Verify that you are sending to the correct phone number in E.164 format. ### Message delivered as SMS instead of RCS If your test message is delivered as SMS instead of RCS, check the following: + Verify that you are sending the message using the AWS RCS Agent ARN or a pool that contains the AWS RCS Agent as the origination identity. If you specify only an SMS phone number, the message is sent via SMS. + Verify that the test device has accepted the tester invitation and is registered as a verified destination number for the correct AWS RCS Agent. + Check the delivery event to determine whether the message was initially attempted via RCS and fell back to SMS, or whether it was sent directly via SMS. ### Tester invitation not received If a test device does not receive the tester invitation, check the following: + The tester invitation can take up to 20 minutes to arrive after adding a test device. If the invitation has not arrived after 20 minutes, remove the test device and add it again. + Verify that the phone number is in the correct E.164 format and is a valid mobile number. + Verify that the test device has an active data connection and RCS is enabled. ### iOS: Tester invitation in Unknown Senders On iOS devices (iPhone with iOS 18 or later), the tester invitation from RBM Tester Management may be filtered into the **Unknown Senders** folder in the Messages app. This is a default iOS behavior for messages from unknown contacts. To find the invitation: **To find the tester invitation on iOS** 1. Open the Messages app on the iPhone. 1. Tap **Filters** in the upper-left corner (or swipe right from the message list). 1. Tap **Unknown Senders**. 1. Look for the RBM Tester Management message and tap **Make me a tester** to accept the invitation. # RCS to SMS fallback using phone pools A phone pool is a container of messaging identities, such as AWS RCS Agents and SMS phone numbers, that provides an abstraction layer between your API requests and the underlying origination identities. Pools simplify configuration changes, number type migration, and RCS-to-SMS fallback. You send a single API call to the pool, and AWS End User Messaging handles channel selection for you. This chapter explains how RCS delivery can fail, what makes SMS fallback possible, the fallback logic and priority order, and billing implications. It also covers pool-per-use-case best practices and how to add and remove AWS RCS Agents from pools. For general information about phone pools, see [Phone pools in AWS End User Messaging SMS](phone-pool.md). For information about managing AWS RCS Agents, see [Managing RCS agents](rcs-agents.md). **Topics** + [ ## How RCS delivery can fail ](#rcs-sms-fallback-how-rcs-fails) + [ ## What makes SMS fallback possible ](#rcs-sms-fallback-what-makes-possible) + [ ## Why use pools ](#rcs-sms-fallback-why-pools) + [ ## Pool-per-use-case model ](#rcs-sms-fallback-pool-per-use-case) + [ ## Compliance risk with account-level sending ](#rcs-sms-fallback-compliance-risk) + [ ## Fallback logic and priority order ](#rcs-sms-fallback-logic) + [ ## Billing implications of SMS fallback ](#rcs-sms-fallback-billing) + [ ## Testing SMS fallback ](#rcs-sms-fallback-testing) + [ ## Managing AWS RCS Agents in pools ](#rcs-sms-fallback-pool-management) ## How RCS delivery can fail RCS delivery can fail for several reasons. Understanding these failure modes helps you plan your fallback strategy: + **Carrier does not support RCS** — The recipient's mobile carrier has not enabled RCS messaging on their network. + **Device does not support RCS** — The recipient's device does not have RCS capability (for example, an older Android device or an iPhone running iOS earlier than 18). + **Agent not active on carrier** — Your AWS RCS Agent has not yet been approved by the recipient's carrier, or the agent is in PARTIAL status for that country. + **Device temporarily unreachable** — The recipient's device supports RCS but is temporarily offline or has no data connection. RCS messages require a data connection for delivery. When any of these conditions occur and you are using pool-based or account-level sending, AWS End User Messaging automatically falls back to SMS delivery using a phone number from the same pool or account. ## What makes SMS fallback possible SMS fallback requires both an AWS RCS Agent and at least one SMS phone number in the same pool. When you send a message to the pool, AWS End User Messaging attempts RCS delivery first. If RCS delivery fails, the service retries the message via SMS using a phone number from the same pool. A pool with only an AWS RCS Agent (and no phone numbers) does not support SMS fallback. If RCS fails, the message is not delivered. **Important** For SMS fallback to work, your pool must contain both an AWS RCS Agent and one or more SMS phone numbers. A pool with only a single identity type does not provide cross-channel fallback. ## Why use pools We recommend using a phone pool for all messaging use cases, not just RCS. Pools provide the following advantages: + **Automatic SMS fallback** — When a pool contains both an AWS RCS Agent and SMS phone numbers, AWS End User Messaging attempts RCS delivery first. If RCS delivery fails (for example, the recipient's device or carrier does not support RCS), the service automatically retries the message via SMS using a phone number from the same pool. You do not need to implement fallback logic in your application. + **Intelligent routing** — The service selects the best origination identity from the pool based on the destination, channel availability, and sticky sending history. This routing happens transparently with each `SendTextMessage` call. + **Single API call** — You specify the pool ID as the origination identity in your `SendTextMessage` request. The service determines whether to deliver via RCS or SMS without any additional logic on your side. + **Flexibility for future changes** — You can add or remove phone numbers and AWS RCS Agents from a pool at any time without changing your application code. For example, you can add a toll-free number for SMS fallback or swap out a 10DLC number without modifying your sending integration. + **No cost or downside** — Creating a pool and adding origination identities to it does not incur additional charges. Even with a single phone number or a single AWS RCS Agent, using a pool gives you the flexibility to add more identities later without application changes. **Note** We recommend always using a pool for messaging. There is no cost or downside to using a pool, even with a single origination identity. For RCS-to-SMS fallback, the pool must contain both an AWS RCS Agent and at least one SMS phone number. Starting with a pool from the beginning means you can add SMS fallback numbers or additional AWS RCS Agents later without modifying your sending code. ## Pool-per-use-case model We recommend creating one pool per use case. Each pool should contain all of the phone numbers and the AWS RCS Agent that serve a single messaging purpose. For example: + A **transactional pool** for OTP codes and account notifications, containing your AWS RCS Agent and a 10DLC number registered for transactional messaging. + A **marketing pool** for promotional messages, containing the same AWS RCS Agent (or a different one) and a toll-free number registered for marketing. + An **appointment reminders pool** for scheduling notifications, containing your AWS RCS Agent and a dedicated phone number for appointment-related messages. This model ensures that when RCS delivery fails and the service falls back to SMS, the fallback message is sent from a phone number that is registered and approved for the same use case. This keeps your messaging compliant with carrier requirements and registration terms. ## Compliance risk with account-level sending When you send messages at the account level (without specifying a pool or origination identity), AWS End User Messaging selects an origination identity from all available identities in your account. If your account has multiple phone numbers registered for different use cases, the service may select a phone number that does not match the content of your message. **Important** Account-level sending with mixed use cases creates a compliance risk. For example, if your account has a 10DLC number registered for OTP messages and a toll-free number registered for appointment reminders, an OTP message that falls back to SMS could be sent from the appointment reminders toll-free number. This violates the registration terms for that number and can result in carrier filtering or number suspension. To avoid this risk, use pool-based sending with one pool per use case. When you specify a pool ID in your `SendTextMessage` request, the service only selects origination identities from that pool. Because all identities in the pool are registered for the same use case, the fallback message is always sent from an appropriate number. **Sending approach compliance comparison** | Sending approach | SMS fallback behavior | Compliance risk | | --- | --- | --- | | Pool-based (recommended) | Falls back to a phone number in the same pool, registered for the same use case | Low — fallback number matches the message use case | | Account-level | Falls back to any available phone number in the account | High — fallback number may not match the message use case if multiple use cases share the account | | Direct (AWS RCS Agent ARN) | No SMS fallback | None — message is delivered via RCS only or not at all | ## Fallback logic and priority order When AWS End User Messaging selects an origination identity for a message (either from a pool or from all account identities), it evaluates identities in the following priority order: 1. **Sticky identity** — If a sticky sending pairing exists for the destination phone number and the identity is still available, the service uses that identity. 1. **AWS RCS Agent** — If no sticky pairing exists, the service attempts RCS delivery through an available AWS RCS Agent. 1. **SMS Short Code** — If RCS is not available, the service selects an SMS short code. 1. **SMS 10DLC** — If no short code is available, the service selects a 10DLC number. 1. **SMS Toll-Free Number** — If no 10DLC number is available, the service selects a toll-free number. 1. **SMS Sender ID** — If no other identity is available, the service selects a sender ID. This priority order applies within the scope of the sending pattern you use. For pool-based sending, the service only considers identities in the specified pool. For account-level sending, the service considers all identities in your account. ### Automatic SMS fallback When you send a message through a pool or at the account level, AWS End User Messaging automatically falls back to SMS if RCS delivery is not possible. Fallback is asynchronous: If AWS End User Messaging successfully submits the RCS message but does not receive a delivery confirmation or failure signal within 25 seconds, the service falls back to SMS. This handles cases where the RCS infrastructure accepts the message but delivery stalls (for example, the recipient's device is temporarily unreachable, the carrier does not support RCS, or the device is not RCS-capable). **Note** Direct sending (specifying an AWS RCS Agent ARN as the origination identity) does not support automatic SMS fallback. If you need SMS fallback, use pool-based sending. ### Sticky sending Sticky sending is a routing optimization that improves delivery consistency. When AWS End User Messaging successfully delivers a message to a destination phone number using a specific origination identity, the service remembers that pairing for 25 hours. Subsequent messages to the same destination within the 25-hour window are routed through the same origination identity, provided it is still available in the pool or account. Sticky sending applies to both RCS and SMS delivery. For example, if a message is delivered via RCS through your AWS RCS Agent, the next message to the same destination within 25 hours is also attempted via RCS through the same agent. If the previous message was delivered via SMS (after RCS fallback), the next message is attempted via SMS through the same phone number. The service periodically retries RCS delivery even when the sticky identity is an SMS phone number. This ensures that recipients whose devices gain RCS support (for example, after a carrier rollout or device upgrade) begin receiving RCS messages without manual intervention. Key characteristics of sticky sending: + **25-hour TTL** — The sticky pairing expires 25 hours after the last successful delivery. After expiration, the service re-evaluates the origination identity priority order for the next message. + **Automatic RCS retry** — Even when the sticky identity is an SMS phone number, the service periodically attempts RCS delivery to check whether the recipient now supports RCS. + **No manual flushing** — You cannot manually flush or reset sticky sending pairings. The pairing expires automatically after the 25-hour TTL. ### Delivery receipts during fallback When SMS fallback occurs, AWS End User Messaging generates a single delivery receipt for the final channel that delivered the message. If the message is delivered via SMS after RCS fallback, the delivery receipt indicates SMS as the delivery channel. Under normal circumstances, AWS End User Messaging revokes the RCS message before the SMS fallback message is delivered. This prevents the recipient from receiving the same message twice. However, in rare cases, both the RCS message and the SMS fallback message may be delivered. This can happen if the RCS message is delivered after the 25-second timeout but before the revocation completes. In these rare dual-delivery scenarios, you may receive delivery receipts for both channels. For information about how dual delivery affects billing, see [RCS billing and pricing model](rcs-billing.md). ## Billing implications of SMS fallback When a message falls back from RCS to SMS, you are charged for the SMS delivery, not the failed RCS attempt. RCS messages are billed only when successfully delivered to the recipient's device. If RCS delivery fails and the message falls back to SMS, you pay the SMS rate for that message. In rare dual-delivery scenarios (where both the RCS message and the SMS fallback message are delivered), you may be charged for both deliveries. For complete billing details, see [RCS billing and pricing model](rcs-billing.md). ## Testing SMS fallback You can test SMS fallback behavior to verify that your messages are delivered via SMS when RCS delivery is not possible. There are two approaches to testing SMS fallback, depending on whether you have an approved SMS phone number. ### Testing without an approved SMS number You can verify that AWS End User Messaging correctly triggers the fallback mechanism without an approved SMS phone number. Even without an approved number, you can see the retry and failure events via SMS, which confirms that fallback is working. **To test SMS fallback without an approved SMS number** 1. Take your test device offline by disabling mobile data and Wi-Fi, or enable airplane mode. 1. Send an RCS message to the test device using the `SendTextMessage` API with your AWS RCS Agent ARN as the origination identity. 1. Check the message event in CloudWatch or your event destination. You should see a failed delivery event indicating that RCS delivery was not possible and that the service attempted SMS fallback. Because there is no SMS phone number available for fallback, the SMS delivery also fails. However, the event confirms that AWS End User Messaging correctly triggered the fallback mechanism. ### Testing with an approved SMS number For a complete end-to-end SMS fallback test, add an approved SMS phone number and your AWS RCS Agent to the same phone pool. This allows you to verify that messages are delivered via SMS when RCS is not available. **To test SMS fallback with an approved SMS number** 1. Create a phone pool that contains both your AWS RCS Agent and an approved SMS phone number (such as a 10DLC, toll-free, or short code number). 1. Take your test device offline by disabling mobile data and Wi-Fi, or enable airplane mode. 1. Send a message using the `SendTextMessage` API with the pool ID as the origination identity. 1. Verify that the message is delivered via SMS to your test device. 1. Check the delivery event to confirm that the message was delivered through the SMS channel after RCS fallback. ## Managing AWS RCS Agents in pools For step-by-step instructions on creating pools with AWS RCS Agents, adding agents to existing pools, understanding pool configuration requirements, and removing agents from pools, see [Managing AWS RCS Agents in pools](phone-pool-rcs-agents.md). # Sending RCS messages AWS End User Messaging uses the same `SendTextMessage` API for both RCS and SMS delivery. How the service routes your message depends on the origination identity you specify in the request. You can send messages through a phone pool (recommended), at the account level, or directly through an AWS RCS Agent ARN. This section explains the three sending patterns, how to interpret delivery receipts, and provides code examples. For details on sticky sending, origination identity priority order, and automatic SMS fallback, see [RCS to SMS fallback using phone pools](rcs-sms-fallback.md). For details on managing AWS RCS Agents, see [Managing RCS agents](rcs-agents.md). **Topics** + [ ## Sending patterns ](#rcs-send-message-patterns) + [ ## Sticky sending, priority order, and SMS fallback ](#rcs-send-message-fallback-summary) + [ ## Code examples ](#rcs-send-message-examples) + [ ## AI agent prompt for sending RCS messages ](#rcs-send-message-ai-prompt) + [ ## Delivery receipt handling ](#rcs-send-message-delivery-receipts) ## Sending patterns AWS End User Messaging supports three patterns for sending RCS messages. Each pattern determines how the service selects an origination identity and whether automatic SMS fallback is available. **RCS sending patterns** | Pattern | How it works | SMS fallback | When to use | | --- | --- | --- | --- | | Pool-based (recommended) | Specify a pool ID as the origination identity. The service selects the best identity from the pool. | Yes | All use cases. Provides automatic channel selection and SMS fallback with compliance-safe routing. | | Account-level | Omit the origination identity. The service selects from all available identities in your account. | Yes | Simple setups with a single use case. Not recommended for accounts with multiple use cases. | | Direct send | Specify an AWS RCS Agent ARN as the origination identity. The message is sent via RCS only. | No | RCS-or-nothing use cases, or when you manage SMS fallback outside of AWS End User Messaging. | ### Pool-based sending (recommended) Pool-based sending is the recommended approach for all RCS use cases. When you specify a pool ID as the origination identity in your `SendTextMessage` request, AWS End User Messaging selects the best origination identity from the pool based on the destination, channel availability, and sticky sending history. If the pool contains both an AWS RCS Agent and SMS phone numbers, the service attempts RCS delivery first. If RCS delivery fails, the service automatically falls back to SMS using a phone number from the same pool. Because all identities in the pool are registered for the same use case, the fallback message is always sent from an appropriate number. For details on creating and configuring pools with AWS RCS Agents, see [RCS to SMS fallback using phone pools](rcs-sms-fallback.md). ### Account-level sending When you omit the origination identity from your `SendTextMessage` request, AWS End User Messaging selects an origination identity from all available identities in your account. The service uses the origination identity priority order to determine which identity to use. For details, see [Fallback logic and priority order](rcs-sms-fallback.md#rcs-sms-fallback-logic). **Important** Account-level sending creates a compliance risk if your account contains phone numbers registered for different use cases. When RCS delivery fails and the service falls back to SMS, it may select a phone number that does not match the content of your message. For example, an OTP message could fall back to a toll-free number registered for appointment reminders, violating the registration terms for that number. To avoid this risk, use pool-based sending with one pool per use case. For details, see [Compliance risk with account-level sending](rcs-sms-fallback.md#rcs-sms-fallback-compliance-risk). ### Direct send (RCS only) When you specify an AWS RCS Agent ARN as the origination identity in your `SendTextMessage` request, AWS End User Messaging sends the message via RCS only. There is no automatic SMS fallback. If RCS delivery fails, the message is not retried on another channel. Use direct sending when: + You want RCS-or-nothing delivery. The message should only be delivered via RCS, and you prefer no delivery over SMS delivery. + You manage SMS fallback outside of AWS End User Messaging. Your application handles fallback logic independently, for example by detecting RCS delivery failure and sending a separate SMS through a different system or provider. **Note** Direct sending bypasses all SMS fallback logic. If the recipient's device or carrier does not support RCS, the message is not delivered. For most use cases, pool-based sending is recommended because it provides automatic SMS fallback at no additional cost. ## Sticky sending, priority order, and SMS fallback When you send messages through a pool or at the account level, AWS End User Messaging uses sticky sending (a 25-hour routing optimization), an origination identity priority order, and automatic SMS fallback to select the best channel and identity for each message. For complete details on how these mechanisms work, including automatic fallback, delivery receipts during fallback, and billing implications, see [RCS to SMS fallback using phone pools](rcs-sms-fallback.md). ## Code examples The following Python examples demonstrate how to send RCS messages using each of the three sending patterns. All examples use the boto3 `pinpoint-sms-voice-v2` client and the `SendTextMessage` API. ### Pool-based sending example The following example sends a message through a phone pool. The service selects the best origination identity from the pool and automatically falls back to SMS if RCS delivery is not possible. ``` import boto3 client = boto3.client('pinpoint-sms-voice-v2') response = client.send_text_message( DestinationPhoneNumber='+12065550100', OriginationIdentity='pool-a1b2c3d4e5f6g7h8i', MessageBody='Your appointment is confirmed for tomorrow at 2:00 PM.', MessageType='TRANSACTIONAL' ) print(f"Message ID: {response['MessageId']}") ``` ### Account-level sending example The following example sends a message at the account level by omitting the origination identity. The service selects an identity from all available identities in your account using the priority order. ``` import boto3 client = boto3.client('pinpoint-sms-voice-v2') response = client.send_text_message( DestinationPhoneNumber='+12065550100', MessageBody='Your verification code is 123456.', MessageType='TRANSACTIONAL' ) print(f"Message ID: {response['MessageId']}") ``` **Important** If your account contains phone numbers registered for different use cases, account-level sending may route SMS fallback through a number that does not match your message content. Use pool-based sending with one pool per use case to avoid compliance risk. ### Direct send example The following example sends a message directly through an AWS RCS Agent ARN. The message is delivered via RCS only, with no SMS fallback. ``` import boto3 client = boto3.client('pinpoint-sms-voice-v2') response = client.send_text_message( DestinationPhoneNumber='+12065550100', OriginationIdentity='arn:aws:sms-voice:us-east-1:123456789012:rcs-agent/rcs-a1b2c3d4', MessageBody='Welcome to our RCS channel! Reply HELP for assistance.' ) print(f"Message ID: {response['MessageId']}") ``` **Note** If the recipient's device or carrier does not support RCS, the message is not delivered. No SMS fallback is attempted. Use this pattern only when you want RCS-or-nothing delivery or when you manage SMS fallback outside of AWS End User Messaging. ## AI agent prompt for sending RCS messages If you use a generative AI coding assistant or AI agent, you can use the following prompt to get help sending RCS messages using the AWS CLI or SDK. **Note** Copy the following prompt and paste it into your AI agent or coding assistant: ``` ## RCS Messaging Assistant Prompt Help me send RCS messages using AWS End User Messaging SMS with the `pinpoint-sms-voice-v2` service. Show me exact CLI commands and Python/boto3 examples. Ask me for my details before generating any commands. **Important rules for generating commands:** - The API is `send-text-message` — the same command used for SMS. There is NO separate RCS send API. - There is NO `describe-messages` API. Do not generate it. - The boto3 method is `send_text_message` on the `pinpoint-sms-voice-v2` client. - Use the term "testing" — NOT "sandbox". **Prerequisites:** I have an existing RCS agent (created via the setup process) and a verified test device. ### Pattern 1: Direct RCS sending (simplest, good for testing) Send directly through my RCS Agent ARN. RCS-only delivery, no SMS fallback. If the recipient's device doesn't support RCS, the message is not delivered. CLI: `send-text-message --destination-phone-number --origination-identity --message-body "" --message-type ` Returns `MessageId`. ### Pattern 2: Pool-based sending (recommended for production) Send through a phone pool containing my RCS agent (and optionally SMS phone numbers for fallback). The service tries RCS first, then falls back to SMS asynchronously if no RCS signal within 25 seconds. This is NOT synchronous fallback — the SMS is sent as a separate attempt after the timeout. To set up a pool: - `create-pool --origination-identity --message-type TRANSACTIONAL` → returns `PoolId` - Optionally add SMS numbers: `associate-origination-identity --pool-id --origination-identity ` CLI: `send-text-message --destination-phone-number --origination-identity --message-body "" --message-type ` ### Pattern 3: Account-level sending Send without specifying `--origination-identity`. The service auto-selects the best identity from the account. CLI: `send-text-message --destination-phone-number --message-body "" --message-type ` **Compliance warning:** If the account has multiple RCS agents, SMS numbers, or different use cases, the service picks an identity automatically — which may not be the intended one. Use pool-based or direct sending for explicit control over which identity is used. ### Delivery verification - For testing: check the test device directly — the message appears from the branded RCS agent. - For production: configure event destinations BEFORE sending using `create-event-destination` (SNS, CloudWatch Logs, or Firehose). Event destinations do not retroactively capture events for already-sent messages. - CloudWatch metrics in `AWS/SMSVoice` namespace provide aggregate delivery statistics. ### Behavioral notes - Sticky sending: the service remembers the last successful identity per destination number for 25 hours. - Pool-based sending is recommended for production because it provides automatic SMS fallback. - All three patterns use the same `send-text-message` API — the only difference is what you pass (or don't pass) as `--origination-identity`. --- **Before generating commands, ask me for:** - Which sending pattern I want to use (direct, pool-based, or account-level) - My RCS Agent ARN - My pool ID (if using pool-based sending) - Destination phone number in E.164 format - Message type (TRANSACTIONAL or PROMOTIONAL) - Message text ``` ## Delivery receipt handling AWS End User Messaging provides delivery receipts for RCS messages through Amazon EventBridge and configuration set event destinations. Delivery receipts indicate the final status of your message and which channel was used for delivery. To learn how to set up event destinations to capture delivery receipts and other message events, see [Event destinations in AWS End User Messaging SMS](configuration-sets-event-destinations.md). ### Delivery status values The following delivery status values apply to RCS messages: DELIVERED The message was successfully delivered to the recipient's device. PENDING The message has been accepted by the RCS infrastructure but delivery confirmation has not yet been received. The message may still be delivered. EXPIRED The message was not delivered within the allowed time window. For RCS messages with SMS fallback, this status applies to the RCS attempt before fallback occurs. UNDELIVERABLE The message could not be delivered. This can occur when the recipient's device is permanently unreachable or the phone number is invalid. REJECTED The message was rejected by the RCS infrastructure or carrier. This can occur due to content policy violations or carrier-level filtering. ### Channel attribution Delivery receipts include channel attribution that indicates whether the message was delivered via RCS or SMS. This is important for understanding your delivery mix and for billing purposes. + When a message is delivered via RCS, the delivery receipt indicates RCS as the delivery channel and includes the AWS RCS Agent identity. + When a message falls back to SMS, the delivery receipt indicates SMS as the delivery channel and includes the SMS phone number identity that was used for delivery. + When a direct send (AWS RCS Agent ARN) fails, the delivery receipt indicates RCS as the attempted channel with a failure status. No SMS fallback receipt is generated. For details on RCS CloudWatch metrics and monitoring delivery patterns, see [RCS CloudWatch metrics and monitoring](rcs-monitoring.md). For information about how delivery channel affects billing, see [RCS billing and pricing model](rcs-billing.md). # Receiving inbound RCS messages AWS End User Messaging supports two-way RCS messaging, allowing you to receive text messages from your customers. Inbound RCS messages follow the same pattern as SMS two-way messaging: incoming messages are delivered to an Amazon SNS topic that you configure, and you process them using Lambda functions or other SNS subscribers. **Important** In order to consume inbound RCS messages, you must set up a two-way messaging SNS topic on your AWS RCS Agent. Two-way messaging is disabled by default when you create an agent. After you enable it and configure an SNS topic, inbound messages are delivered to that topic. Customers are charged for all inbound RCS messages at standard rates. This section explains how two-way RCS messaging works, how to enable it for your AWS RCS Agent, the inbound message payload format, and how to manage keywords. For information about managing AWS RCS Agents, see [Managing RCS agents](rcs-agents.md). For information about sending RCS messages, see [Sending RCS messages](rcs-send-message.md). **Topics** + [ ## How two-way RCS messaging works ](#rcs-inbound-how-it-works) + [ ## Configuring your two-way messaging destination ](#rcs-inbound-enable) + [ ## Inbound message payload format ](#rcs-inbound-payload) + [ ## Supported message types ](#rcs-inbound-text-only) + [ ## Keyword management for RCS ](#rcs-inbound-keywords) + [ ## Processing inbound messages with Lambda ](#rcs-inbound-lambda) + [ ## Best practices for inbound RCS messaging ](#rcs-inbound-best-practices) ## How two-way RCS messaging works When a customer sends a text message to your AWS RCS Agent, AWS End User Messaging receives the message and publishes it to an Amazon SNS topic that you designate. From there, you can process the message using any SNS subscriber, such as a Lambda function, an Amazon SQS queue, or an HTTP/HTTPS endpoint. The two-way RCS messaging flow works as follows: 1. A customer sends a text message to your AWS RCS Agent from their RCS-capable device. 1. AWS End User Messaging receives the inbound message and evaluates it against your configured keywords. If the message matches a keyword, the service sends the configured auto-response (if any). 1. AWS End User Messaging publishes the message payload as a JSON object to the Amazon SNS topic that you configured for two-way messaging on the AWS RCS Agent. 1. Your SNS subscribers (for example, a Lambda function) receive the message payload and process it according to your application logic. RCS in AWS End User Messaging currently supports inbound text messages. If a customer sends a media message (such as an image or video) to your AWS RCS Agent, the message is logged with an IGNORED status. Your application does not receive media messages through the SNS topic. ## Configuring your two-way messaging destination To receive and process inbound RCS messages in your application, you must enable two-way messaging and configure a destination on your AWS RCS Agent. Two-way messaging is disabled by default. When you enable it, you specify an Amazon SNS topic where AWS End User Messaging delivers inbound messages. You can configure the destination using the AWS End User Messaging console or the API. ------ #### [ Console ] **To configure your two-way messaging destination using the console** 1. Open the AWS End User Messaging console. 1. In the navigation pane, choose **RCS agents**. 1. Choose the AWS RCS Agent that you want to configure. 1. Choose the **Two-way messaging** tab. 1. Choose **Edit settings**. 1. Toggle **Enable two-way messaging** to on. 1. For **SNS topic**, choose an existing Amazon SNS topic or create a new one. This is the topic where inbound messages are published. 1. Choose **Save**. ------ #### [ AWS CLI ] To configure your two-way messaging destination using the API, call the `UpdateRcsAgent` API with the following parameters: + `two-way-enabled` — Set to `true` to enable two-way messaging. + `two-way-channel-arn` — The ARN of the Amazon SNS topic where inbound messages are published. + `two-way-channel-role` — The ARN of the IAM role that grants AWS End User Messaging permission to publish messages to the SNS topic. The following example configures the two-way messaging destination using the AWS CLI: ``` aws pinpoint-sms-voice-v2 update-rcs-agent \ --rcs-agent-id rcs-a1b2c3d4 \ --two-way-enabled \ --two-way-channel-arn arn:aws:sns:us-east-1:123456789012:MyRCSInboundTopic \ --two-way-channel-role arn:aws:iam::123456789012:role/SMSVoiceSNSPublishRole ``` ------ ### SNS topic permissions The Amazon SNS topic that you configure for two-way RCS messaging must allow AWS End User Messaging to publish messages to it. You have two options for granting access. #### Option 1: Use an IAM role Create an IAM role that AWS End User Messaging can assume to publish messages to your SNS topic. The role needs both a trust policy and a permission policy. The following is the **trust policy** for the IAM role. Replace *accountId* with the unique ID for your AWS account. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "SMSVoice", "Effect": "Allow", "Principal": { "Service": "sms-voice.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "accountId" } } } ] } ``` The following is the **permission policy** for the IAM role. The `SMSVoiceAllowSNSPublish` Sid allows publishing to Amazon SNS topics and the `SMSVoiceAllowEncryptedSNSTopics` Sid is optional for encrypted Amazon SNS topics. Make the following changes: + Replace *partition* with the AWS partition that you use AWS End User Messaging in. + Replace *region* with the AWS Region that you use AWS End User Messaging in. + Replace *accountId* with the unique ID for your AWS account. + Replace *snsTopicName* with the name of the Amazon SNS topic that receives inbound messages. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "SMSVoiceAllowSNSPublish", "Effect": "Allow", "Action": "sns:Publish", "Resource": "arn:partition:sns:region:accountId:snsTopicName", "Condition": { "StringEquals": { "aws:ResourceAccount": "accountId" } } }, { "Sid": "SMSVoiceAllowEncryptedSNSTopics", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey*" ], "Resource": "*", "Condition": { "StringEquals": { "kms:EncryptionContext:aws:sns:topicArn": "arn:partition:sns:region:accountId:snsTopicName", "aws:CalledViaLast": "sns.amazonaws.com" } } } ] } ``` #### Option 2: Use an SNS topic policy Alternatively, add a policy statement directly to the SNS topic that allows AWS End User Messaging to publish messages. Replace *snsTopicArn* with the ARN of your SNS topic. ``` { "Effect": "Allow", "Principal": { "Service": "sms-voice.amazonaws.com" }, "Action": "sns:Publish", "Resource": "snsTopicArn" } ``` ## Inbound message payload format When your AWS RCS Agent receives an inbound text message, AWS End User Messaging publishes a JSON payload to the configured Amazon SNS topic. The RCS inbound message payload uses the same format as SMS two-way messaging: ``` { "originationNumber": "+14255550182", "destinationNumber": "+12125550101", "messageKeyword": "JOIN", "messageBody": "EXAMPLE", "inboundMessageId": "cae173d2-66b9-564c-8309-21f858e9fb84", "previousPublishedMessageId": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" } ``` The inbound message payload contains the following fields: **Inbound RCS message payload fields** | Field | Description | | --- | --- | | `originationNumber` | The phone number that sent the inbound message (the customer's phone number). | | `destinationNumber` | The identifier of the AWS RCS Agent that received the message. | | `messageKeyword` | The registered keyword that matches the inbound message, if any. Keywords are evaluated against the beginning of the message body. | | `messageBody` | The text content of the inbound message. | | `inboundMessageId` | A unique identifier for the inbound message. | | `previousPublishedMessageId` | The unique identifier of the outbound message that the customer is responding to, if the inbound message is a reply to a previous outbound message. | ## Supported message types RCS in AWS End User Messaging currently supports receiving inbound text messages. When a customer sends a text message to your AWS RCS Agent, the message is delivered to your configured Amazon SNS topic for processing. If a customer sends a media message (such as an image, video, or file) to your AWS RCS Agent, AWS End User Messaging logs the message with an IGNORED status. Media messages are not delivered to your SNS topic and are not processed by your application. No error is returned to the sender. ## Keyword management for RCS Keywords allow you to configure automatic responses when customers send specific words or phrases to your AWS RCS Agent. When an inbound message matches a configured keyword, AWS End User Messaging sends the associated auto-response message back to the customer. For RCS, keywords are configured on the AWS RCS Agent and apply to all associated RCS for Business IDs (testing agent and country launch agents). You can configure up to 30 keywords per AWS RCS Agent. To manage keywords for your AWS RCS Agent, use the AWS End User Messaging console or the API. For general information about keyword management, see [Keywords in AWS End User Messaging SMS](keywords.md). **Note** Keywords configured on the AWS RCS Agent apply to all associated registrations. You cannot set different keywords for your testing agent and country launch agents independently. ## Processing inbound messages with Lambda A common pattern for processing inbound RCS messages is to subscribe a Lambda function to the Amazon SNS topic configured for two-way messaging. The Lambda function receives the inbound message payload and can implement your application logic, such as responding to customer inquiries, processing commands, or routing messages to other systems. The following Python example shows a Lambda function that processes inbound RCS messages and sends a response using the `SendTextMessage` API: ``` import json import boto3 sms_client = boto3.client('pinpoint-sms-voice-v2') def lambda_handler(event, context): # Parse the SNS message for record in event['Records']: sns_message = json.loads(record['Sns']['Message']) origination_number = sns_message['originationNumber'] message_body = sns_message['messageBody'] keyword = sns_message.get('messageKeyword', '') print(f"Received message from {origination_number}: {message_body}") # Process the message and determine a response if keyword.upper() == 'HELP': response_text = 'Available commands: HELP, STATUS, STOP' elif keyword.upper() == 'STATUS': response_text = 'Your account is active. No action needed.' else: response_text = ( f'Thanks for your message. ' f'Reply HELP for available commands.' ) # Send a response back to the customer try: response = sms_client.send_text_message( DestinationPhoneNumber=origination_number, OriginationIdentity='pool-a1b2c3d4e5f6g7h8i', MessageBody=response_text, MessageType='TRANSACTIONAL' ) print(f"Response sent. Message ID: {response['MessageId']}") except Exception as e: print(f"Failed to send response: {str(e)}") return {'statusCode': 200} ``` In this example, the Lambda function: 1. Parses the inbound message payload from the SNS event. 1. Checks the `messageKeyword` field to determine the customer's intent. 1. Sends a response using pool-based sending (recommended) through the `SendTextMessage` API. The pool handles channel selection automatically. **Note** When sending responses to inbound messages, use pool-based sending to ensure automatic SMS fallback if the customer's device no longer supports RCS. For details on sending patterns, see [Sending RCS messages](rcs-send-message.md). ## Best practices for inbound RCS messaging Follow these best practices when implementing two-way RCS messaging: + **Implement error handling** — Your Lambda function or SNS subscriber should handle errors gracefully. If your function fails to process a message, configure a dead-letter queue (DLQ) on the SNS subscription to capture unprocessed messages for later retry. + **Send fallback responses** — When your application receives a message it cannot process, send a helpful fallback response rather than leaving the customer without a reply. For example, respond with available commands or direct the customer to an alternative support channel. + **Use pool-based sending for responses** — When sending responses to inbound messages, use pool-based sending to ensure automatic SMS fallback. This guarantees that your response reaches the customer even if their device no longer supports RCS. + **Monitor message processing** — Use Amazon CloudWatch metrics to monitor your inbound message volume and processing success rate. Set up alarms for unusual patterns, such as a sudden increase in inbound messages or a high rate of processing failures. For details on RCS metrics, see [RCS CloudWatch metrics and monitoring](rcs-monitoring.md). + **Handle keyword responses consistently** — Ensure that keyword auto-responses and your application's programmatic responses do not conflict. If you configure a keyword auto-response for a specific keyword, your Lambda function still receives the message. Design your function to avoid sending a duplicate response for keywords that already have auto-responses configured. # Launching RCS in countries After you have tested your RCS messaging integration using a testing agent, the next step is to launch your AWS RCS Agent in one or more countries. Each country launch creates a separate RCS for Business ID that is approved for each carrier in that country. AWS End User Messaging supports RCS country launches in the United States and Canada. The country launch process follows this path: you create an AWS RCS Agent, submit a testing registration to get a testing agent, and then submit one or more country launch registrations. Each country launch registration goes through a separate approval process for each carrier in that country. **Note** The AWS End User Messaging console presents AWS RCS Agent creation and testing registration as a single guided workflow. API users can create the AWS RCS Agent separately and could technically skip the testing registration, but we strongly recommend completing testing before submitting country launch registrations. For an overview of how the AWS RCS Agent relates to RCS for Business IDs, see [What is RCS?](rcs-overview.md). For details on creating and managing your AWS RCS Agent, see [Managing RCS agents](rcs-agents.md). **Topics** + [ ## Testing registration ](#rcs-country-launch-testing-registration) + [ ## Testing agent as a template for country launches ](#rcs-country-launch-template) + [ ## Launching in the United States ](#rcs-country-launch-us) + [ ## Launching in Canada ](#rcs-country-launch-ca) + [ ## Use case selection ](#rcs-country-launch-use-cases) + [ ## Registration state management ](#rcs-country-launch-registration-states) + [ ## Per-carrier launch status ](#rcs-country-launch-carrier-status) + [ ## Carrier approval timelines ](#rcs-country-launch-timelines) + [ ## Common registration issues and troubleshooting ](#rcs-country-launch-troubleshooting) ## Testing registration Before you can submit a country launch registration, you must first complete a testing registration for your AWS RCS Agent. The testing registration creates a testing agent (an RCS for Business ID) that you can use to validate your integration before going to production. For step-by-step instructions on creating an AWS RCS Agent and completing the testing registration, see [Getting started with RCS](rcs-getting-started.md). For details on managing test devices and sending test messages, see [Testing RCS messages](rcs-testing.md). **Important** Testing messages are charged at standard RCS rates. ## Testing agent as a template for country launches **Important** The testing agent serves as the template for all your country launch registrations. The brand configuration you set during testing registration is what gets pre-populated into each country launch form. Take time to get your testing agent configuration right before submitting country launches. When you submit a country launch registration, the AWS End User Messaging console auto-populates the registration form with the brand configuration from your testing agent. This includes your brand name, logo, banner image, brand color, description, and website URL. You can customize fields for each country launch. For example, you might adjust the consumer-facing agent name, logo, banner image, or contact information to match local requirements. Countries can have different brand assets. The testing agent provides the starting point, but each country launch can be customized independently. ## Launching in the United States To launch your AWS RCS Agent in the United States, submit a country launch registration using the `US_RCS_LAUNCH` registration type. The US launch registration requires additional information beyond what you provided for the testing registration. ### US registration requirements The US launch registration requires the following information: + **Brand information** — Auto-populated from your testing agent configuration. You can review and adjust the brand name, description, website URL, and contact information. + **Use case selection** — Select the use case category for your RCS messaging. Available categories include OTP (one-time passwords), Transactional, Promotional, and Multi-use. + **Screen recording** — You must provide a screen recording that demonstrates your RCS messaging experience. The recording should show the end-user experience of receiving and interacting with your RCS messages. This is a requirement specific to the US launch. + **Privacy policy and terms of service** — URLs to your privacy policy and terms of service pages. **Important** The screen recording requirement is specific to the US launch registration. You must provide a recording that clearly demonstrates your RCS messaging use case. Registrations submitted without a valid screen recording are rejected. ## Launching in Canada To launch your AWS RCS Agent in Canada, submit a country launch registration using the `CA_RCS_LAUNCH` registration type. The Canada launch registration has different form field requirements than the US launch. ### Canada registration requirements The Canada launch registration requires the following information: + **Brand information** — Auto-populated from your testing agent configuration. You can review and adjust the brand name, description, website URL, and contact information for the Canadian market. + **Use case selection** — Select the use case category for your RCS messaging. Available categories include OTP (one-time passwords), Transactional, Promotional, and Multi-use. + **Privacy policy and terms of service** — URLs to your privacy policy and terms of service pages. **Note** The Canada launch registration does not require a screen recording. The form field requirements differ from the US launch registration. Review the registration form carefully to ensure all required fields are completed for the Canadian market. ## Use case selection When you submit a country launch registration, you must select a use case category that describes how you intend to use RCS messaging. The use case category is reviewed by carriers as part of the approval process. The following use case categories are available: **Important** Use case examples must be provided for your agent to be launched. Select the appropriate use case, as this determines your agent's configuration and capabilities. Incorrect selection may result in delays or issues with deployment. **OTP (one-time password)** Used for account authentication or secure transaction confirmation. **Not permitted:** product updates, offers, or promotions. **Transactional** Send notifications and updates related to customer's products or services (for example, alerts, confirmations, account updates). **Not permitted:** offers, promotions, discounts, or upgrades. **Promotional** Used for offers, promotions, and marketing messages to increase sales, including reminders for incomplete transactions. **Not permitted:** OTPs, 2FA, or urgent transactional notifications. **Multi-use** Used when messaging includes both transactional and promotional messages (for example, sending a purchase confirmation followed by a related offer). **Not permitted:** OTP/2FA, password resets, or purely transactional or purely promotional use. ## Registration state management Country launch registrations go through a multi-stage approval process. You can track the progress of your registration using two sets of states: registration states and registration version states. ### Registration states The registration state tracks the overall status of your country launch registration: **CREATED** The registration has been created but not yet submitted. You can edit the registration form fields in this state. **SUBMITTED** The registration has been submitted and is awaiting review. **REVIEWING** The registration is being reviewed by the carriers. You cannot modify the registration while it is in this state. **COMPLETE** The registration has been approved and the country launch agent (RCS for Business ID) is active. Your AWS RCS Agent can send messages in this country. **REQUIRES\$1UPDATES** The registration requires changes before it can be approved. Review the feedback provided, update the required fields, and resubmit the registration. **CLOSED** The registration has been closed. The associated resources have been removed. **DELETED** The registration has been deleted. ### Registration version states Each registration can have multiple versions. The version state tracks the status of a specific version of the registration: **DRAFT** The version is being prepared and has not been submitted. You can edit the form fields in this state. **SUBMITTED** The version has been submitted for review. **REVIEWING** The version is being reviewed by the carriers. **APPROVED** The version has been approved. The country launch agent is active for this country. **DENIED** The version has been denied. Review the feedback and submit a new version with the required changes. **REVOKED** A previously approved version has been revoked. The country launch agent is no longer active. **ARCHIVED** The version has been archived. It is no longer the active version but is retained for historical reference. **DISCARDED** The version has been discarded before submission. ## Per-carrier launch status After you submit a country launch registration, each carrier in that country independently reviews and approves your AWS RCS Agent. You can track the approval status at both the individual carrier level and the country aggregate level. ### Carrier states Each carrier in a country has one of the following approval states: **PENDING** The carrier is reviewing your agent. No action is required from you. **ACTIVE** The carrier has approved your agent. Your AWS RCS Agent can send RCS messages to recipients on this carrier's network. **REJECTED** The carrier has rejected your agent. Review the rejection reason and submit a new registration version with the required changes. ### Country aggregate states The country-level aggregate state summarizes the carrier approval status across all carriers in a country: **PENDING** All carriers in the country are still reviewing your agent. No carriers have approved or rejected the agent yet. **PARTIAL** At least one carrier has approved your agent, but not all carriers have completed their review. Your AWS RCS Agent can send messages to recipients on approved carriers. **ACTIVE** All carriers in the country have approved your agent. Your AWS RCS Agent has full reach in this country. **REJECTED** All carriers in the country have rejected your agent. Your AWS RCS Agent can send messages in a country as soon as at least one carrier in that country has approved the agent. You do not need to wait for all carriers to approve before you can start sending RCS messages. When a recipient is on a carrier that has not yet approved your agent, AWS End User Messaging automatically falls back to SMS if you are using pool-based or account-level sending. As additional carriers approve your agent, your RCS reach in that country increases. To view the per-carrier launch status for your AWS RCS Agent, use the `DescribeRcsAgentCountryLaunchStatus` API or navigate to the **Country launch status** tab on the agent details page in the AWS End User Messaging console. ## Carrier approval timelines Carrier approval for RCS country launches is a multi-step process that involves review by each carrier in the target country. Approval timelines vary depending on the carrier and the completeness of your registration. For both the United States and Canada, expect the carrier approval process to take several months from the time you submit your country launch registration. The timeline includes the initial review, any required updates, and the per-carrier rollout. To help ensure a smooth approval process: + Complete all required registration fields accurately before submitting. + For US launches, provide a clear and complete screen recording that demonstrates your RCS messaging use case. + Respond promptly to any REQUIRES\$1UPDATES feedback from the review process. + Ensure your privacy policy and terms of service URLs are accessible and up to date. ## Common registration issues and troubleshooting The following sections describe common issues that you might encounter during the country launch registration process and how to resolve them. ### Registration requires updates If your registration enters the REQUIRES\$1UPDATES state, review the feedback provided in the registration details. Common reasons include: + Incomplete or inaccurate brand information. + Missing or invalid screen recording (US launches only). + Privacy policy or terms of service URLs that are inaccessible or do not meet requirements. + Use case description that does not clearly explain your intended messaging purpose. Update the required fields and resubmit the registration. The registration returns to the SUBMITTED state and is reviewed again. ### Carrier rejected the agent If a carrier rejects your AWS RCS Agent, review the rejection reason provided in the carrier status details. Common rejection reasons include: + Brand assets that do not meet the carrier's quality standards. + Use case that does not comply with the carrier's messaging policies. + Insufficient information about the business or messaging purpose. Address the rejection feedback and submit a new registration version. Note that a rejection by one carrier does not affect the approval status with other carriers in the same country. ### Registration in review for an extended period Carrier approval timelines for the United States and Canada are typically several months. If your registration has been in the REVIEWING state for longer than expected: + Verify that your registration does not have a REQUIRES\$1UPDATES status that you may have missed. + Check the per-carrier status using the `DescribeRcsAgentCountryLaunchStatus` API to see if some carriers have already approved while others are still reviewing. + Contact AWS Support if you need assistance with a registration that has been in review for an unusually long time. ### Registration denial reasons When a registration is denied, AWS End User Messaging provides a denial reason that explains why the registration was not approved. The following table lists all RCS registration denial reasons and the recommended action for each. **RCS registration denial reasons** | Denial reason | Description | Recommended action | | --- | --- | --- | | REQUIRES\$1OFFLINE\$1REVIEW | This registration requires manual offline review. | Create a support case in the AWS Support Center. Choose the RCS Agent assistance category and include your registration ID. See [Get more information through Support for registration issues](registrations-request-support.md). | | CANNOT\$1UPDATE\$1REGISTRATION | Certain RCS agent fields cannot be modified on an existing registration. | Create a new testing registration with the corrected fields. | | IMAGE\$1URL\$1INACCESSIBLE | The image URL provided is not publicly accessible. | Provide a URL that can be accessed without authentication. Update the registration and resubmit. | | IMAGE\$1FORMAT\$1INVALID | The image must be in JPEG or PNG format. | Upload an image in the correct format and resubmit. | | IMAGE\$1RESOLUTION\$1INVALID | The image does not meet the required resolution. The logo must be 224 x 224 pixels and the banner must be 1440 x 448 pixels. | Resize the image to the required dimensions and resubmit. | | IMAGE\$1SIZE\$1EXCEEDED | The image file size exceeds the allowed limit. The logo must not exceed 50 KB and the banner must not exceed 200 KB. | Reduce the file size and resubmit. | | ACCENT\$1COLOR\$1CONTRAST\$1INSUFFICIENT | The accent color must have a contrast ratio of at least 4.5:1 relative to white. | Choose a darker accent color that meets the contrast requirement and resubmit. | | PRIVACY\$1POLICY\$1INACCESSIBLE | The privacy policy URL provided is inaccessible or invalid. | Provide a publicly accessible privacy policy URL and resubmit. | | TERMS\$1AND\$1CONDITIONS\$1INACCESSIBLE | The terms and conditions URL provided is inaccessible or invalid. | Provide a publicly accessible terms and conditions URL and resubmit. | | CONTACT\$1DETAILS\$1MISSING | At least one contact method (phone, email, or website) is required in the agent profile, and each contact value must have a corresponding label. | Add at least one contact method to your agent profile. Ensure each contact value has a corresponding label (for example, if you provide a phone number, also provide a phone label). Update the registration and resubmit. | For denial reasons that require AWS Support assistance, create a support case in the [AWS Support Center](https://console.aws.amazon.com/support/home#/case/create?issueType=service-limit-increase). Include your AWS RCS Agent ID and registration ID in the case description. # RCS CloudWatch metrics and monitoring AWS End User Messaging publishes RCS messaging metrics to CloudWatch in the `AWS/SMSVoice` namespace. You can use these metrics to monitor your RCS message delivery, track fallback behavior from RCS to SMS, and set alarms to alert you when delivery patterns change. RCS metrics are published alongside existing SMS and MMS metrics in the same namespace. **Topics** + [ ## RCS messaging metrics ](#rcs-monitoring-rcs-metrics) + [ ## Modified existing metrics with OriginationIdentityType dimension ](#rcs-monitoring-modified-metrics) + [ ## RCS metric dimensions ](#rcs-monitoring-dimensions) + [ ## Inbound RCS message metrics ](#rcs-monitoring-inbound) + [ ## Monitoring best practices for RCS ](#rcs-monitoring-best-practices) ## RCS messaging metrics The `AWS/SMSVoice` namespace includes the following metrics specific to RCS messaging. These metrics track RCS message sending, delivery, and SMS fallback. **RCS messaging metrics** | Metric | Description | Unit | Meaningful statistics | | --- | --- | --- | --- | | RCS.MessagesSent | The number of RCS messages sent. This metric counts messages that AWS End User Messaging accepted and attempted to deliver via RCS. Messages blocked by Protect or service limits are excluded from this count. | Count | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/sms-voice/latest/userguide/rcs-monitoring.html) | | RCS.MessagesDelivered | The number of RCS messages successfully delivered to the recipient's device. A message is counted as delivered when AWS End User Messaging receives a delivery confirmation from the RCS infrastructure. | Count | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/sms-voice/latest/userguide/rcs-monitoring.html) | | RCS.MessagesFallenBackToSMS | The number of messages that were initially attempted via RCS but fell back to SMS delivery. This metric helps you understand how often RCS delivery is unavailable for your recipients and can be used to track fallback rates over time. | Count | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/sms-voice/latest/userguide/rcs-monitoring.html) | ## Modified existing metrics with OriginationIdentityType dimension With the addition of RCS, several existing metrics in the `AWS/SMSVoice` namespace now support the `OriginationIdentityType` dimension. This dimension allows you to filter metrics by the type of origination identity used to send the message, including AWS RCS Agents. The following existing metrics now include the `OriginationIdentityType` dimension: + `NumberOfTextMessagePartsSent` — Filter by origination identity type to see how many text message parts were sent via each channel (phone number, sender ID, AWS RCS Agent, or pool). + `NumberOfTextMessagePartsDelivered` — Filter by origination identity type to compare delivery rates across channels. + `NumberOfMediaMessagePartsSent` — Filter by origination identity type to track media message sending by channel. + `NumberOfMediaMessagePartsDelivered` — Filter by origination identity type to compare media message delivery across channels. + `TextMessagesBlockedByProtect` — Filter by origination identity type to see which channels have messages blocked by Protect rules. + `MediaMessagesBlockedByProtect` — Filter by origination identity type to track Protect blocking by channel. Use the `OriginationIdentityType` dimension with a value of `RCS_AGENT` to isolate metrics for messages sent through your AWS RCS Agent. For more information about the available dimension values, see [RCS metric dimensions](#rcs-monitoring-dimensions). ## RCS metric dimensions You can use the following dimensions to filter and group RCS metrics. These dimensions are available for both the new RCS-specific metrics and the modified existing metrics described in the previous sections. ### OriginationIdentityType dimension The `OriginationIdentityType` dimension filters metrics by the type of origination identity used to send the message. **OriginationIdentityType dimension values** | Value | Description | | --- | --- | | PHONE\$1NUMBER | Messages sent using a phone number (long code, short code, or toll-free number). | | SENDER\$1ID | Messages sent using a sender ID. | | RCS\$1AGENT | Messages sent using an AWS RCS Agent. | | POOL | Messages sent using a phone pool. When you send through a pool, AWS End User Messaging selects the appropriate origination identity (AWS RCS Agent or phone number) automatically. | ### MessageType dimension The `MessageType` dimension filters metrics by the type of message. **MessageType dimension values** | Value | Description | | --- | --- | | TEXT | Text messages sent via RCS or SMS. | | MEDIA | Media messages (MMS). RCS in AWS End User Messaging currently supports text messages only. | | DELIVERY\$1REPORT | Delivery report messages confirming message delivery status. | **Note** The `READ_REPORT` message type is not available because read receipts are not supported in the current release of RCS in AWS End User Messaging. ## Inbound RCS message metrics The existing `NumberOfMessagesReceived` metric in the `AWS/SMSVoice` namespace now includes inbound RCS messages. You can use the `OriginationIdentityType` dimension with a value of `RCS_AGENT` to filter for inbound messages received through your AWS RCS Agent. The following dimensions are available for inbound RCS message metrics: + `OriginationIdentityType` — Use `RCS_AGENT` to filter for inbound RCS messages. + `IsoCountryCode` — Filter by the country code of the inbound message sender. + `MessageType` — Use `TEXT` to filter for text messages received via RCS. In the current release, RCS in AWS End User Messaging supports inbound text messages only. ## Monitoring best practices for RCS Use the following best practices to monitor your RCS messaging operations and identify delivery issues early. ### Track RCS versus SMS delivery rates Compare `RCS.MessagesDelivered` against `RCS.MessagesFallenBackToSMS` to understand what percentage of your messages are delivered via RCS versus SMS. A high fallback rate may indicate that many of your recipients are on carriers or devices that don't support RCS. Use the following formulas to calculate key rates: ``` RCS delivery rate = 100 * SUM(RCS.MessagesDelivered) / SUM(RCS.MessagesSent) SMS fallback rate = 100 * SUM(RCS.MessagesFallenBackToSMS) / SUM(RCS.MessagesSent) ``` Track these rates over time to identify trends as carrier and device support for RCS expands. A decreasing fallback rate indicates that more of your recipients are receiving messages via RCS. ### Set CloudWatch alarms for RCS metrics Create CloudWatch alarms to alert you when RCS messaging patterns change unexpectedly. Consider setting alarms for the following conditions: + **High fallback rate** — Set an alarm when `RCS.MessagesFallenBackToSMS` exceeds a threshold percentage of `RCS.MessagesSent`. A sudden increase in fallback may indicate an issue with your AWS RCS Agent or a carrier outage. + **Delivery rate drop** — Set an alarm when the ratio of `RCS.MessagesDelivered` to `RCS.MessagesSent` drops below your expected delivery rate. + **Inbound message volume** — If you use two-way RCS messaging, set an alarm on `NumberOfMessagesReceived` (filtered by `OriginationIdentityType = RCS_AGENT`) to detect unexpected changes in inbound message volume. # RCS billing and pricing model RCS messaging in AWS End User Messaging uses a pricing model with two cost components: an AWS message fee and a carrier fee that is passed through with no markup. This chapter explains the pricing structure for RCS messaging. For current rates, see [AWS End User Messaging Pricing](https://aws.amazon.com//end-user-messaging/pricing/). AWS End User Messaging charges for RCS messages only when they are successfully delivered to the recipient's device. You are not charged for delivery attempts that fail. If an RCS message fails and falls back to SMS, you are charged for the SMS message that is delivered, not for the failed RCS attempt. **Topics** + [ ## Billing overview ](#rcs-billing-overview) + [ ## United States pricing model ](#rcs-billing-us-pricing) + [ ## Canada pricing model ](#rcs-billing-ca-pricing) + [ ## Registration fees ](#rcs-billing-registration-fees) + [ ## Double-delivery billing ](#rcs-billing-double-delivery) + [ ## Content violation fees ](#rcs-billing-content-violations) + [ ## Bill transparency ](#rcs-billing-transparency) ## Billing overview RCS billing in AWS End User Messaging has the following components: + **Message fees** — Per-message charges for outbound and inbound RCS messages, based on message segments. + **Carrier fees** — Pass-through charges from carriers with no AWS markup. + **Registration fees** — One-time and recurring fees for agent setup, brand vetting, and maintenance. Each component appears as a separate line item on your AWS bill, giving you visibility into your RCS messaging costs. ## United States pricing model RCS messaging in the United States uses a message type called **Rich RCS**. Rich RCS messages are metered per 160-character segment, similar to SMS. Messages exceeding 160 characters are charged for multiple segments. Each outbound or inbound Rich RCS message has two cost components: **Message transport fee** The per-segment fee charged by AWS for processing and delivering the RCS message. **Carrier fee (pass-through)** The per-segment fee charged by the carrier for RCS message delivery. AWS passes this fee through to you with no markup. Carrier fees are separate from message transport costs. The total cost per message is the message transport fee plus the carrier fee. Inbound RCS messages (messages sent from end users to your AWS RCS Agent) follow the same two-component pricing structure. **Note** RCS messages are charged only for delivered messages. This differs from SMS, which charges for requested messages. For current per-segment rates, see [AWS End User Messaging Pricing](https://aws.amazon.com//end-user-messaging/pricing/). ## Canada pricing model RCS messaging in Canada uses two message types: **RCS Basic** Messages up to 160 characters. Charged per message. **RCS Single** Messages exceeding 160 characters. Billed as a single message, not as multiple segments. This differs from the United States, where Rich RCS messages exceeding 160 characters are metered per 160-character segment similar to SMS. Each outbound or inbound RCS message in Canada has two cost components: a message transport fee and a carrier pass-through fee. **Note** RCS messages are charged only for delivered messages. This differs from SMS, which charges for requested messages. For current rates, see [AWS End User Messaging Pricing](https://aws.amazon.com//end-user-messaging/pricing/). ## Registration fees Launching an AWS RCS Agent requires registration with the RCS infrastructure provider. The following carrier pass-through fees apply to the registration process: **One-time agent setup fee** A one-time fee charged when you create and register your AWS RCS Agent. This covers the initial setup and verification of your agent with the RCS infrastructure provider. **Annual brand vetting fee** An annual fee for verifying your brand identity. Brand vetting confirms that your organization is legitimate and authorized to send RCS messages under your brand name. **Monthly agent maintenance fee** A recurring monthly fee for maintaining your active AWS RCS Agent registration with the RCS infrastructure provider. These registration fees are carrier pass-through charges. For current registration fee amounts, see [AWS End User Messaging Pricing](https://aws.amazon.com//end-user-messaging/pricing/). **Important** RCS registration fees are excluded from Enterprise Discount Program (EDP) discounts. These fees are pass-through charges from the RCS infrastructure provider and are not eligible for AWS volume discounts. Registration fees appear as separate line items on your AWS bill. For details on how charges are categorized, review your AWS Cost and Usage Report. ## Double-delivery billing When AWS End User Messaging sends an RCS message with SMS fallback enabled (through pool-based or account-level sending), the service attempts RCS delivery first. If RCS delivery fails, the service falls back to SMS. Under normal circumstances, the RCS message is revoked before the SMS fallback message is delivered. In this case, you are charged only for the SMS message that was successfully delivered. In rare cases, both the RCS message and the SMS fallback message may be delivered to the recipient. This can happen if the RCS message is delivered after the revocation window but before the SMS message arrives. When dual delivery occurs, you are charged for both the RCS message and the SMS message. **Note** Dual delivery is uncommon. AWS End User Messaging is designed to revoke the RCS message before initiating SMS fallback. Monitor your delivery receipts and CloudWatch metrics to track delivery channel attribution. For more information about RCS metrics, see [RCS CloudWatch metrics and monitoring](rcs-monitoring.md). ## Content violation fees It is the responsibility of any RCS message sender to comply with country laws and regulations for messaging, as well as carrier policies. Carriers may impose penalty fees for RCS messages that violate their message content policies. These penalties are carrier-imposed charges that AWS may pass through to customers that send RCS messages that carriers flag as violating their message content policies. Carriers typically categorize content violations into the following tiers: **Tier 1 — Phishing, smishing, and social engineering** Social engineering refers to the practice of targeting individuals in a way that manipulates them to reveal private information such as credit card numbers or social security numbers. **Tier 2 — Illegal content** Content must be legal in all 50 states and federally. Illegal content includes, but is not limited to, cannabis, marijuana, CBD, illegal prescriptions, and solicitation. **Tier 3 — Other violations** All other commercial messaging violations that breach federal, state, or local laws, regulations, or carrier codes of conduct on prohibited content. For more information about content violation fee amounts, see [AWS End User Messaging Pricing](https://aws.amazon.com//end-user-messaging/pricing/). ## Bill transparency RCS charges appear as separate line items on your AWS bill, allowing you to distinguish between the following cost categories: + RCS message fees (AWS charges) + RCS carrier fees (pass-through charges) + RCS registration fees (pass-through charges) + SMS message fees (for messages that fell back from RCS to SMS) This separation helps you understand your messaging costs and identify opportunities to optimize your spending. For detailed billing information, review your AWS Cost and Usage Report.