Oracle Cloud Infrastructure Documentation

Workflow: Sending Text Messages by Using the Oracle Radio WebSocket API

Send normal or critical text to a subscribed Radio channel and process confirmation, delivery, and denial results.

Send a Normal Message

  1. Follow Sending an Oracle Radio WebSocket Text Message to send TEXT_MESSAGE with critical set to false.

    {
  "type": "TEXT_MESSAGE",
  "channel": "operations",
  "text": "All units stand by for briefing at 1400",
  "critical": false,
  "clientMessageId": "normal-message-123"
}

  2. Wait for TEXT_MESSAGE_SENT or ERROR on the initiating connection. Match the clientMessageId to the pending request. For success, confirm the channel and critical values, and record recipientCount when it is present. An error for one identifier doesn't reject other pending messages on the same channel.

  3. On eligible other connections subscribed to the channel, process TEXT_MESSAGE_RECEIVED. Do not wait for the initiating connection to receive its own delivery event.

Send a Critical Message

  1. Verify that the user has the additional critical-message permission and channel access described in Sending an Oracle Radio WebSocket Text Message.

  2. Follow Sending an Oracle Radio WebSocket Text Message to send TEXT_MESSAGE with critical set to true.

    {
  "type": "TEXT_MESSAGE",
  "channel": "operations",
  "text": "Evacuate the east entrance immediately",
  "critical": true,
  "clientMessageId": "critical-message-123"
}

  3. Match TEXT_MESSAGE_SENT or ERROR to this request's clientMessageId. A successful response has critical set to true. Eligible other connections receive TEXT_MESSAGE_RECEIVED with the critical indicator.

Handle Denials and Errors

Use the following guidance to handle denials and errors during this workflow.

ResultClient action
ERROR with NotAuthorizedOrNotFoundDo not report the correlated message as sent. The response doesn't disclose whether permissions, channel access, membership, or resource absence caused the failure. Verify the target and subscription, and have an authorized administrator review permissions. Don't downgrade a critical message automatically.
Validation ERRORCorrect the message parameters. After correcting a confirmed rejection, use a new identifier for a deliberate new attempt. Reusing the old identifier can replay the cached error even when the input changes.
Internal ERROR, WebSocket disconnect, or no terminal responseTreat delivery as indeterminate. If retrying the unchanged request, retain its original clientMessageId. A cached result can replay without another send, but no fixed retry-protection period or guarantee across reconnects or service restarts is established. Don't automatically use a new identifier or repeat a request that had no identifier. Follow the recovery procedure if disconnected.

A cached rejection can replay even after access is corrected. Use a new identifier only for a deliberate new attempt after a confirmed rejection, not to bypass an uncertain delivery result. For further checks, see message troubleshooting.