Push Notification Configuration
Using push notifications with your Conversations implementation keeps your engagement high - when another member of the conversation sends a message, your chat users can get a push notification to let them know there is activity.
New messages in a Conversation are just one event that can cause a notification. You can configure which events will send push notifications out to your chat participants, on a per Service instance basis.
Conversations integrates APN (iOS) and FCM (Android and browsers) Push Notifications for certain events. Please note that these implementations do not all have the same list of possible events to trigger push notifications. Additionally, the content and payload of your push notifications will differ based on requirements and use cases.
Conversations Service instances provide some configuration options which allow push configuration on a per Service instance basis. These options allow for:
- Selecting which of the eligible Conversations events should trigger push notifications
- Specifying the payload template for each message type (overriding the default template)
It is not currently possible to selectively register for various push notification message types on the client SDKs (iOS and Android). This capability is planned and will be delivered in a future release of the relevant SDKs.
Table of Contents
Push Notification Types
The following Push Notifications can be configured for a Conversations Service instance:
| Push Notification Type | Description |
|---|---|
| New Message | This is sent to all chat participants within a Conversation when a new Message is posted to the Conversation |
| Added to Conversation | This is sent to chat participants that have been added to a Conversation |
| Removed from Conversation | This is sent to chat participants that have been removed from a Conversation they were a member of |
Note: The default enabled flag for new Service instances for all Push Notifications is false. This means that Push will be disabled until you explicitly enable it.
Note: You may configure a sound parameter value for each of the Push Notification types (detailed below).
Push Notification Templates
Each of the Push Notification types has a default template for the payload (or notification body). Each of these templates can be overridden per Service instance via the Push Notification configuration. The templating employs very simple markup for a limited set of variables:
Template Variables
| Template Variable | Description |
|---|---|
${PARTICIPANT} |
Will be replaced with the FriendlyName of the Participant's underlying User who triggered the Push Notification (if any). The User's Identity will be used if no FriendlyName has been set. For Proxy Participants engaged via a non-chat channel, the MessagingBinding.Address will be used instead. For Group Participants engaged in group texting, the MessagingBinding.Address will be used, or the MessagingBinding.ProjectedAddress if the Participant uses a Twilio phone number and has no underlying User. |
${PARTICIPANT_FRIENDLY_NAME} |
Will be replaced with the FriendlyName of the Participant's underlying User who triggered the Push Notification (if any). The User's Identity will be used if no FriendlyName has been set. For Proxy Participants engaged via a non-chat channel, the MessagingBinding.Address will be used instead. For Group Participants, the MessagingBinding.Address will be used, or the MessagingBinding.ProjectedAddress if the Participant uses a Twilio phone number and has no underlying User. |
${PARTICIPANT_IDENTITY} |
Will be replaced with the FriendlyName of the Participant's underlying User who triggered the Push Notification (if any). The User's Identity will be used if no FriendlyName has been set. For Proxy Participants engaged via a non-chat channel, the MessagingBinding.Address will be used instead. For Group Participants, the MessagingBinding.Address will be used, or the MessagingBinding.ProjectedAddress if the Participant uses a Twilio phone number and has no underlying User. |
${PARTICIPANT_SID} |
Will be replaced with the Sid of the Participant who triggered the Push Notification (if any). The Participant's Identity will be used if no Sid is available. |
${CONVERSATION} |
Will be replaced with the UniqueName, FriendlyName or ConversationSid (if they exist, in that order of priority). These properties are tied to the Conversation related to the Push Notification. |
${CONVERSATION_FRIENDLY_NAME} |
Will be replaced with the FriendlyName, UniqueName or ConversationSid (if they exist, in that order of priority). These properties are tied to the Conversation related to the Push Notification. |
${CONVERSATION_SID} |
Will be replaced with the ConversationSid. This property is tied to the Conversation related to the Push Notification. |
${CONVERSATION_UNIQUE_NAME} |
Will be replaced with the UniqueName or ConversationSid (if they exist, in that order of priority). These properties are tied to the Conversation related to the Push Notification. |
${MESSAGE} |
Will be replaced with the body of the actual Message. Only used for notifications of type: New Message |
Note: The maximum length of the entire notification payload is 110 characters. This substring is applied after the notification payload is constructed and the variables data applied. Thus, freeform text and the variable data are compiled into a string and the first 110 characters are then used as the notification payload.
Note: Variables can be used multiple times within a template, but each variable will contribute to the maximum number of available characters.
Default Templates
| Push Notification Type | Default Template |
|---|---|
| New Message | ${CONVERSATION}:${PARTICIPANT}: ${MESSAGE} |
| Added to Conversation | You have been added to the conversation ${CONVERSATION} by ${PARTICIPANT} |
| Removed from Conversation | ${PARTICIPANT} has removed you from the conversation ${CONVERSATION} |
Configure Push Notifications
Each Push Notification type can be configured for a Service instance. The configuration allows each notification type to be enabled or disabled. This also handles custom template configuration as per the templating mechanism described above.
The following are the eligible notification type names:
NewMessageAddedToConversationRemovedFromConversation
The following are the configuration parameters used:
| parameter name | description |
|---|---|
| [type].Enabled | true if this type of push notification should be sent, false if not. Default: false |
| [type].Template | The customer template string for the notification type. |
| [type].Sound | The "sound" push payload parameter that will be set for this notification type. |
| NewMessage.BadgeCountEnabled | true if the NewMessage notification type should send a badge count value in the push payload. This parameter is only applicable to the NewMessage type. Please note that this is currently only used by the iOS APNS push notification type. |
Badge Count
This setting is only for the NewMessage notification type. Currently, only APNS push notifications for iOS will use this and include the badge property in the payload. If enabled, the value of this property will represent the count of Conversations the User is a Member of which have any unread Messages for the User.
If NewMessage.BadgeCountEnabled is set to true, decrements to the count of Conversations with unread messages will be sent to all registered iOS endpoints for that User.
Setting additional notification types requires including them in your configuration request. For instance, to include the AddedToConversation Push Notification type, you can add the following 3 rows to your curl request.
'AddedToConversation.Enabled=true' 'AddedToConversation.Template=You are now a Member of ${CONVERSATION}! Added by ${PARTICIPANT}' 'AddedToConversation.Sound=default'
Need some help?
We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd browsing the Twilio tag on Stack Overflow.