Twilio account structure · 2026
Twilio subaccounts for a sales team: when you need them and when you do not
Last updated September 3, 2026
The moment a second person starts dialing on your Twilio account, someone asks whether each rep should have a subaccount. The honest answer for most sales teams is no, and the reason is that subaccounts do not do the thing people expect them to do: they isolate resources and data, not money. Every subaccount bills to the parent, on one invoice, from one balance. Here is exactly what they isolate, the handful of cases where the separation is worth the administration, and how to structure one account for a team instead.
The short answer
A sales team of one company does not need subaccounts. Run one Twilio account with one number per rep; the call log already tells you who called whom, and usage attributes by number. Subaccounts are free and you can have up to 1,000, but they earn their keep only when there is a real boundary to enforce — an agency with clients, separate legal entities, separate A2P brands, or recordings one group must not be able to open. They never give you separate bills: all usage rolls up to the parent.
What a subaccount isolates, and what it does not
| Resource | Status | What that means in practice |
|---|---|---|
| Phone numbers | Isolated | Each number lives in exactly one account. Move one by reassigning its AccountSid between accounts you control. |
| Call and message logs | Isolated | A subaccount sees only its own traffic. Useful when several people have console access. |
| Recordings and transcriptions | Isolated | The strongest practical reason to split: one client cannot pull another client’s call audio. |
| Usage records | Isolated | Per-subaccount usage rollups, which is what makes chargeback possible without tagging every call. |
| Credentials | Isolated | Own SID and Auth Token, own API keys. Subaccount keys cannot reach the parent or a sibling; parent credentials can reach down. |
| Applications and SIP domains | Isolated | TwiML apps and SIP configuration are per-account and have to be recreated in each. |
| Billing and balance | Shared | No balance of its own. Everything bills to the parent, on one invoice. |
| Account status | Shared | Suspend the parent and every subaccount stops. The dependency runs one way only. |
| A2P 10DLC business profile | Shared | A primary business profile cannot be created on a subaccount. Register on the parent, share it down. |
From Twilio's subaccounts documentation, checked September 2026. The two shared rows are the ones that decide most architectures. If what you actually want is a separate bill per client, subaccounts do not provide it — you get one invoice and per-subaccount usage records you split yourself.
The decision table
| Your situation | Subaccounts? | Why |
|---|---|---|
| One founder, or two to five reps, one company | No | One account, one number per rep. Everything you want is in the call log. |
| Six to fifteen reps, one company | No, usually | Still one account. Numbers give you per-rep attribution; subaccounts add credential sprawl for nothing. |
| Departments with separate budgets | Maybe | One subaccount per department plus a usage trigger each gives clean monthly chargeback. |
| Agency dialing on behalf of clients | Yes | One subaccount per client. Separate numbers, logs, recordings and usage, one bill to you. |
| Separate legal entities or brands | Yes | Separate A2P brands and business profiles need the separation, within the parent’s rules. |
| You resell calling inside your own product | Yes | This is the case Twilio designed subaccounts for: one per tenant, provisioned by API. |
| You want one team’s spam labels not to touch another’s | Partly | Numbers isolate; the carrier relationship and the parent’s account status do not. |
| You want a separate bill per client | No | Subaccounts cannot do this. All usage bills to the parent; you split it yourself from usage records. |
What the structure costs
Nothing, which is the point worth stating plainly: subaccounts are free to create and hold, and the rates inside them are the parent's rates. Take a six-rep team with two numbers each, billing 5,000 minutes a month at ~$0.014/min US outbound and ~$1.15/month per local number:
| Structure | Twilio / mo | Invoices | Trade-off |
|---|---|---|---|
| One account, one number per rep | $84 | 1 | Simplest. Everything visible to anyone with console access. |
| One account, 6 subaccounts (one per rep) | $84 | 1 | Same cost, six sets of credentials, per-rep usage rollups you did not need. |
| One account, 3 subaccounts (one per client) | $84 | 1 | Same cost. Real isolation of numbers, logs and recordings; you split the invoice yourself. |
| 3 separate Twilio accounts | $84 | 3 | Separate bills and balances, but three business profiles, three A2P registrations, no aggregation. |
The Twilio column is $70.00 of minutes plus $13.80 of numbers, identical in every row — the structure changes the administration, never the price. Add $58 of DialSheet for 6 seats ($29 per 3-seat pack) and the whole team runs at $142 a month. The last row is the only one that genuinely separates money, and it costs you the shared compliance setup and the single balance.
Spend alerts and usage triggers per subaccount
This is the one feature that makes subaccounts genuinely useful for budgeting. A Usage Trigger is created inside a subaccount and fires when a metric crosses a threshold: a count (calls placed), a usage quantity (minutes), or a price (dollars spent). It recurs daily, monthly, yearly, or fires once and stops, and an account can hold up to 1,000 of them. Twilio calls a webhook you nominate, generally within a minute of the threshold being crossed.
Two things the vendor guides tend not to say. First, a trigger is a webhook, not an email — if nobody has built an endpoint to receive it, nothing reaches a human. Second, the balance and auto-recharge alerts in the console live on the parent and are account-wide, so a runaway subaccount will not trip a per-client alarm on its own. If you are splitting by client, create a price trigger in every subaccount on the day you create the subaccount, and set it well below the number that would hurt.
Old triggers persist and keep firing until deleted, which is a small maintenance chore worth putting on the same checklist as closing the subaccount.
Recordings, credentials and data separation
If there is one reason a small team ends up wanting subaccounts, it is recordings. Call audio and transcriptions belong to the account that made the call, and a subaccount API key can read only its own — so "this client's recordings must not be openable by whoever handles that client" is satisfied structurally rather than by policy. Recordings live in your Twilio either way, which is the underlying privacy advantage of running a dialer on your own account rather than a vendor's.
The credential model is worth understanding before you commit. The parent's Account SID and Auth Token can reach subaccount resources through the REST API; a subaccount's own credentials cannot reach the parent or a sibling. Some products that use their own subdomains, such as Studio and TaskRouter, require the subaccount's credentials specifically. And phone numbers move between accounts you control by reassigning the number's AccountSid, so a mistake in the initial split is recoverable — you do not have to release and rebuy.
One asymmetry to plan around: closing a subaccount is permanent and releases its phone numbers, and the closed subaccount is deleted about 30 days later. Suspending it instead stops traffic while keeping the numbers, and is reversible. Suspend first, close much later.
A2P 10DLC and business profiles across subaccounts
If your reps text as well as call, this is the constraint that shapes the whole structure. A primary business profile cannot be created on a subaccount. You register it on the parent and share it down to the subaccounts, and a customer registered as a direct business can register only its own brand — registering secondary brands on behalf of clients is the ISV path, which is a different onboarding. So an agency planning "a separate brand per client, one subaccount each" should confirm which registration path it is on before provisioning fifty subaccounts. Voice needs none of this; the registration questions start the moment SMS does. The mechanics are in the A2P 10DLC registration guide.
The same shared-not-isolated logic applies to STIR/SHAKEN. Attestation depends on an approved business profile and trust product held at the parent, and on calling from numbers you own — the subaccount boundary does not create a second carrier identity. See STIR/SHAKEN attestation for cold callers.
What a dialer needs from whichever account you pick
One Account SID and Auth Token pair, and it must be the pair for the account whose numbers you intend to dial from. Connect a dialer with the parent credentials and it will offer you the parent's numbers and write call records at the parent, which quietly undoes the separation you built. So: one subaccount, one workspace, one credential pair, one set of numbers.
For a single company, this is an argument for not splitting at all. DialSheet takes one SID and token per workspace and gives every teammate their own number, their own caller ID and their own call history inside the app, with shared lead pools and a manager view on top — the per-rep separation people reach for subaccounts to get, without a second Twilio credential to rotate. If you are an agency, do the opposite: one DialSheet workspace per client, pointed at that client's subaccount. Setup either way is Settings, then Twilio, then paste two credentials, and takes about ten minutes including the Twilio signup — note that a Twilio trial cannot cold call, so the upgrade comes first (see why the trial fails).
One Twilio account, a number for every rep
DialSheet runs on your own Twilio, so the numbers, the recordings and the account structure stay yours. Free for one person up to 500 calls a month; $29 a month per 3-seat pack for a team, never per user.
Start freeQuestions people actually ask
Do I need a Twilio subaccount for each sales rep?
Almost certainly not. One Twilio account with one phone number per rep gives you everything a small team needs: per-rep caller ID, per-number call logs, and usage you can attribute by number. Subaccounts add a second set of credentials to manage, a second place to look for recordings, and per-account configuration that has to be repeated. They earn their keep when a boundary is real — separate clients, separate legal entities, separate brands — not when you simply want to see which rep called whom, which the call log already tells you.
What do Twilio subaccounts actually isolate?
Resources and data: phone numbers, verified caller IDs, call and message logs, recordings, transcriptions, applications, SIP domains, and usage records all belong to one subaccount and are invisible from the others. Each subaccount has its own Account SID and Auth Token, and its own API keys, which cannot reach the parent or a sibling. What is not isolated is money: subaccounts have no balance of their own, all usage is billed to the parent, and you receive one Twilio invoice. If the parent account is suspended, every subaccount is suspended with it.
How many subaccounts can a Twilio account have?
An upgraded Twilio account can create up to 1,000 subaccounts by default, and support can raise that. A trial account can create 1. Closed subaccounts stop counting against the limit and are deleted about 30 days after closure, which also releases their phone numbers permanently — so close one only when you are sure you do not want its numbers back. Suspending a subaccount is the reversible option: it stops calls and messages but keeps the resources, and you can set it back to active later.
Do Twilio subaccounts cost anything?
No. Creating and holding subaccounts is free, and the rates inside them are the same list rates as the parent — about ~$0.014/min for US outbound and ~$1.15/month for a local number, checked September 2026. Because all usage bills to the parent, splitting an account into subaccounts does not fragment your spend the way opening separate Twilio accounts would; the total stays in one place. The real cost of subaccounts is administrative: more credentials, per-subaccount configuration to repeat, and a compliance setup that has to be shared down from the parent.
Can I use subaccounts to protect one client from another client getting flagged as spam?
Partly, and it is worth being precise about the limits. Carrier spam labelling attaches to phone numbers and their calling behaviour, so keeping each client on its own numbers does contain the damage — and subaccounts are a clean way to keep those numbers, logs and recordings apart. What subaccounts do not give you is a separate carrier identity: the parent account owns the relationship, an A2P brand is registered on the parent and shared down, and a suspension of the parent cascades to every subaccount. Isolation of data, not of reputation.
How do I get a spend alert per subaccount?
Use Usage Triggers, created inside each subaccount. A trigger fires on a count, a usage quantity or a price crossing a threshold you set, recurring daily, monthly, yearly, or once only, and Twilio calls a webhook you supply — usually within a minute. An account can hold up to 1,000 of them. The catch worth planning for: a trigger is a webhook, not an email, so something has to receive it and tell a human. The balance and auto-recharge alerts in the console sit on the parent and are account-wide.
Which credentials does a dialer need if I use subaccounts?
One Account SID and Auth Token pair — the subaccount's, not the parent's. A dialer that connects with the parent credentials will see the parent's numbers and write its call records there, which defeats the point of the split. So connect each workspace or client to its own subaccount SID and token, and keep the parent credentials out of every tool. On DialSheet that is Settings, then Twilio, then paste the pair; the numbers the software offers you afterwards are exactly the numbers in that subaccount.