Eftersom RCS kräver att mottagarens enhet och operatör har stöd för tekniken, används fallback-logiken för att garantera leverans (exempelvis genom att automatiskt slå om till vanlig SMS-text) om ett RCS-meddelande inte kan levereras.


Översikt: Var finns Fallback-logiken? #

I API-specifikationen är fallback integrerat på två nivåer:

  1. Konfiguration (Requests): När du skickar meddelanden anger du instruktioner för hur systemet ska agera om RCS misslyckas.
  2. Statusuppföljning (Responses): När du hämtar data om skickade meddelanden kan du se exakt status och orsak till eventuell fallback.

1. Konfiguration av Fallback vid sändning (Requests) #

Fallback-inställningar kan definieras i tre centrala POST-endpoints när meddelanden initieras. Dessa endpoints använder datastrukturerna BundleRequest, ConversationRequest och MessageRequest:

  • POST /bundles – Skapar en samling (bundle) av meddelanden till en eller flera mottagare.
  • POST /conversations – Startar en ny tvåvägskonversation med ett första meddelande.
  • POST /conversations/{conversation} – Skickar ett nytt meddelande i en pågående konversation.

Konfigurationsparametrar #

Följande parametrar skickas med i JSON-bodyn för att styra fallback-beteendet:

ParameterTypBeskrivning
fallbackPolicyText (Enum)Bestämmer vilken strategi/policy som ska tillämpas. Refererar till FallbackPolicy (giltiga värden: NoFallback, FallbackOnNoCapability, FallbackOnFailure, FallbackAfterTimeout, CustomerControlledFallback). Lägg till flera policys genom att kommaseparera varje enskild policy.
fallbackTimeoutSecondsIntegerTid i sekunder som systemet väntar på leveransrapport från RCS innan fallback-meddelandet triggas.
Minimum: 1
Maximum: 2147483647
fallbackMessageStringDet faktiska textmeddelandet (t.ex. SMS) som ska skickas om fallback aktiveras.
Maxlängd: 160 tecken (motsvarar standardlängden för 1 SMS). fallBack message autogenereras från Content eller Card om den inte specifikt anges i anropet.

2. Uppföljning och Status (Responses & GET) #

När du granskar skickade meddelanden eller bundles via API:ets GET-endpoints, inkluderas objektet RcsMessageFallback i svaret för att redovisa hur fallbacken har hanterats.

Detta är tillgängligt via bland annat:

  • GET /bundles/{bundle}
  • GET /bundles/{bundle}/messages
  • GET /conversations/{conversation}/messages
  • GET /conversations/{conversation}/messages/{id}

Datastrukturen RcsMessageFallback #

När du läser av ett meddelande returneras följande fält i fallback-objektet:

FältTypBeskrivning
fallbackPolicyText (enum)Den policy som är aktiv för meddelandet (NoFallback, FallbackOnNoCapability, FallbackOnFailure, FallbackAfterTimeout, CustomerControlledFallback).
fallbackTimeoutString (date-span)Det tidsspann/inställning som angavs vid uppsättning av requesten.
fallbackMessageStringTexten som angavs vid requesten.
fallbackStatusText (Enum)Aktuell status för fallback-leveransen. Refererar till FallbackStatus (giltiga värden: Unknown, Pending, Sent, Completed, Failed).
fallbackReasonStringSystemets felmeddelande eller beskrivning av varför fallback aktiverades (t.ex. ”Mottagaren saknar RCS-kapacitet”).
fallbackMessageIdString (ObjectId)Det unika ID:t för det genererade fallback-meddelandet (t.ex. Batch-ID:t i underliggande SMS-gateway) för att möjliggöra spårning.

3. Enum-definitioner #

FallbackPolicy #

Används i requests för att välja fallback-beteende.

  • Värden: NoFallback, FallbackOnNoCapability, FallbackOnFailure, FallbackAfterTimeout, CustomerControlledFallback.

FallbackStatus #

Används i responses för att visa var i processen fallback-meddelandet befinner sig.

  • Värden: Unknown, Pending, Sent, Completed, Failed.