Processing Modes

By default, Conversation API always associates new messages with a Contact and a Conversation. If there's no existing contact or active conversation, new ones are created. This is the CONVERSATION mode intended to be used by the majority of apps.

This behavior may not be desired for use cases in which contacts and conversations are not leveraged, mainly unidirectional SMS campaigns. Such use cases may find the DISPATCH processing mode more attractive in order to prevent storage of unused information. Dispatch mode aims to address this necessity by handling messages without maintaining contacts and conversations.

Processing Mode	Behavior
`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`
`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

Using Dispatch Mode

Dispatch mode can be set in two ways:

On the App : dispatch mode will be applied to every new MT and MO. Conversation API won't create contacts and conversations at all.
On individual MTs : only the MT will be sent in dispatch mode. The dispatch mode won't carry over to the MO. Therefore, 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.

Limitations of Dispatch Mode

Since contacts and conversations are not created in dispatch mode, bear in mind it will limit the usage of APIs involving them. These operations will return status 400 in case a contact_id or conversation_id are provided for an app in dispatch mode: