You have a list of 500 leads and a deadline. Fire them all through one API call and one of two things happens: half the messages never arrive, or the number you sent them from is dead by Thursday. Neither problem shows up as an error. Carriers do not return a "you got flagged as spam" response. Messages just stop landing, silently, and the only signal you get is a reply rate that collapsed for no reason you can see in your own logs.
This is the actual mechanic behind "sent" not meaning "delivered," and it applies whether you are a real estate wholesaler blasting a skip-traced list, a dispensary announcing a restock, or a lender sending due-date reminders to a few hundred borrowers at once. The fix is not "write better copy." It is understanding what a carrier's filtering system is scoring, and structuring the broadcast so it never looks like the thing that gets scored down.
Why bulk sends get flagged before content is even the issue
U.S. and Canadian carriers run machine-scoring systems on inbound traffic that weigh two things independently of what the message says: how many messages have come from a given number in a given window, and how closely the pattern matches known spam behavior. Twilio, which routes more A2P traffic than almost anyone, documents this directly: carriers assign a cumulative score to a sending number based on volume and pattern, and messages that cross the threshold get filtered regardless of content (Twilio: How Does Message Filtering Work?).
The pattern that scores worst is the one most bulk tools default to: nothing from a number for days, then a burst of hundreds of messages in a few minutes. Twilio's own filtering documentation describes this exact shape, a sudden spike from a number with no sending history, as one of the clearest spam signals a carrier's system looks for (Twilio: SMS Message Filtering in the United States and Canada). A2P senders solve this with warm-up schedules and TCR-registered campaign throughput limits. If you are not running A2P traffic, you do not have that registration to fall back on, which means the burst pattern is the one thing you actually have to design around yourself.
What Android Texter's broadcast call actually does
Android Texter's send endpoint, POST /api/v1/messages/send, accepts a broadcast to up to 500 phone numbers in a single call, authenticated with a per-user API key (prefix atx_) sent as the X-API-Key header. The full spec is published at /api/openapi.json with an interactive Swagger UI at /api/swagger if you want to test calls before wiring them into a script.
That 500-number cap is a batch limit, not a delivery guarantee, and it is worth treating it as two separate jobs: building the list of who gets a message, and deciding how that list actually leaves the phone. The API supports scheduled sends via an RFC 3339 timestamp and can target a specific device with device_id, both of which matter more to deliverability than the batch size itself. Free-tier accounts hit a daily send quota; paid accounts do not, but neither tier changes how a carrier scores the traffic once it leaves the handset.
Because every message routes through a real Android phone on a real carrier line, a broadcast from Android Texter is still, technically, hundreds of individual person-to-person texts rather than one A2P campaign submission. That is what keeps it outside TCR registration and campaign-level content gating in the first place. It does not make the traffic invisible to a carrier's general anti-fraud scoring, which watches any number, business or personal, for the same burst-and-silence pattern described above.
Spreading the send across more than one line
Android Texter supports pairing multiple Android phones to a single account, each showing up as a distinct device with its own number. A broadcast can be split across them by specifying device_id per batch, or left to auto-route to whichever paired device is online.
This is the same mechanic real estate wholesalers already lean on: distributing outbound across three to five paired phones, each handling roughly 100 to 200 sends a day, keeps any single line's volume inside a range that reads as normal personal use rather than a mail-merge. A 500-contact broadcast split four ways across paired devices produces four sending patterns a carrier's system has no particular reason to flag, instead of one pattern that looks exactly like the spike Twilio's own filtering documentation calls out.
Scheduling instead of blasting
The same API call that sends a broadcast accepts a scheduled_at field, and the dashboard's composer has a scheduled-send picker for the same thing without writing code. Scheduled and pending sends are visible and editable at /dashboard/scheduled until they go out.
Spacing 500 messages across a two-hour window instead of firing them in ninety seconds does two things. It keeps velocity per minute low enough that no single burst trips a threshold, and it means replies come back staggered instead of in one unmanageable wave, which matters if you are the one answering them. For payment-due reminders, restock announcements, or renewal offers, a scheduled window also lets you send at a time zone-appropriate hour instead of assuming everyone on a national list is on Eastern time.
A broadcast doesn't change who you're allowed to text
None of the above touches consent. The Telephone Consumer Protection Act requires prior express consent before you send a non-emergency marketing text to a wireless number, and that requirement applies per recipient, not per campaign. Sending the same message to 500 people in one API call does not create 500 separate legal obligations that are somehow smaller than one message sent individually. It creates 500 identical obligations, and you need a consent record for each one before the message goes out (FCC: TCPA Rules on Revoking Consent for Unwanted Robocalls/Robotexts).
Opt-outs work the same way in reverse. Android Texter's auto-reply rules can be configured to recognize STOP, UNSUBSCRIBE, CANCEL, END, and QUIT and return an automatic suppression, but the underlying obligation to honor that opt-out is the operator's, not the tool's. That obligation is also about to shift in a way that is worth watching if you send broadcasts on any kind of recurring basis: the FCC has a draft order circulated for its September 30, 2026 open meeting that would let a business designate a single exclusive channel through which consumers must revoke consent, rather than being required to honor a revocation made through any reasonable method, alongside a proposed rule that would require two-way texting so a reply-based opt-out is even possible in the first place (FCC Fact Sheet, September 9, 2026; National Law Review: Look Alive! New NPRM Seeks to Change TCPA Rules). If that rule takes effect, a broadcast tool that cannot receive and act on inbound replies stops being a legal option for marketing sends, not just a bad one.
Android Texter's routing does not touch any of this. It changes which gate your traffic passes through at the carrier level; it does not change what the TCPA requires of the person hitting send.
A working checklist before you hit send
- Confirm every number on the list has a consent record you could produce if asked, not just a source you trust.
- Deduplicate the list. The same person on it twice doubles your exposure and halves your credibility with them.
- Split the batch across paired devices if it is close to the 500 cap, rather than pushing all 500 through one line.
- Schedule the send across a window of at least an hour instead of firing it as one call.
- Make sure your auto-reply rules are live before the broadcast goes out, not after the first STOP reply arrives.
Frequently Asked Questions
How many contacts can I include in one Android Texter broadcast?
Up to 500 phone numbers per call to POST /api/v1/messages/send. For lists larger than that, split them into multiple batches, ideally spread across paired devices and a scheduled window rather than fired back to back from the same line.
Does splitting a broadcast across devices actually improve delivery?
It keeps per-line volume in a range that looks like normal personal use rather than a mail-merge spike, which is the pattern carrier filtering systems flag first. It does not guarantee delivery, since carrier scoring also weighs content and reply behavior, but it removes the single biggest self-inflicted risk.
Do I still need consent for everyone on a broadcast list?
Yes. The TCPA requires prior express consent per recipient for marketing texts, and sending to many people in one API call does not reduce or bundle that requirement. You need a consent record for each number before it goes out, the same as if you texted them one at a time.
What happens when someone replies STOP to a broadcast message?
If an auto-reply rule is configured for STOP, UNSUBSCRIBE, CANCEL, END, or QUIT, Android Texter returns a confirmation and suppresses further sends to that number automatically. Set the rule up before you send the broadcast, not after the first opt-out reply arrives.
Is a scheduled broadcast treated differently than an instant one under the TCPA?
No. The TCPA governs consent and content, not send timing. Scheduling a broadcast across a window helps with carrier-level deliverability and reply management, but it has no bearing on whether you had consent to send it in the first place.
Send the list, don't burn the number
A 500-contact broadcast is either four clean batches spread across paired devices and a two-hour window, or one burst that trips a filter and teaches a carrier to distrust your number before your next campaign even starts. Android Texter's dashboard and API give you the batch size, the device targeting, and the scheduling to do it the first way. What they do not do, and were never built to do, is replace the consent record you need for every number on the list before you send.