Interface SendChoiceMessageRequest<T>

The ID of the app sending the message.

Overwrites the default callback url for delivery receipts for this message. Note that you may define a secret_for_overridden_callback_urls at the app level; this secret will be used to sign the contents of delivery receipts when the default callback URL is overridden by this property. The REST URL should be of the form: http://host[:port]/path

Explicitly define the channels and order in which they are tried when sending the message. All channels provided in this field must be configured in the corresponding Conversation API app, or the request will be rejected. Which channels the API will try and their priority is defined by: 1. channel_priority_order if available. 2. recipient.identified_by.channel_identities if available. 3. When recipient is a contact_id: - if a conversation with the contact exists: the active channel of the conversation is tried first. - the existing channels for the contact are ordered by contact channel preferences if given. - lastly the existing channels for the contact are ordered by the app priority.

Channel-specific properties. The key in the map must point to a valid channel property key as defined by the enum ChannelPropertyKeys. The maximum allowed property value length is 1024 characters.

Metadata that will be associated with the conversation in CONVERSATION mode and with the specified recipient identities in DISPATCH mode. This metadata will be propagated on MO callbacks associated with the respective conversation or user identity. Up to 2048 characters long. Note that the MO callback will always use the last metadata available. Important notes: - If you send a message with the conversation_metadata field populated, and then send another message without populating the conversation_metadata field, the original metadata will continue be propagated on the related MO callbacks. - If you send a message with the conversation_metadata field populated, and then send another message with a different value for conversation_metadata in the same conversation, the latest metadata value overwrites the existing one. So, future MO callbacks will include the new metadata. - The conversation_metadata only accepts json objects. - If you send a message in DISPATCH mode while the retention period of the app is set to 0 (note that this value is set to 0 by default), the conversation_metadata field will not be retained. Currently only returned in the message_metadata field of an Inbound Message callback.

Update strategy for the conversation_metadata field.

An arbitrary identifier that will be propagated to callbacks related to this message, including MO messages from the recipient. The correlation_id is associated with the conversation in CONVERSATION mode and with the specified recipient identities in DISPATCH mode. The MO callbacks will always include the last correlation_id available, (which is similar to how the conversation_metadata property functions). Up to 128 characters long. Important note: If you send a message in DISPATCH mode while the retention period of the app is set to 0 (note that this value is set to 0 by default), the correlation_id field will not be retained.

This field classifies the message content for use with Sinch's consent management functionality. Note that this field is currently only used with Sinch's consent management functionality, and is not referenced elsewhere by the Conversation API.

Metadata that should be associated with the message. Returned in the metadata field of a Message Delivery Receipt. Up to 1024 characters long.

Overrides the app's Processing Mode. Default value is DEFAULT.

The timeout allotted for sending the message, expressed in seconds. Passed to channels which support it and emulated by the Conversation API for channels without ttl support but with message retract/unsend functionality. Channel failover will not be performed for messages with an expired TTL.

The format is an integer with the suffix s (for seconds). Valid integer range is 3 to 315,576,000,000 (inclusive). Example values include 10s (10 seconds) and 86400s (24 hours). The SDK will take care of the formatting: example of valid input for 10 seconds: 10 (number), "10" (string), "10s" (string)