10DLC for SaaS platforms: who registers the brand for your customers

Your customer is the brand, and you are the platform that registers it on their behalf: each business whose name appears in the texts gets its own 10DLC brand and its own campaign, submitted by you using their legal details. One shared registration covering every customer on your platform is the setup carriers filter, and it is the most common mistake in 10DLC for SaaS platforms.

This post is for CTOs and heads of product at vertical SaaS companies and CRMs who are adding texting, or who already added it and are seeing delivery drop. It covers why the shared-campaign shortcut fails, how one-customer-to-one-registration maps onto sub-accounts, and what that costs per customer per month, with the math shown. If you need the basics of what a brand and a campaign are first, start with our 10DLC explainer.

The ISV question, stated plainly

In carrier terms you are an ISV (independent software vendor): software that sends messages for many separate businesses. 10DLC splits registration into two objects:

• Brand: the legal business sending the message. Legal name, EIN, address, website. This is your customer, not you.
• Campaign: what that brand sends and why. The use case (account notifications, appointment reminders, marketing, mixed), sample messages, opt-in description and opt-out language.

Each sending phone number is attached to one campaign. Carriers judge traffic from that number against what the campaign said it would be.

The question every platform hits is: "Can we register ourselves once and send for everybody?" For your own messages, the ones your company sends to your users (login codes, billing alerts, product updates), yes. That is your brand and your campaign. For messages your customers send to their customers ("Hi, this is Lakeside Dental, your cleaning is Tuesday at 9 AM"), no. The sender in that text is Lakeside Dental, so Lakeside Dental is the brand.

Why one shared campaign for all customers gets filtered

Teams try the shared approach because it's one registration, one approval wait and one monthly fee. Here is what goes wrong.

The content doesn't match the registration

A campaign is approved against specific sample messages and a specific use case. If you registered "appointment reminders for a scheduling platform" and then route a dental office's reminders, a gym's promo, a landscaper's quote follow-up and a salon's review request through it, the traffic no longer resembles what was approved. Carrier filtering works on content and patterns, not just on whether a registration exists. We cover that layer in why approved campaigns still get filtered, and a mixed-tenant campaign triggers most of it.

The brand name in the text isn't the registered brand

Your registration says the brand is "AcmeScheduler Inc." The message says "Lakeside Dental." Carriers vet brands so that a recipient's carrier knows who is actually texting. A message that names a business other than the registered brand looks like the thing vetting exists to stop.

One bad customer sinks everyone

Opt-out rates, spam complaints and filtered content are tracked against the campaign and brand. If one customer of 300 uploads an old list and texts it, the complaint spike lands on the shared registration. Your other 299 customers, who did nothing wrong, start seeing filtered messages. You can't isolate the damage because there's nothing to isolate it to.

Every customer shares one daily cap

T-Mobile caps messages per brand per day by trust score, in tiers of roughly ~2,000, ~10,000, ~40,000, ~100,000 or ~200,000. Throughput per second is set per campaign, and a fresh standard campaign with no vetting runs at about 1 to 4 segments per second. Put 300 customers behind one brand and one campaign, and all 300 queue behind the same ceiling. At an assumed 3 segments per second, a single customer's 10,000-segment campaign takes close to an hour, and everyone else waits behind it. More on that ceiling in our throughput explainer.

Registering each customer separately gives every customer its own cap and its own per-second lane.

10DLC for SaaS platforms: how sub-accounts map one customer to one registration

The model that works is one customer, one sub-account, one registration:

1. Sub-account per customer. Each business on your platform gets a sub-account with its own numbers, contacts, opt-outs and registration. On Ready that's POST /v1/sub-accounts from your backend when a customer turns on texting, and GET /v1/sub-accounts to list them.
2. Brand per sub-account. The customer's legal name, EIN and address. You collect these in your own onboarding UI and submit them, so the customer never sees a carrier portal.
3. Campaign per sub-account (sometimes two). Usually one campaign matching what that customer actually sends. If a customer sends both reminders and promotions, pick the use case that matches the real traffic. Our use-case picking guide walks through it.
4. Numbers per sub-account. Each number sits on that customer's campaign. Reputation built on Lakeside Dental's numbers stays with Lakeside Dental.
5. Status polling. GET /v1/registration tells you where a registration stands, so your UI can show "texting goes live when approval lands" instead of a support ticket. Most approvals take 2 to 7 days.

Your own company's messages get their own brand and campaign under your main account, kept apart from your customers' traffic. If you also send login codes, keep those on a separate number from anything promotional. The reasons are in the transactional and marketing split.

What sending looks like

Once a sub-account is registered and has a number, a send is one call:

POST https://api.tryready.com/v1/messages
X-API-Key: <key>
Idempotency-Key: 7f9c2a1e-3b4d-4e8a-9c1f-2d6b8e0a5c3f
Content-Type: application/json

{"to": "+12125550199", "body": "Lakeside Dental: your cleaning is Tue at 9 AM. Reply STOP to opt out.", "consent_attested": true}

The Idempotency-Key means a retried request never sends twice, which matters when your job runner retries on a timeout. How API keys map to sub-accounts, and the rest of the request options, are in the docs and the quickstart.

What it costs per customer per month

Here are the actual numbers. Registration has no setup fee. When you submit a customer's registration, the charge is the first month, $25. After that, the monthly cost is:

• Brand: $10
• Campaign: $20
• Each number: $2

A customer with one number costs $27 a month in fixed registration and number fees, before they send anything.

Messaging is $0.0075/segment on Standard, plus a $0.0045 carrier fee per segment itemized separately. That's the all-in rate, and it excludes the compliance surcharge: TCPA/DNC scrubbing and landline validation are each $0.003 extra per segment when switched on for an account, and both are off by default. Replies a customer receives are billed like sent texts.

Worked example: three customer sizes

Assumptions: one number per customer, all messages fit in one 160-character segment, replies included in the segment count, no compliance add-ons switched on.

At the small end, the fixed fee is most of the cost. A customer sending 300 segments pays more for registration than for messages. That's the part to price for.

Segments are where budgets drift. A 140-character reminder with one emoji is 3 unicode segments, not 1, because an emoji drops the limit to 70 characters (67 per part in a multipart message). For the mid-size customer above, that one emoji on every message triples the messaging line from 2,000 segments to 6,000.

How platforms usually pass this through

• Bake it into a paid tier. Texting is only available on plans where $27/month of fixed cost is comfortably covered.
• Charge an SMS add-on. A flat monthly add-on covers registration, plus usage billed at a markup or passed through.
• Pass registration through at cost and mark up messages. This is honest and simple, but small senders feel the $27 floor directly.

If most of your customers would send under a few hundred texts a month, model this before launch. Some vertical SaaS products find texting only makes sense on their top two plans.

Compliance: what the platform handles and what stays with the sender

Separate registrations fix carrier trust. They don't fix consent. Each customer is responsible for texting only people who agreed to hear from them, and you as the platform are on the hook to make that easy to do right and hard to do wrong.

What Ready does at the platform layer:

• STOP handling. Inbound STOP/UNSUBSCRIBE is honored automatically, and the opt-out propagates so that contact can't be texted again across campaigns. GET /v1/opt-outs lists the opted-out contacts on this account. It leaves out a STOP from a deleted contact, a dialer do-not-call entry and a STOP held on another account of the same family, so before a send from another tool, check the number with GET /v1/opt-outs/:phone.
• Quiet hours. Campaigns, drip campaigns and automations wait up to 24 hours for the recipient's permitted window. A one-to-one, inbox or API text (bulk API included) is held only if the window opens within 6 hours; otherwise it is refused with 409 QUIET_HOURS_BLOCK and has to be sent again later. A held text is charged only when it sends.
• Refusals before charge. Opt-outs, numbers on your Ban list and known landlines are refused up front and not charged.
• Scrubbing. Known TCPA-litigator and DNC numbers can be screened out before sending, either per segment on an account or with the standalone scrub at $0.005 per contact (GET /v1/scrub/:phone). With TCPA exposure commonly cited at $500 to $1,500 per text, it's cheap risk reduction. It doesn't make anyone lawsuit-proof.
• Attestation trail. Each bulk send and each API send that sets consent_attested records the sender's opt-in attestation: who sent, to how many, and when.

