Blueprint for an Enterprise Communications Layer Leveraging Twilio APIs for Messaging (SMS and WhatsApp)

As a Twilio Solutions Architect, I have worked with many enterprises to help them develop strategies for leveraging Twilio’s industry-leading APIs. Frequently, those discussions have centered around a “Communications Layer,” or a “Communications Hub,” where an enterprise could centralize how their applications call Twilio to execute on Messaging sends. Centralizing messaging traffic, visibility, analytics, compliance, security, and infrastructure makes a ton of sense for enterprises. In addition, an Enterprise Communication Layer can lead to significant cost savings from consolidating volumes, choosing cost effective channels, prioritizing message types, and reducing internal support costs.

No two enterprise systems are the same, but they do share many key concepts. In this article, I’ll introduce a blueprint for an Enterprise Communications Layer that shows how to leverage Twilio’s APIs to maximize your enterprise’s Messaging strategy.

Towards an Enterprise SMS Communications Layer

It is important to point out that while sending an SMS to a customer is the key objective, this blueprint also addresses security, compliance, error handling, inbound messages (2-Way), and engagement feedback. These additional topics are equally important to the overall success of your enterprise SMS strategy.

We can begin with the entire blueprint and then break down notes for each section:

This image is a little small, so it may be helpful to open the image in a separate browser tab or download the PDF.

We will expand on each numbered note to explain the blueprint and the complete enterprise SMS lifecycle.

1. Enterprise Applications Trigger Message Events

This whole process starts with the need to send an SMS message. (For the purpose of this blog post, we will say “SMS,” but everything also applies to MMS as well as to WhatsApp!)

Any Enterprise Application that needs to send an SMS message can send events to an internal API in the Enterprise Communication Layer.

First and foremost, implement authentication and authorization on this internal API per your process and network requirements. Through this step, you will standardize how your enterprise sends SMS messages.

2. Process Message Event

Once a message event passes your internal API, it can be processed before being sent to the Twilio Integration.

Steps can include:

• Pull required evaluation data from your CDP (check out Twilio Segment!) or other data sources.
• Determine whether the message event can proceed.
• Set the parameters for API calls to Twilio (Twilio account, sender, priority, and more).
• Send to an internal queue before calling the Twilio API.

The internal queue could address both rate limits on the throughput for your senders, as well as the prioritization of your messages. For example, transactional messages could be sent out before promotional messages already in your internal queue.

3. Trigger API Call to Twilio

Messages released from the queue are sent to your Twilio Integration. You can leverage the Twilio Programmable Messaging API (with quickstarts available in many popular programming languages), to build an integration to meet your requirements. There are many examples that show you how to properly format your message events into API calls to Twilio.

Twilio has many endpoints (and SDKs) that you can learn about in our world-class docs, but for sending SMS messages, you will hit our Messaging API.

API calls to Twilio are REST calls made over HTTPS using an API Key for the Twilio Account that you want to use for that call. You have the option to enable and use Twilio Public Key Client Validation to secure your API calls made TO Twilio.

This integration can also take advantage of special Twilio features such as Link Shortening and Tracking, Message Scheduling, Content API, and the upcoming Message Tagging.

4. Twilio Accepts and routes API Call

Twilio’s Messaging API will receive your API calls, and if they are valid, route them to the corresponding Twilio Account or Subaccount. Invalid API calls will return an error code and message. Your Twilio integration needs to handle errors returned on your API calls to Twilio.

You can read more about Twilio Accounts in the docs, but I like to explain them as containers for resources that you can provision in Twilio. For example, a resource provisioned in a Twilio Account (or Subaccount) could be a phone number used to send SMS messages. It makes sense to have Twilio Accounts (and Subaccounts) to match your business units and use cases and to follow best practices to separate your concerns.

When you make an API call to Twilio, the API Key you use will specify the intended Twilio Account (or Subaccount) you’d like to use, and the Messaging API will route your request to the correct Twilio Account.

5. Twilio Account / Subaccount Processes Message

For SMS use cases, you will need to provision the appropriate Senders to meet your branding, regulatory, and throughput requirements. Sender types include Short Codes, Long Codes, Toll Free, and Alphanumeric Sender IDs.

Individual Senders can be configured individually or they can be added to a Messaging Service. Messaging Services are out of scope for this blog post, but they are a powerful tool that add important functionalities such as advanced opt-out management, automatic sender selection, sticky sender, sender pools, and more. While planning your Twilio configuration you should certainly be aware of Messaging Services and – most likely – use them!

Twilio will manage a queue of messages based on the available throughput of your senders in each Account or Subaccount. In other words, queue size for each Twilio account will likely be different depending on the senders available. The queue for each Account will hold up to 4 hours worth of messages at the max throughput. Read more: Understanding Twilio (SMS) Rate Limits and Queues.

6. Twilio TrustHub Addresses Compliance

