You want to send SMS from code you control, not from a dashboard someone else built. A cron job that fires payment reminders, a Node app that texts a lead the second a form submits, a Python script that pings a customer when an order ships. The obvious first move is signing up for a Twilio-style API. If you're in payday lending, debt collection, cannabis, vape, crypto, MLM, lead generation, real estate wholesaling, or gambling, that's also the move that stalls out: brand registration, campaign registration, a use-case review that rejects your industry outright or approves it and then throttles it anyway.
This is a walkthrough of the other path: the Android Texter REST API, which sends through a real Android handset instead of a carrier-registered business number, and what that means for the code you actually have to write.
Why the API Path Usually Dead-Ends at 10DLC
Every major SMS API provider, Twilio, MessageBird, Plivo, Bandwidth, routes your traffic as A2P: application-to-person messaging over a 10-digit long code (10DLC). Before any of them will let your API key send a message, you have to register a Brand with The Campaign Registry, the industry clearinghouse that verifies businesses and use cases on behalf of the carriers, and then register a Campaign describing exactly what you're sending and why.
Once that's approved, the carriers keep filtering. AT&T, T-Mobile, and Verizon treat the CTIA's messaging principles as close to mandatory, and their automated filters score every outbound message against your registered brand, your registered use case, and content patterns associated with restricted categories. If your industry falls into a blocked or soft-restricted bucket, and payday lending, debt collection, cannabis, vape, crypto, MLM, lead-gen, and gambling all do at one aggregator or another, you either get rejected at the campaign-registration step or approved and then throttled at the filtering step, often with no error message telling you which messages didn't land.
None of this is a bug. It's the system working as designed for A2P traffic. The problem is that your traffic isn't inherently business spam, it's a legitimate operator who happens to sell something a compliance committee flagged as high-risk.
How Android Texter's API Sends Around the Carrier Gate
Android Texter's API doesn't send A2P traffic at all. Every message routes through a real Android phone running the Android Texter app, over that phone's own carrier line, the same way a text sends when you type it on your own keypad. That's person-to-person (P2P) SMS, and P2P isn't subject to 10DLC brand or campaign registration because there's no business sender ID for a carrier to vet in the first place. Your API call reaches a phone; the phone sends the text.
This doesn't touch the Telephone Consumer Protection Act. TCPA still governs who you can text and what you can send, consent is still entirely your responsibility, and nothing about calling this API instead of Twilio's changes that. What it removes is the second gate carriers built on top of the TCPA: the one that requires a brand review and a use-case approval before your first message can go out at all.
Getting an API Key
API keys live at /dashboard/settings/api-keys in the web dashboard. Generate one, and you get a key prefixed atx_. That key goes in the X-API-Key header on every request, there's no OAuth handshake or token refresh to build. If a key leaks, revoke it from the same settings page and issue a new one.
The full API reference is at androidtexter.com/api, with a machine-readable OpenAPI 2.0 spec at /api/openapi.json if you want to generate a client, and an interactive Swagger UI at /api/swagger for poking at endpoints before you write any code.
Sending Your First Message
The send endpoint is POST /api/v1/messages/send. A minimal call:
curl -X POST https://androidtexter.com/api/v1/messages/send \
-H "X-API-Key: atx_yourkeyhere" \
-H "Content-Type: application/json" \
-d '{
"phone": "+15551234567",
"message": "Your order shipped and should arrive Thursday. Reply STOP to opt out."
}'
That's it for a single text. The same endpoint takes a media_url field for MMS, so a shipping confirmation can include a photo of the package label or a receipt without a separate call.
If you've paired more than one phone to your account, you can target a specific device with a device_id field rather than letting the send auto-route to whichever device is online. That matters most once you're distributing volume across several lines instead of running everything through one number, which is its own conversation, but worth knowing the field exists from day one.
Scheduling Sends and Broadcasting to a List
Two things turn a single send call into something closer to a campaign tool. scheduled_at on the send endpoint takes an RFC 3339 timestamp and queues the message for later instead of sending immediately, useful for a payment reminder that should land at 9am in the recipient's time zone rather than whenever your script happens to run. And for a list, there is a separate broadcast endpoint, POST /api/messages/broadcast, which takes a phones array instead of a single number, up to 500 recipients in one call.
curl -X POST https://androidtexter.com/api/messages/broadcast \
-H "X-API-Key: atx_yourkeyhere" \
-H "Content-Type: application/json" \
-d '{
"phones": ["+15551234567", "+15557654321"],
"message": "Reminder: your payment is due Friday."
}'
Free-tier keys hit a daily send quota; a pro account removes the cap. Either way, the quota is a volume limit, not a content review, there's no campaign classification sitting between your call and the send.
Receiving Replies: Webhooks vs Polling
There are two ways to get inbound messages into your app. GET /api/messages/received polls for the latest inbound and works fine for a script that checks in every few minutes. It does not work for anything that needs to react in real time, a support bot, a live agent handoff, an order-status lookup triggered by a reply.
For that, register a webhook: POST /api/v1/webhooks with a url and the events you want, message.received and message.sent, which is also what you get if you leave events off entirely. The registration response includes a signing secret. Use it to verify, in your own handler, that an incoming webhook call actually came from Android Texter and not from something spoofing your endpoint, before you act on the payload.
If you're building a reply flow, webhooks are the right default. Polling is the fallback for a low-frequency integration where a few minutes of lag doesn't matter.
Rate Limits and What They Mean for Your App
Everything under /api/v1 is capped at 5 requests per second with a burst of 10. The unversioned send and broadcast paths carry their own higher limit, 10 requests per second with a burst of 20. For a transactional integration, order confirmations, appointment reminders, one-off replies, you will not come close to either. The limits start to matter if you're looping a list one phone at a time instead of batching into the 500-per-call broadcast, so batch first and you'll rarely think about rate limits again.
Everything Else the API Can Touch
Sending and receiving are the two endpoints most integrations actually need, but the API has full CRUD on contacts, quick replies, auto-reply rules, and SMS forwarding rules, so you can manage the same automations from code that you'd otherwise click through in the dashboard. Scheduled messages can be listed, edited, or canceled after the fact, not just created. There's also support for burn-note (read-once) links if a message needs to carry a one-time-view payload, and conversation-history endpoints that support per-thread fetches, including group threads, by passing a thread_id query parameter.
None of this requires a separate integration. It's the same key, the same header, the same base URL.
What the API Doesn't Change
The API removes the carrier registration gate. It does not touch your TCPA obligations, and nothing here should be read as reducing them. You still need prior express consent before you text a wireless number for marketing purposes, you still need to keep records of that consent, and you still need to honor an opt-out. Android Texter treats STOP, UNSUBSCRIBE, CANCEL, END, and QUIT as automatic suppression triggers regardless of how the message was sent, whether that was through the dashboard composer or your own API call. Build your integration as if you were texting from your own phone, because functionally, that's what's happening. The consent and content decisions on the other end of that API call are still entirely yours.
Frequently Asked Questions
Do I need to register a brand or campaign to use this API?
No. Android Texter routes messages as P2P SMS through a real Android device, which sits outside the A2P 10DLC framework that requires Campaign Registry brand and campaign approval. There's no use-case review to submit or wait on before your first send.
Does this API reduce my TCPA risk?
No, and it isn't meant to. The TCPA governs consent and content regardless of which API sends the message. Skipping carrier registration removes a carrier-imposed gate, not a legal obligation. Get consent, keep records, honor opt-outs.
Can I use this instead of Twilio for a high-volume marketing campaign?
You can send at volume, the broadcast field takes up to 500 numbers per call, but this is P2P infrastructure running on a real phone's carrier line, not a short code or dedicated A2P throughput built for six-figure monthly sends. It fits industries Twilio won't approve, not necessarily Twilio's ceiling.
What happens if my API key gets exposed?
Revoke it from /dashboard/settings/api-keys and generate a new one. Keys are per-user and scoped to your account, so revoking one doesn't affect anything else on the dashboard.
Should I poll for replies or use webhooks?
Use webhooks if your app needs to react to an inbound message in anything close to real time. Polling /api/messages/received is fine for low-frequency checks but introduces lag that a live reply flow can't absorb.
If you're building this integration for an industry Twilio has already rejected you from, the API key setup above is the same one used by everything else on this dashboard. Android Texter is built so the phone doing the sending is a real one, and the API is just a way to automate what you'd otherwise type by hand.