Skip to contentSkip to navigationSkip to topbar
Rate this page:
On this page

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.


Step 1: Review and select an account architecture

step-1-review-and-select-an-account-architecture page anchor

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.

(information)

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.

  1. 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.
  2. 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.

Architecture for a Direct Customer

architecture-for-a-direct-customer page anchor
generic onboarding guide templates - Direct - subaccounts.

As a direct customer it is important to think through how your organization works internally. One of the biggest advantages to setting up Subaccounts is reporting on usage. The architecture shows how you could break up your Subaccounts by business unit or team. You could also do so by product, region, or in an industry specific way.

We recommend setting up both a Development Subaccount and Staging Subaccount to ensure you have separate environments for development and testing. Within each Subaccount, you then have the opportunity to further separate your traffic based on Messaging Service use cases. Sometimes, it can make sense for one Messaging Service to have multiple use cases. However, for optimal compliance and reporting, we recommend separating out Messaging Services by use case as much as possible.

Architecture for an Independent Software Vendor (ISV)

architecture-for-an-independent-software-vendor-isv page anchor
ISV Architecture.

Our recommended ISV architecture is structured to segment and containerize each customer with Subaccounts.

There will be a parent account where no sending will occur; it acts more as a shell account for administrative settings and privileges. All sending will happen in the Subaccounts below it. We recommend setting up both a Development Subaccount and Staging Subaccount to ensure you have separate environments for development and testing. From there, your production accounts will be broken up by customer. We only list two customers below, but you can have as many Subaccounts as you want.

Within each Subaccount, a Messaging Service should be created to hold all relevant senders. Depending on the amount of use cases you have for a given customer, you may want to separate out your client's use cases by Messaging Service and have multiple Messaging Services in one account, as shown in the diagram under customer 2. Note that this can incur extra costs if utilizing A2P 10DLC numbers(link takes you to an external page), but will allow the customer to ensure that each use case has its own throughput and number pool.

Now that you've reviewed one or both approaches to account architecture, we suggest you select one as a foundation for your planning and map out your account needs as a team.


Step 2: Create Subaccounts and Messaging Services

step-2-create-subaccounts-and-messaging-services page anchor

If you completed step 1 in "Prepare your sender strategy," you created and configured your parent account. If you haven't completed that step yet, we advise that you do so before proceeding.

Using your account architecture, navigate to the documentation and build out the remaining key elements of your account.

  1. Create your Subaccounts(link takes you to an external page) (recommended)
  2. Create API keys for each Subaccount (recommended)
  3. Create Messaging Services(link takes you to an external page) (recommended)

Step 3: Complete data configurations

step-3-complete-data-configurations page anchor

There are plenty of options for reviewing data in the Twilio Console, but for many of our customers, ensuring that you have this data securely stored internally is of the utmost importance. By utilizing your own data storage methods, you can use your reporting tools to review your sending in the exact way you want. Even if you don't have a solid data visualization software to use, it is important to store the data you need for archival purposes.

As a team, we recommend discussing and deciding on where you will hold your data. We highly recommend the use of our Status Callback Webhook because it is the easiest and quickest way for you and your team to get consistent updates on how your messages are faring in the SMS ecosystem.

Read about the actions below and navigate to the relevant documentation to plan your data storage strategy.

  1. Review documentation on the different webhooks available to your team (recommended)
  2. Set up the Status Callback Webhook (recommended): you can set these up at the Messaging Service level or the phone number level.
  3. Set up alerts based on your Status Callback Webhooks (optional)
  4. Retrieve your data through log archives(link takes you to an external page) (optional)

At this point, you should be able to create a structure for your account that will best serve your business needs, including Subaccounts with API keys and Messaging Services. You should also be able to build a data configuration that allows you to track delivery metrics for your application.

Next, Monitor your Application


Rate this page: