From twilio-developer-kit
Best practices for ISVs (Independent Software Vendors) building SMS features into multi-tenant SaaS platforms using Twilio. Covers customer onboarding for A2P and toll-free compliance, subaccount architecture, sender management, billing patterns, and common ISV pitfalls. Use this when building SMS capabilities that your customers will use to message their end users.
npx claudepluginhub twilio/ai --plugin twilio-developer-kitThis skill uses the workspace's default tool permissions.
ISVs face unique challenges when building SMS into their platforms: each customer needs their own number registration, sender pool management, compliance isolation, and usage tracking. This skill consolidates the architectural patterns and operational knowledge specific to multi-tenant SMS platforms.
Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Share bugs, ideas, or general feedback.
ISVs face unique challenges when building SMS into their platforms: each customer needs their own number registration, sender pool management, compliance isolation, and usage tracking. This skill consolidates the architectural patterns and operational knowledge specific to multi-tenant SMS platforms.
Before following this skill, determine whether you are an Independent Software Vendor (ISV) or a direct customer.
Your company sends messages for your own products and services. Your end users know they are interacting with your brand.
Example: A shoe company called CoolShoes sends marketing messages and order updates for their own products. Even if CoolShoes owns multiple brands (CoolShoes and CoolShirts), they are still a direct customer because both brands are operated by the same company.
Follow the direct customer onboarding process — not this ISV skill.
Your company provides messaging services to other businesses, who are represented by their own brands. Your end users think they are interacting with your client's brand, not yours.
Example: HotelTech Inc. sells a technology platform for hotels. When hotel SleepWell Inn uses the service, hotel visitors receive messages that appear to come from SleepWell Inn. Visitors likely don't know HotelTech powers the interaction.
Follow this ISV skill.
1. Who do your end users think they are receiving messages from?
2. How much control do your clients have over message contents?
| Scenario | Classification | Example |
|---|---|---|
| Templated messages with little/no customization | Direct customer | EventSite sends templated event reminders to attendees. Event organizers can only customize basic details (event name, date). End users interact with EventSite brand. |
| Clients can customize and send messages on their own behalf | ISV | PoweringEvents provides a platform where car dealership CarWorld can write and send customized messages about their Cars & Coffee events. Attendees don't know PoweringEvents exists — messages appear to come from CarWorld. |
If you give clients the ability to send customized messages that end users perceive as coming directly from your client, you are an ISV.
twilio-compliance-onboarding for registration basicstwilio-messaging-services for sender pool managementTWILIO_ACCOUNT_SID (parent account)TWILIO_AUTH_TOKEN (parent account)
— See twilio-iam-auth-setup for credential securitypip install twilio / npm install twilioRecommended approach: Create one Twilio subaccount per customer.
Why subaccounts:
Use this flow when your customer needs to send SMS via 10-digit long code (local) numbers in the United States or Canada.
The full onboarding overview includes all necessary API calls to complete A2P campaign registration for your customers.
Timeline: 13-20 business days total (3-5 days for Brand + 10-15 days for campaign). Start early.
Do not skip this step. Unregistered traffic gets blocked (error 30034).
As an ISV, you create a Secondary Customer Profile for each of your clients in their own subaccount. This profile contains your client's business information.
Required fields for Standard Brand:
Once you have customer's business information, submit Brand registration using the Customer Profile Bundle SID from Step 1.
Each Standard Brand is assigned a Trust Score, which affects each campaign's throughput and the T-Mobile daily message limit for the Brand.
Timeline: 3-5 business days.
Create a campaign for your customer's use case.
Critical ISV consideration: Each customer needs their own campaigns. Do NOT share campaigns across customers — it violates carrier policies and creates compliance risk.
Create the campaign with:
Timeline: 10-15 business days.
Use this flow when your customer needs to send SMS via toll-free numbers (800, 888, etc.).
Timeline: 3-5 business days.
Do not skip this step. Unregistered traffic gets blocked (error 30032).
When to use toll-free vs. 10DLC:
Purchase a toll-free number for the customer in their subaccount.
Submit toll-free verification with:
Timeline: 3-5 business days.
Create API keys per customer instead of sharing parent account credentials.
Generate API keys per customer with a descriptive friendly name. Store the API key SID and secret securely; use them to provision resources in the customer's account on their behalf.
Only use a customer's dedicated API key — not your parent account credentials. This limits the blast radius if a customer's key is compromised.
Throughput per Brand type:
| Brand type | SMS/sec per campaign | T-Mobile SMS daily cap (per Brand) | Total SMS daily cap (per Brand) |
|---|---|---|---|
| Sole Proprietor | ~1 | 1,000 messages | 3,000 messages |
| Low-Volume Standard | ~3.75 | 2,000 messages | 6,000 messages |
| Standard | ~12-225 (varies by Trust Score) | 2,000+ messages (varies by Trust Score) | Unlimited |
ISV strategy:
DON'T: Use a single shared campaign SID for all customers in your parent account.
Problem: Violates carrier policies. One customer's spam complaint affects all customers. Campaign rejection or shutdown blocks everyone.
DO: Each customer has their own campaigns in their own subaccount.
DON'T:
Problem: Messages blocked immediately (error 30034). Customers can't send. Scramble to register takes 10-15 business days.
DO:
Common rejections:
| Field | Common mistake | Fix |
|---|---|---|
| Opt-in description | "Users can opt in on our website" | "Users check 'I agree to receive SMS' checkbox at checkout.acme.com/register" |
| Message samples | Generic ("We send notifications") | Exact examples matching use case ("Your order #12345 has shipped") |
| Business name | Marketing name instead of legal name | Must match EIN records exactly |
| Website URL | Localhost, staging URL, or 404 page | Live, publicly accessible production URL |
DON'T: Store credentials in plain text.
Problem: Credential leaks expose customer accounts.
DO: Encrypt credentials at rest using strong encryption (e.g., Fernet). Store encrypted values and decrypt only when needed for API calls.
See twilio-iam-auth-setup for credential security best practices.
twilio-compliance-onboardingtwilio-messaging-servicestwilio-sms-send-messagetwilio-iam-auth-setuptwilio-account-setuptwilio-compliance-traffic