What we don't store is a per-contact consent record: the recipient's opt-in time, the wording they agreed to, the page they agreed on. Your product, or your customer's system, has to keep that. If your CRM already captures opt-in on forms, keep that record and expose it. It's what a customer will need if a recipient ever disputes a text. (A contact who signs up on a Ready-hosted opt-in page is the exception: Ready stores that sign-up, with the time, IP address and exact wording, and support@tryready.com can send you a copy.)

When this setup is overkill, and when a CPaaS is the better fit

To be straight about the tradeoffs:

• You only send your own notifications. If your product texts your users (codes, alerts, billing) and never sends on behalf of customers, you need one brand and one or two campaigns. Sub-accounts add nothing.
• You want the lowest per-segment price and have engineers to spare. Twilio's per-segment rate is around $0.0083, under our $0.0075/segment Standard rate. If your team is happy to build sub-account provisioning, the registration flow, status handling, opt-out sync and quiet-hours logic themselves, a raw CPaaS costs less per message. What we sell is that work already done: registration in-app or by API, compliance controls on by design, and a working inbox.
• High-volume customers. Optional brand vetting ($79 Standard / $179 Enhanced, one-time) raises a brand's trust score and can move its daily cap if it crosses a tier. Most customers don't need it. See whether vetting is worth $79.

The gap between signup and approval

A customer who turns on texting today won't have an approved registration today. Two things help in the meantime. An account can send up to 500 texts a month before it registers, at its normal per-text rate. An account that bought its number before registering sends on our shared registration, at the same per-text rate, while its own registration is in review. Neither is a long-term substitute for the customer's own brand. Both stop the "texting is broken" tickets during the first week.

The practical takeaway

The brand is whoever's name is in the message. When you text for your customers, each customer gets a brand, a campaign and its own numbers, held in its own sub-account, so one customer's bad week doesn't become everyone's. Budget about $27 a month per single-number customer in fixed fees, model the segment math with real message lengths, and decide which plans can carry that floor.

If you want to try the flow, create an account. To send, you add a card and get a number, which is $2 a month with the first month charged when you get it. Your first 20 one-to-one texts are free, and they end the moment a registration is paid for, so use them to test your sends before you register. The pricing page has the per-segment numbers, and the docs cover the API.

FAQ

Does each customer on my SaaS platform need its own 10DLC registration?

Yes, if you send texts on their behalf under their business name. Each customer is a separate brand with its own campaign. One shared registration across unrelated businesses gets filtered and puts every customer behind one daily cap.

Who is the brand when a SaaS platform texts for its customers?

The customer business is the brand, and the platform submits the registration for it. You use the customer's legal name, EIN and address, not your own. Your company is only the brand for messages you send to your own users.

How much does 10DLC cost per customer per month?

On Ready, it's $25 for registration and $2 per number, so $27 a month for a one-number customer. The first charge at submission is $25, and there is no setup fee. Messages are billed separately at $0.0075/segment plus the $0.0045 carrier fee.

Can I put all my customers on one 10DLC campaign to save money?

You can submit one, but expect filtering. The messages won't match the registered brand or samples. Complaints from any one customer hit everyone, and all customers share one throughput lane and daily cap.

How long does 10DLC approval take for a new customer?

Most approvals take 2 to 7 days. In the meantime, an account can send up to 500 texts a month before registering. An account that bought its number before registering can send on Ready's shared registration while its own is in review.