RCS-Nachrichten senden

AWS End User Messaging verwendet dieselbe SendTextMessage API sowohl für die RCS- als auch für die SMS-Zustellung. Wie der Dienst Ihre Nachricht weiterleitet, hängt von der Absenderidentität ab, die Sie in der Anfrage angeben. Sie können Nachrichten über einen Telefonpool (empfohlen), auf Kontoebene oder direkt über einen AWS-RCS-Agenten-ARN senden.

In diesem Abschnitt werden die drei Versandmuster und die Interpretation von Lieferbelegen erläutert und Codebeispiele bereitgestellt. Weitere Informationen zum Versand per Direktversand, zur Prioritätsreihenfolge der Absenderidentität und zum automatischen SMS-Fallback finden Sie unter. Fallback von RCS zu SMS mithilfe von Telefonpools Einzelheiten zur Verwaltung von AWS RCS-Agenten finden Sie unterVerwaltung von RCS-Agenten.

Muster senden

AWS End User Messaging unterstützt drei Muster für das Senden von RCS-Nachrichten. Jedes Muster bestimmt, wie der Dienst eine Ausgangsidentität auswählt und ob automatisches SMS-Fallback verfügbar ist.

Poolbasiertes Senden (empfohlen)

Poolbasiertes Senden ist der empfohlene Ansatz für alle RCS-Anwendungsfälle. Wenn Sie in Ihrer SendTextMessage Anfrage eine Pool-ID als Ausgangsidentität angeben, wählt AWS End User Messaging auf Grundlage des Ziels, der Kanalverfügbarkeit und des Sticky-Sendeverlaufs die beste Ausgangsidentität aus dem Pool aus.

Wenn der Pool sowohl einen AWS RCS-Agenten als auch SMS-Telefonnummern enthält, versucht der Service zuerst, über RCS zuzustellen. Wenn die RCS-Zustellung fehlschlägt, greift der Service automatisch auf SMS zurück und verwendet dabei eine Telefonnummer aus demselben Pool. Da alle Identitäten im Pool für denselben Anwendungsfall registriert sind, wird die Fallback-Nachricht immer von einer geeigneten Nummer gesendet.

Einzelheiten zur Erstellung und Konfiguration von Pools mit AWS RCS-Agenten finden Sie unterFallback von RCS zu SMS mithilfe von Telefonpools.

Senden auf Kontoebene

Wenn Sie die Herkunftsidentität in Ihrer SendTextMessage Anfrage weglassen, wählt AWS End User Messaging eine Absenderidentität aus allen verfügbaren Identitäten in Ihrem Konto aus. Der Dienst verwendet die Prioritätsreihenfolge der Originalidentität, um zu bestimmen, welche Identität verwendet werden soll. Details hierzu finden Sie unter Fallback-Logik und Prioritätsreihenfolge.

Direktes Senden (nur RCS)

Wenn Sie in Ihrer SendTextMessage Anfrage einen AWS-RCS-Agent-ARN als Ausgangsidentität angeben, sendet AWS End User Messaging die Nachricht nur über RCS. Es gibt kein automatisches SMS-Fallback. Wenn die RCS-Zustellung fehlschlägt, wird die Nachricht nicht auf einem anderen Kanal erneut versucht.

Verwenden Sie direktes Senden, wenn:

Automatisches Senden, Prioritätsreihenfolge und SMS-Fallback

Wenn Sie Nachrichten über einen Pool oder auf Kontoebene senden, verwendet AWS End User Messaging Sticky-Sending (eine 25-stündige Routing-Optimierung), eine Prioritätsreihenfolge der Absenderidentitäten und automatisches SMS-Fallback, um für jede Nachricht den besten Kanal und die beste Identität auszuwählen. Vollständige Informationen zur Funktionsweise dieser Mechanismen, einschließlich automatischem Fallback, Empfangsbestätigungen während des Fallbacks und Auswirkungen auf die Abrechnung, finden Sie unter. Fallback von RCS zu SMS mithilfe von Telefonpools

Codebeispiele

Die folgenden Python-Beispiele zeigen, wie RCS-Nachrichten mit jedem der drei Sendemuster gesendet werden. Alle Beispiele verwenden den pinpoint-sms-voice-v2 Boto3-Client und die API. SendTextMessage

Beispiel für poolbasiertes Senden

Im folgenden Beispiel wird eine Nachricht über einen Telefonpool gesendet. Der Dienst wählt die beste Ausgangsidentität aus dem Pool aus und greift automatisch auf SMS zurück, wenn eine RCS-Zustellung nicht möglich ist.

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']}")
            

Beispiel für das Senden auf Kontoebene

Im folgenden Beispiel wird eine Nachricht auf Kontoebene gesendet, wobei die ursprüngliche Identität weggelassen wird. Der Dienst wählt anhand der Prioritätsreihenfolge eine Identität aus allen verfügbaren Identitäten in Ihrem Konto aus.

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']}")
            

Beispiel für direktes Senden

Im folgenden Beispiel wird eine Nachricht direkt über einen AWS-RCS-Agenten-ARN gesendet. Die Nachricht wird nur über RCS ohne SMS-Fallback zugestellt.

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']}")
            

Aufforderung des AI-Agenten zum Senden von RCS-Nachrichten

Wenn Sie einen generativen KI-Codierungsassistenten oder einen AI-Agenten verwenden, können Sie die folgende Aufforderung verwenden, um Hilfe beim Senden von RCS-Nachrichten über die AWS CLI oder das SDK zu erhalten.

## 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 <E.164>
--origination-identity <agent-arn> --message-body "<text>"
--message-type <TRANSACTIONAL|PROMOTIONAL>`

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 <rcs-agent-id> --message-type TRANSACTIONAL` → returns `PoolId`
- Optionally add SMS numbers: `associate-origination-identity --pool-id <id>
  --origination-identity <phone-number-id>`

CLI: `send-text-message --destination-phone-number <E.164>
--origination-identity <pool-id> --message-body "<text>"
--message-type <TRANSACTIONAL|PROMOTIONAL>`

### 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 <E.164>
--message-body "<text>" --message-type <TRANSACTIONAL|PROMOTIONAL>`

**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
            

Bearbeitung von Lieferscheinen

AWS End User Messaging stellt Empfangsbestätigungen für RCS-Nachrichten über Amazon EventBridge und konfigurierte Ereignisziele bereit. Zustellungsbelege geben den endgültigen Status Ihrer Nachricht an und geben an, welcher Kanal für die Zustellung verwendet wurde. Informationen zum Einrichten von Ereigniszielen zur Erfassung von Zustellungsbestätigungen und anderen Nachrichtenereignissen finden Sie unter. Veranstaltungsziele in AWS End User Messaging SMS

Werte für den Lieferstatus

Die folgenden Werte für den Zustellungsstatus gelten für RCS-Nachrichten:

Kanalzuweisung

Zustellungsbestätigungen beinhalten eine Kanalzuweisung, die angibt, ob die Nachricht per RCS oder SMS zugestellt wurde. Dies ist wichtig, um Ihren Versandmix zu verstehen und für Abrechnungszwecke.

Einzelheiten zu CloudWatch RCS-Metriken und zur Überwachung von Zustellungsmustern finden Sie unter. CloudWatch RCS-Metriken und Überwachung Informationen darüber, wie sich der Lieferkanal auf die Abrechnung auswirkt, finden Sie unterRCS-Abrechnungs- und Preismodell.