Twilio functional guide
The following guide describes the capabilities of Twilio SMS within Redpoint Interaction (RPI), how sending messages/synchronizing state data works, and links to other resources.
Key capabilities
The Twilio SMS connector providers the following key capabilities:
Channel Configuration
The ability to send SMS messages via an Interaction using an Offer Activity and/or Queue Listener
Receiving state/disposition date via the Channel Synchronization Task
Using state/disposition data as inputs to additional workflows and downstream activities
Unique features
Compared to the other SMS connectors that RPI supports, Twilio SMS connector supports the following features:
Enhanced fulfillment states, including:
Sent Count: messages that were sent via the platform.
Queue Count: messages that are currently in queue, pending delivery.
Sending Count: messages that are currently sending and have not been yet delivered.
Undelivered Count: messages that were undelivered.
Ability to pool the sending phone numbers, utilizing Twilio's Copilot functionality. This service will help improve deliverability for larger sends. More information is available here: https://www.twilio.com/blog/2017/03/introducing-the-copilot-api-for-programmable-sms.html
Support for long and short codes.
Ability to configure keywords for managing responses and capturing those respective keywords within the offer history states table. This would be ideal for sending follow-up messages, depending on the response.
Ability to configure retry limits to minimize failures when executing large sends.
Ability to configure the retrieval period for event data, at the channel level.
Ability to configure the number of event records to process per channel sync.
Support for email notifications when processing bulk export jobs during channel sync, configurable at the channel level.
Process flow
The following flow chart shows how the Twilio SMS channel works within both outbound fulfillment and inbound state synchronization.
Outbound processing
Inbound processing
Outbound fulfillment
The Twilio SMS connector performs the following steps when it is used as part of an outbound Offer Activity:
Step # | Step Description | APIs / SQL |
---|---|---|
1 | Initiate a connectivity test to validate the credentials configured in the channel are valid. The connectivity test will fail if the response code does not return a | Method: Endpoint: Request Body: N/A Response Body (Example):
JSON
|
2 | This request is to check if the sending phone number has any recipients that have opted-out within the retrieval period, which is 13 months, but this can be configured in the channel. Records will be loaded to the Twilio will not send the message if the recipient has opted out, but RPI will check the | Method: Endpoint: Request Body: N/A Response Body (Example):
JSON
|
3 | RPI temp table used during execution to dedupe the records by recipient phone number. This table is dropped after execution of the offer. | Multiple queries against the |
4 | RPI temp table used during execution to load any records that have opted-out OR opted back in. This table is dropped after execution of the offer. | Multiple queries against the |
5 | This table used to store recipient phone numbers that have opt-out or opted back in. | Multiple queries against the |
6 | This request will initiate the sending of the message, and Twilio will queue the message on their end. | Method: Endpoint: Request Body:
Response Body (Example):
JSON
|
7 | This table is used to store the individual message IDs generated by Twilio at the time of send. During the channel sync, RPI will check the status of these messages and load the delivery status to the Offer History table, e.g., These records will be deleted from the table once they've been processed to avoid redundant calls to the Twilio API. | Multiple queries against the |
8 | These tables are dropped as part of the tidy up process after the execution is complete. |
|
State data synchronization
Inbound process
Step # | Step Description | APIs / SQL |
---|---|---|
1 | Create |
SQL
|
2 | For each eligible execution associated with the channel, query the If no results are returned, then check next eligible execution. |
SQL
|
3 | For each message that was sent after the last channel sync, check the delivery status by calling the | Method: Endpoint: Request Body: N/A Response Body (Example):
JSON
|
4 | Create RPI temp table for bulk loading the status event for all messages associated with the execution. |
SQL
|
5 | Load the data from the temp table to the Offer History states table. |
SQL
|
6 | Once the data is loaded for messages associated with the channel execution, delete the respective message(s) from the Repeat steps 2 to 6 until all eligible executions associated with the channel have been processed. |
SQL
|
7 | For each eligible execution, call the | Method: Endpoint: Request Body: N/A Response Body (Example):
JSON
|
8 | Create RPI temp table for bulk loading states data. |
SQL
|
9 | Create separate RPI temp table for loading messages from phone numbers that have unsubscribed. |
SQL
|
10 | If any records are inserted into the |
SQL
|
11 | Check if the |
SQL
|
12 | Load the data from the temp table to the Offer History states table. |
SQL
|
13 | Query the The data from this query will be used to determine which records have already been processed, so that they're not picked up again during the next channel sync. |
SQL
|
14 | Delete RPI temp table once processing is complete. |
SQL
|
15 | Delete RPI temp table once processing is complete. Repeat steps 7-15 for each eligible execution associated with the channel. |
SQL
|
16 | Aggregate results and write them back to the | N/A |
Limitations
Limitation # | Limitation Detail |
---|---|
1 | Twilio will split the offer into multiple messages if the content exceeds 160 characters. |
2 | Twilio does not support batching when sending messages. Each recipient will initiate a single API request which may extend processing time for larger sends. |
3 | The Twilio API does have rate limitations, but the exact limits are not documented by Twilio. When limits are reached, the request will fail with error code For sends larger than 500 recipients at one time, it's recommended that you increase the minimum and maximum API call retry delay thresholds, e.g., starting with |
4 | Twilio will throttle the actual delivery of the messages, depending on the type of phone number being used for sending. For example, if a standard phone number is configured, the messages will be sent to the carrier at a rate of one per second. More information is available on their support site: https://support.twilio.com/hc/en-us/articles/115002943027-Understanding-Twilio-Rate-Limits-and-Message-Queues |
5 | Opt-out messages are not automatically added to the offer during send and will need to be configured directly within the offer. |
6 | Twilio does not support the ability to match the response data to a specific send for a recipient. For example, if a recipient receives 5 messages over a period of 30 days, and they respond with |
7 | Short codes currently are not able to receive states data, whether used as standalone phone number or part of a messaging service. This feature is currently in public beta. |
Performance testing will be completed and published by the end of August 2021.
Logging
Below is an example of the Interaction log for an offer using the Twilio SMS channel:
Log | Log Entry Descriptions |
---|---|
2021/07/09 16:30:38 Fulfillment Action complete | Sending first batch of SMS campaign: XX messages = the number of messages that will be attempted to send XX SMS(s) have been sent = the actual number of messages that were sent to Twilio XX invalid SMS numbers = the total number of invalid SMS numbers, eg not formatted correctly XX unsubscribed SMS numbers = the total number of SMS numbers that had opted out and not eligible send. Twilio will not send the message if the recipient has opted out but RPI will check before the message is sent, to avoid making the request and being charged the fee to send. XX seed SMS(s) have been sent = the total number of seed SMS messages that were sent XX invalid seed SMS numbers = the total number of invalid seed SMS numbers XX unsubscribed seed SMS numbers = the total number of seed SMS numbers that had opted out and not eligible send. |
Troubleshooting
When the Enable trace option is selected within the Advanced tab of the Twilio SMS channel configuration, the following samples of trace HTTP request/response log messages are being generated:
Description | HTTP Request | HTTP Response |
---|---|---|
Validate the account credentials are valid. | 7/9/2021 4:05:33 PM Version :6.3.0.0 Category: Plugin Trace | NA - to be looked at |
Check if any opt-outs are associated with the sending from number before sending the actual message. The retrieval period defaults to 13 months, but it can be configured within the channel. | 7/9/2021 4:05:34 PM Version :6.3.0.0 Category: Plugin Trace | NA - to be looked at |
Send the message to the recipient(s). This request is made for each recipient being sent a message. | 7/9/2021 4:05:35 PM Version :6.3.0.0 Category: Plugin Trace | NA - to be looked at |
Check message status for any messages sent after the last channel sync. | 7/9/2021 4:06:17 PM Version :6.3.0.0 Category: Plugin Trace | NA - to be looked at |
Retrieve states information for the sending number that have occurred since the last channel sync. | 7/9/2021 4:06:17 PM Version :6.3.0.0 Category: Plugin Trace | NA - to be looked at |
Common questions
Q | Can I use a URL shortening service like Bit.ly or Rebrandly within the content? |
A | Yes, URL shorteners are supported within the offers, but per Twilio, this has potential to result in carriers blocking the message. It's recommended to monitor the delivery metrics for the sends and adjust the offer if necessary. |
Q | The offer is failing with an error code |
A | This error may occur when sending larger volumes at one time. For any sends larger than 500 recipients, it may be necessary to adjust the API retry thresholds in the channel configuration: It's recommended to start by increasing the minimum and maximum API call retry delays to 2 and 20 respectively, and continue to increase those thresholds if failures are still occurring. |
Q | Do the recipient and sending phone numbers need to be in a specific format? |
A | Yes, the format of the recipient phone number must be stored in the database as Likewise, the sending phone number must be formatted the same way, unless using a short code. |
Q | In the Twilio console, we're seeing error code |
A | This error occurs when the carrier filters or blocks the message being sent by Twilio. Twilio support has some recommendations for addressing this error, published here: We've also spoken to Twilio directly regarding this error, and they offered additional suggestions, including:
|