Need help building or registering your A2P 10DLC application? Learn more about Twilio Professional Services for A2P 10DLC.
This onboarding overview is for ISVs who want to register their customers for A2P 10DLC messaging capabilities to phone numbers in the U.S.
This registration can be done via the Twilio Console (Messaging > Regulatory Compliance > Onboarding) or via API calls. Below you will find directions and links to other documents addressing both alternatives.
ISVs are not limited to sending messages on behalf of their customers. As an ISV, you can (and must) also register campaigns to send messages for your own company's brand. If you only send messages on behalf of your own company, please see our Direct Brand onboarding guide instead of this one.
US Application-to-Person 10-Digit Long Code (A2P 10DLC) messaging is the latest offering from US carriers to help support the growing number of businesses texting their customers while protecting end-users from unwanted messages. 10-digit long codes have traditionally been intended for Person-to-Person (P2P) traffic only, causing businesses to be constrained by limited throughput and heightened filtering.
The launch and support of A2P 10DLC across all carriers in the United States provides good actors with increased deliverability and throughput, but also requires additional registration to build trust with carriers. There are associated fees with this registration process and also per-message carrier fees.
Please see our support article for details of associated fees.
It's best to think of US A2P 10DLC as comprising two operations: routes and registration. First, carriers prepare their routes for traffic on 10-digit long codes, after which they charge additional fees per outbound message segment. Second, the carriers require that a message originator register their US A2P brand and messaging campaign. Registered traffic immediately benefits from reduced filtering. Twilio has created a centralized process that allows customers to add and manage all required information via the Twilio Console.
Let's quickly run through an example of an ISV use case and what actions would be required to enable US A2P 10DLC messaging.
As shown in the diagram below, Owl Inc. is a new software company. Two retailers, Acme Corp and Buy n Large, use Owl's platform to send SMS messages to their own customers.
Owl requires two-factor authentication to login to their platform, and they use Twilio to deliver their one-time passcodes.
Owl has separated its two retail customers, Acme and Buy n Large, into subaccounts to separate billing:
In order to comply with the new US A2P 10DLC changes, Owl needs to create the following:
Finally, Owl must register a campaign use case for each type of traffic that its customers will be sending:
Type=Account Notifications
.
Type=Marketing
.
Type=Conversational Messaging
. This is because these messages typically have a large number of back-and-forth interactions as Buy n Large's customers find a good time slot.
In this guide, you will find links to detailed explanations of how to register:
We've seen many different patterns of how accounts, subaccounts, and messaging services are organized amongst our ISV customers. The diagrams and discussion below represent the six main architectures that clients have used up to the present for the organization of accounts, subaccounts and messaging services.
Please note, however, that these different architectures are NOT all equally viable going forward, given the requirements for A2P 10DLC registration that will enforced as of the Summer of 2023. In general, patterns #3, #5 and #6 below will not be viable for A2P 10DLC registration, and any clients using these architectures currently will need to migrate to patterns #1, #2 or #4. Of these latter three, we suggest that pattern #1 will prove the most useful in the longer term. These points will be explained below with reference to specific patterns.
For ISVs who use subaccounts for their customers, each subaccount contains the secondary business profile. Campaign use cases map to the secondary business profile and a Messaging Service.
If, as an ISV, you have a direct offering, you can use your US A2P brand directly and associate it with a campaign use case at the parent-account level.
In the Customer requirements example given above, the ISV (Owl) used subaccounts in which to create the Profiles, Brands and Campaigns of each of their secondary customers, Acme Corp and Buy n Large. The diagram for this has been reproduced below, so it can be more easily contrasted with an example architecture that uses no subaccounts:
For ISVs who do not use subaccounts for their customers, the parent account contains all of the secondary business profiles. Campaign use cases map to the secondary business profile and a Messaging Service.
Identify your ISV type in the table below, based on your architecture and organization. As noted above, architecture types 3, 5 and 6 will not be viable for A2P 10DLC registration going forward.
If you currently do not use Messaging Services for SMS Campaigns with 10DLC numbers in the U.S, you do not need to make any changes to your code. To find out more about Twilio Messaging Services and determine whether you'd like to make use of them, please consult this guide.
You use subaccounts for each customer. You will need to collect the required information from customers to fill in the business profile and campaign use case registration forms that make up US A2P 10DLC onboarding.
Information architecture
NOTE: We would recommend this as the preferred architecture for A2P 10DLC Brand and Campaign registration. In this architecture, the messaging traffic of each end customer is clearly separated from that of every other end customer. In a case where one of your customers is a bad actor and sends non-compliant messages, Twilio could decide to suspend their account. Having each subaccount mapped to an individual customer allows you to minimize impact when this happens because the noncompliant traffic is isolated. Moreover, separating your customers into subaccounts allows much easier analytics tracking of individual customers' messaging activity.
You use subaccounts for logical separation other than for an individual customer. You instead utilize a Messaging Service for each customer. Customers may have multiple Messaging Services attributed to them, each in a different subaccount.
Information architecture
Note: This architecture, with all secondary business profiles contained within the single parent account, can be used for compliant A2P 10DLC registration going forward, since each messaging service maps to a distinct secondary client. However, since in this pattern there is no logical separation at the account level, if one of your secondary clients begins sending noncompliant messages, there is a risk that Twilio might need to suspend the entire parent account which would impact all of your secondary accounts.
You use subaccounts for each of your customers but do not currently use A2P 10DLC SMS messaging. If you plan to send US A2P 10DLC SMS going forward for any or all of your secondary customers, you will need to create a Messaging Service within each of your subaccounts and then collect the required information from the customer associated with that subaccount, in order to fill in the Business profile and Campaign use case registration forms that make up US A2P 10DLC onboarding. At that point your architecture will be essentially identical to ISV Architecture #1. Please see the implementation details for that architecture above.
You use a Messaging Service for each customer, but do not use subaccounts. You need to collect the required information from customers to fill in the Business profile and Campaign use case registration forms that make up US A2P 10DLC onboarding.
Information architecture
Note: Technically this architecture is also valid for A2P 10DLC registration going forward. As with architecture #2 above, however, here again there is no logical separation between your primary (ISV) account and the accounts of your secondary customers. This means, again, that there is no way to isolate the activity of any one of your secondary customers should they begin sending noncompliant A2P messages, and it might become necessary to suspend your primary account, thus impacting all of your other secondary customers as well. Separate analytic tracking of each customers' messaging activity is also not possible.
You use Messaging Services as a pooled resource shared amongst your secondary customers, and do not use subaccounts. Sharing of Messaging Services among customers is not allowed for A2P registration, as each Messaging Service must be associated with a single Campaign, and that Campaign associated with a single Brand and Customer Profile. Thus at a minimum, to be A2P compliant you would need to transition to Architecture #4 to provide a logical separation of your customers' messaging services.
As noted above, there are significant benefits to Architecture #1 over Architecture #4, in that Pattern 1 uses subaccounts and therefore offers a logical separation of customer accounts from each other as well as from your primary ISV account. We recognize that this would entail a more significant restructuring; and notably, moving to a subaccount architecture will reset the opt-out mechanisms that Twilio manages, since these are set at the account level. You would therefore need to ensure that you have an up-to-date opt-out list to avoid sending messages to end-users who have opted out. But we suggest that the one-time effort of this restructuring will be worth it in the long term, in allowing you to better manage and track your individual customers' accounts.
You do not use currently subaccounts or Messaging Services for any of your customers. Again, the first question here is whether you plan to use SMS messaging Campaigns with 10DLC numbers for any of your customers going forward. If not, then you do not need to worry about A2P compliance in general. If you DO expect to use A2P 10DLC messaging going forward, for any customers who intend to message to U.S. end users, then you are in essentially the same situation as Architecture #5 above. At a minimum you would need to adopt Architecture #4 (create a separate Messaging Service to associate with a Profile/Brand/Campaign for each customer). See above for the rationale for moving to Architecture #1 instead, for a better separation among customer accounts.
The steps you will follow to create your secondary client's Business Profile, Brand and Campaign via the Trust Hub Console are essentially identical to those you would follow if you were creating a Profile, Brand and Campaign for yourself (in other words, as a direct customer) via the Console, with some very specific exceptions in process, which will be noted below:
_10 You will select the Switch Customer Profile link on the right, which will open a **Select a Customer Profile** dialogue, where you will select the **+ New Customer Profile** button:
This will take you to a Customer Profile New Registration Page, where you will begin creating your secondary client's new profile. From this point on, the business and contact information you enter will pertain to your client, NOT your own business as an ISV.
In this workflow you will first indicate whether the business entity you're registering is located in the U.S. or Canada. If you indicate yes, the page will then expand to ask whether this business entity has a Tax ID, such as a US EIN. If the answer is yes, then you must create this client's Profile and Brand as either a Standard or Low-Volume Standard Brand (learn more about Standard vs Low-Volume Standard Brands here). If your client does NOT have such a Tax ID, they could be created as a Sole Proprietor Brand (this would be rare for most ISVs' secondary clients, but conceivable if your client were either a hobbyist or a sole-proprietor businessperson who used their own Social Security number for tax filing purposes).
ISV's with only a few secondary clients may elect to use the Trust Hub Console, as detailed above; this provides a much more guided experience. If you are less familiar with A2P registration in general it may be worthwhile to follow this process for at least one secondary client, even if you have many others to register, simply to make it easier for you to visualize the sequence of steps and the inputs involved at every point. However, if you have many secondary clients to register, you will ultimately want to do most if not all of them using Twilio's APIs.
Your government agency customers are eligible for increased messaging throughput, regardless of their campaign use case. Your mobile carrier's daily cap will take precedence over the documented throughput for the registered messaging campaign type.
To successfully register and unlock increased throughput, it is critically important that you register your public sector customers as Government.
company_type
of
Government
(see specifically the sample call under 2.3.4)
Providing accurate information about your government agency customer and creating a brand with the Government company type during brand registration will trigger automatic vetting of your customers' organization. If confirmed by TCR as a government entity, the above increased throughput will be applied.
Use Cases: ISVs can register government agency customers with all Standard Campaign use cases, and those customers will also be eligible for the Emergency Special Use Case. If your customers will be sending alerts that meet the definition of the Emergency use case, please see our support article on Special Use Cases for more information.
Campaign Verify
All 527 Political Organizations including political action committees (PACs) sending political communications on behalf of a Federal, State, or Local political campaign must be verified by Campaign Verify in order to onboard successfully onto 10DLC and unlock the "Political" Special Campaign Use Case with increased messaging limits. Campaign Verify is a secure, non-partisan verification solution for U.S. Political organizations who wish to engage with voters via text messaging. For more information on the 527 Political Organization use case, see this FAQ
527s should register their A2P brand on Twilio with the Nonprofit
entity type (company type). Campaign Verify (CV) tokens will only be accepted for brands with this entity type.
Unlike 501(c) entities, 527 status will not be automatically detected and applied upon brand registration. Importing your Campaign Verify proves your 527 status and activates the special A2P benefits for your entity type. 527 organizations will not be able to complete Campaign use case registration until they import a Campaign Verify token.
Listed below are some important pieces of information about Campaign Verify registration:
Note: A 527 organization that does not register with Campaign Verify and provide a token during 10DLC registration will be allowed to register with standard use cases, but will receive the lowest tier of A2P messaging limits and will not qualify for the Political Special Use Case. In addition, you may be subject to penalties from carriers if political messaging traffic is incorrectly registered with standard use cases.
Campaign Verify Tokens
Verification will involve submitting information about your political organization to Campaign Verify, as well as verifying your identity as an authorized person associated with the political organization. Successfully importing a Campaign Verify token will assert your brand status as a verified 527 Political Organization with the carrier ecosystem.
After completing verification with Campaign Verify, you will receive a Campaign Verify Token (CV token) that you will then use during the Brand registration stage of A2P 10DLC registration.
If you are registering a 527 political organization via API, see Import Campaign verify token to an existing brand (527 Political Organizations). If you are registering via the Twilio Console, see the next section for detailed directions.
A full CV token is composed of 6 pipe (|) delimited fields, for example:
cv|1.0|tcr|10dlc|9957c339-d46f-49b7-a399-2e6d5ebac66d|GQ3NMEjED8xSlaAgRXAXXBUNBT2AgL-LdQuPveFhEyy
Listed below are some important pieces of information about CV tokens:
527 Political Organization Console Registration
Note: If you have already created a US A2P brand for a 527 Political Organization and would like to add a Campaign Verify token after brand registration, you will need to use the ISV A2P APIs. Importing or updating Campaign Verify tokens after initial brand registration is currently only available via API, not in the Console.
In the Twilio A2P Compliance Console, providing a Campaign Verify token is done as part of the A2P brand registration step. You must select "Nonprofit" as your Company type on this screen. CV tokens will only be accepted for brands with this entity type. Then, select Yes to confirm that you are a registered 527 Political Organization. You will then need to paste your CV token to verify your Organization's identity.
Final Notes on 527 Political Registration
As you register an A2P brand for your 527 Political organization, please note the following:
5.3 Registration for K-12 institutions
ISVs registering with the K-12th grade (K-12 Education) special use case are not required to create secondary brands for each K-12 school. This means that as an ISV, you may register a single K-12 Education campaign under your company's Primary A2P Brand and associate multiple schools' phone numbers within your own Brand.
Note: Public, Private, Nonprofit, and Government entity types all qualify to register for the K-12 Education Use Case.
K-12 Education is a special use case for messaging platforms that support schools from Kindergarten through 12th grade (K-12). The K-12 Education use case includes increased throughput and pricing discounts and also requires additional carrier review (post approval) to ensure that the campaign you are registering meets the criteria defined for the K-12 Education use case. Refer to the Carrier Post-Approval section below to learn more about this additional review process.
A2P 10DLC Messaging Limits Note: If you serve some of your messaging traffic at no cost to your client school(s), we recommend registering that traffic as a separate second K-12 Education campaign in case of potential fee benefits that are currently being considered by carriers.
For the K-12 Education use case, throughput will be enforced per phone number. Daily message caps on T-Mobile will depend on your brand score.
For more information on registering a K-12 Education campaign use case, see the "Registering Campaign Use Cases" section of the guide.
To learn more about A2P 10DLC, please read the following resources:
Need help building or registering your A2P 10DLC application? Learn more about Twilio Professional Services for A2P 10DLC.