# Processing Modes Breaking change: As of **April 16th, 2025**, a breaking change was introduced to the Conversation API. The default processing mode changed from `CONVERSATION` to `DISPATCH`. This change impacts **all new Conversation API apps** created after this date. Apps created prior to this date are unaffected by this change. Please review your configurations and update any dependencies accordingly. By default, Conversation API uses the `DISPATCH` processing mode, which handles messages without storing information about [contacts](/docs/conversation/keyconcepts/#contact) and [conversation](/docs/conversation/keyconcepts/#conversation). Note that, while this information is not stored in `DISPATCH` mode, you may still engage in two-way messaging with regular recipients. The metadata regarding the contact and conversational thread is simply not stored in Sinch's systems. You may also use the `CONVERSATION` processing mode. Each mode is described below. | Processing Mode | Behavior | | --- | --- | | `DISPATCH` | Messages are not associated with Contacts and Conversations Message retention TTL is `[0 - 7]` days. In the case of a `0` day TTL, messages aren't stored at all Message retention policy can only be `MESSAGE_EXPIRE_POLICY` as there are no conversations or contacts | | `CONVERSATION` | Messages are associated with Contacts and Conversations Message retention TTL is `[1 - 3650]` days Message retention policy can be `MESSAGE_EXPIRE_POLICY`, `CONVERSATION_EXPIRE_POLICY`, and `PERSIST_RETENTION_POLICY` | ## Setting the Processing Mode You can set the processing mode in two ways: - [On the App](/docs/conversation/api-reference/conversation/app/app_createapp#app/app_createapp/t=request&path=processing_mode): the selected processing mode will be applied to every new MT and MO. - [On individual MTs](/docs/conversation/api-reference/conversation/messages/messages_sendmessage#messages/messages_sendmessage/t=request&path=processing_strategy): only the MT will be sent in the selected processing mode. The processing mode won't carry over to the MO. For example, if the user responds a dispatch MT but the App is in `CONVERSATION` mode, a new Contact and Conversation may be created if they don't already exist. You should carefully evaluate this option as it's meant to be used by campaign dispatching services that initiate conversations. ## Notes on `CONVERSATION` mode In general, `DISPATCH` mode is simpler to use. It is the default processing mode and, although certain pieces of information are note stored while using `DISPATCH` mode, you are still able to engage in two-way message while using this default mode. However, depending on your needs, you may find a use for `CONVERSATION` mode. Below are some general considerations and guidelines for making Conversation API calls while using `CONVERSATION` mode. ### Sending messages and events Contacts are created in `CONVERSATION` mode. Therefore, when using a Conversation API app set to `CONVERSATION` mode, the following API calls can be made by including and populating the `contact_id` field of the `recipient` object: - [Send message by `contact_id`](/docs/conversation/api-reference/conversation/messages/messages_sendmessage#messages/messages_sendmessage/t=request&path=recipient&oneof=0/contact_id) - [Send event by `contact_id`](/docs/conversation/api-reference/conversation/events/events_sendevent#events/events_sendevent/t=request&path=recipient&oneof=0/contact_id) ### Listing messages Since contacts and conversations are created in `CONVERSATION` mode, these operations will return successfully `contact_id` or `conversation_id` are provided when using a Conversation API app set to `CONVERSATION` mode: - [List messages by `contact_id`](/docs/conversation/api-reference/conversation/messages/messages_listmessages#messages/messages_listmessages/t=request&in=query&path=contact_id) - [List messages by `conversation_id`](/docs/conversation/api-reference/conversation/messages/messages_listmessages#messages/messages_listmessages/t=request&in=query&path=conversation_id)