We cannot move on to sending SMS messages without talking about compliance! Over the last few years, the SMS ecosystem has shifted dramatically across global markets, especially when it comes to messaging compliance. The carriers, industry partners, and Twilio have pushed to create safe and trusted messaging for consumers while combating bad actors and SPAM.

Twilio TrustHub provides a central place for managing registration and verification details that are needed for sending complaint messages across the globe. All SMS Senders require registration and verification, and Twilio’s resources will help you navigate the processes and keep you in good standing with the carriers. You can find Regulatory Compliance under the Phone Numbers on this page in the Twilio Console.

7. Super Network Routes to Carrier

Messages released from the Account Queue in step 5 are sent to the Twilio Super Network. The Super Network will find the optimal route to the intended carrier and deliver the message. Twilio’s Super Network is a differentiator and will allow your enterprise to confidently send SMS messages globally at scale.

8. Feedback Sent Back to Communications Layer

Sending SMS (and WhatsApp and MMS) is certainly the goal of the system, but knowing what happened to those messages is a crucial part of a successful solution.

The Twilio Super Network will deliver your messages via optimized routing to the destination carrier, and all data will be logged to your Twilio Accounts. In addition, you can receive feedback from those carriers as the message statuses change. With Twilio, you can configure Status Callbacks to receive those status change updates in real time and process them in your data systems. In addition to Status Callbacks, Twilio offers Event Streams as another way for your organization to receive this data.

All of this data generated by these customer engagements are extremely valuable and are definitely worth building into your Enterprise Communications Layer from the start! Feed this data back into your CDP, your CRM, and your other data stores and analytic tools. Check out Twilio’s Customer AI to learn more about how Twilio plans to help customers use data like this to combine living customer profiles and real-time engagement data with artificial intelligence to better serve your customers.

Security is always top of mind at Twilio. You can be sure that each request coming from Twilio is valid by inspecting the X-Twilio-Signature. In addition, via Static Proxy available in Twilio Editions, you can leverage an allowlist of static IP addresses that Twilio webhook responses will come from.

If you want an idea on how you could build a feedback handler, check out this blog: Twilio Serverless Status Callback Handler built in AWS.

9. Inbound Messages

For 1-Way use cases, handling inbound messages from your end users may seem less important. However, at a minimum you will need to address industry standard keywords like STOP, HELP, and START.

Twilio has some built in functionality to help you handle these keywords and remain compliant. You are able to customize how you handle these keywords, but, again, I want to point out that Twilio Messaging Services has built-in functionality available.

Many Twilio messaging customers utilize 2-Way messaging use cases. In fact, we see that most consumers expect to be able to reply back to messages sent from enterprises. If you are considering just 1-Way messaging, you need to consider how best to handle replies back from your customers. With Twilio, enterprises can put in place short term solutions now while knowing that Twilio will be able to support your long-term plans with our powerful messaging solutions.

Each Sender can have a handler configured so that Twilio knows how to deal with inbound messages. Alternatively, the inbound handler can be set on the Twilio Messaging Service.

The inbound handler can be set to send messages to our powerful GUI-based orchestration tool Twilio Studio, or even to our industry-leading contact center solution Twilio Flex. Twilio Conversations is another Twilio platform option you should consider!

If you want to handle inbound messages using your Enterprise Communications Layer, you would configure the handler for the Sender (or Messaging Service) to invoke a webhook that posts the inbound message to a HTTPS destination of your choosing.

Using webhooks to handle your inbound messages will give you ultimate control on how your applications interact with your customers.

10. Inbound Messages Delivered to Webhook

These webhooks created by inbound messages are secured via the same options as the Status Callbacks (X-Twilio-Signature and optionally Static Proxy available in Twilio Editions).

The payloads of these inbound webhooks contain the core message details like message body and from number plus additional context available from the calling Twilio account.

Your enterprise will need to build out all of the application and business logic in your handler to manage these inbound messages. It will likely be necessary to keep track of state and context if you plan to reply with meaningful messages and/or enable conversations. You will want to save these interactions back into your CDP (check out Twilio Segment!), CRM, or other data sources as you enable your data-driven flywheel!  

Should you choose to reply back to any inbound message, you would simply start back at Step 1 of this blueprint.

If you want an idea on how you could build an interactive application, check out this blog post: Build an Interactive Serverless Voice and Messaging Application using Twilio and AWS.

Conclusion

This blog post is intended to give enterprises an overview of how Twilio can help implement an Enterprise-Grade Messaging Solution that uses a Communication Layer to consolidate all outbound and inbound messages, as well as a mechanism for collecting engagement feedback.

This blog post focused on SMS, but your Enterprise can build a Communication Layer to include WhatsApp and MMS. Twilio has first class support for WhatsApp, including a powerful template management system in the Content API.

Each one of the 10 steps in this blueprint are crucial and merit consideration and planning. Your Twilio Enterprise Account Team is ready to help you walk through this blueprint and get you set up for success.

Dan Bartlett has been building web applications since the first dotcom wave. The core principles from those days remain the same but these days you can build cooler things faster. He can be reached at dbartlett [at] twilio.com.