Build your Account
Welcome to the "Build your account" section of the Programmable Messaging API Onboarding Guide. When you complete this milestone, as long as your regulatory requirements are fulfilled, you'll be ready to message your customers whenever you need and at whatever scale you require. We encourage you to complete all the steps presented here.
Who are your stakeholders at this stage?
- Business Team : Ensure that your Subaccount strategy aligns the technical build with how your team will operationalize messaging for use with customers, departments, and consumers.
- Finance Team : Proactively discuss how you can use your account architecture to break up billing as much or as little as your organization requires.
- Developers : Make decisions that ensure your team can maintain a high degree of account security while also managing access to Parent Account, Subaccount, and data flow between Twilio and your systems.
This guide will cover how to:
- Create an account architecture.
- Create Subaccounts, API keys, and Messaging Services.
- Complete data configurations such as webhooks and status callback URLs.
The action(s) associated with each step below are marked as required, recommended, or optional to help you navigate this guide efficiently while providing all the information needed to develop a solid messaging program.
Before you start sending text messages, you need to architect your account in a way that promotes growth and flexibility. There are two main pieces of Twilio functionality you should understand before diving into your account architecture: Subaccounts and Messaging Services.
- Subaccounts : A Subaccount is a child of your parent account. You can create as many of these as you want and they give you the ability to silo out different use cases and clients. By utilizing Subaccounts, you can create API keys for each Subaccount, set up phone numbers on each Subaccount, and even track spending, sending, and error rates based on the Subaccounts. It is highly recommended for any ISV to utilize Subaccounts, but it can be just as helpful for direct use cases. Important: Subaccounts are a critical part of your compliance strategy. The siloeing of message streams means that if one Subaccount is found to be non-compliant, the impact will be contained and the rest of your accounts can continue operation. In worst case scenarios, customers who send directly from a parent account can see all their traffic impacted during a compliance violation.
- Messaging Services : You can think of Messaging Services as a bucket of senders. For example, if you purchase 100 numbers, you can put all those numbers into a Messaging Service. By doing so, these numbers can all be linked to the same Messaging Use Case, throughput, and Brand, ensuring messaging compliance. Out-of-the-box features include geomatching , sticky sending , and advanced opt-out . Messaging Services are recommended regardless of your number type, and they are also required for US A2P 10DLC registration. A default Messaging Service is automatically generated for your Account upon creation.
Info
We recommend that all users, regardless of sender type, set up their account utilizing Subaccounts and Messaging Services.
Below, we provide two account architecture examples. Read through the architecture that best suits your business.
- Architecture for a Direct Customer : This architecture is best for a business-to-consumer (B2C) model, where you send messages to your own customers directly.
- Architecture for an Independent Software Vendor (ISV) : This architecture is best for a business-to-business (B2B) model where you embed Twilio APIs into your software solutions to power digital communications. If you provide full featured solutions to other businesses and want to offer omni-channel solutions via Twilio, this is the architecture for you.