How to Send SMS From Make.com Without Twilio or 10DLC

If you run scenarios in Make.com, you've probably already tried to wire up SMS. You search the app directory, find Twilio or Vonage or Plivo, drop the module into your scenario, and connect your account. Then the messages don't send, or your Twilio campaign gets rejected before you ever get that far, because your business is a payday lender, a cannabis retailer, a debt collector, a crypto platform, or anything else the carriers have decided needs a business license to text.

The problem isn't Make. It's what's on the other end of the module. Here's why that happens and how to point the same scenarios at a channel that isn't gated the same way.

Why Make's native SMS apps hit the same wall

Make has certified modules for Twilio, Twilio Verify, Twilio Autopilot, and similar providers. Every one of them is a wrapper around an A2P (application-to-person) aggregator API. That means every message you send through those modules still has to clear the aggregator's own compliance layer before it touches a carrier network.

That layer is A2P 10DLC: brand registration with The Campaign Registry, campaign registration classified by industry and use case, carrier approval per campaign, and ongoing content filtering against whatever category you registered under. Payday lending, debt collection, cannabis, vape, MLM, and gambling are categorically blocked or throttled to near-uselessness under this system regardless of how clean your Make scenario is. Swapping Twilio for Vonage or Plivo in the module picker doesn't change anything, because they all sit on the same regulatory rail.

Android Texter doesn't. It routes outbound messages through a real Android phone on a real consumer line, so the traffic is person-to-person SMS, not a business sender ID pushing through an aggregator. There's no TCR brand, no campaign to get rejected, no content category to be filtered against. That's the piece Make needs to reach, and it doesn't have a native module for it, which is fine: Make doesn't need a native module to talk to it.

What Android Texter's API gives Make to work with

Android Texter exposes a documented REST API at androidtexter.com/api, with an OpenAPI 2.0 spec at /api/openapi.json and an interactive Swagger UI at /api/swagger. Every request authenticates with a per-user API key (prefixed atx_) sent as the X-API-Key header. You generate and revoke keys from the dashboard at /dashboard/settings/api-keys.

Two endpoints matter for a Make scenario:

• POST /api/v1/messages/send queues an outbound SMS or MMS through your linked Android device. It supports scheduled sends via an RFC 3339 timestamp, targeting a specific device by device_id, media URLs for MMS, and broadcasting to up to 500 numbers in a single call.
• POST /api/v1/webhooks registers an HTTPS URL (in this case, a Make custom webhook) to receive message.received, message.sent, and message.delivered events. The registration response includes a signing secret so you can verify the payload came from Android Texter.

Neither of those needs a certified Make app. Make's generic HTTP module and Webhooks module cover both directions.

Building the send-side scenario

1. In your scenario, add whatever trigger starts the workflow: a new row in a spreadsheet, a new deal stage in your CRM, a form submission, a scheduled interval.
2. Add an HTTP module and choose Make a request.
3. Set the method to POST and the URL to https://androidtexter.com/api/v1/messages/send.
4. Under headers, add X-API-Key with your atx_ key, and Content-Type: application/json.
5. In the body, map the recipient number, message text, and (optionally) device_id or scheduled_at from the data earlier in the scenario.
6. Add a Router after the HTTP module if you want to branch on the response (log a failure to a sheet, retry, alert a Slack channel), since Make surfaces the raw response body and status code from the call.

That's the entire send side. No campaign ID, no brand ID, nothing to get rejected.

Receiving replies: the webhook side

To pull inbound replies into a scenario instead of building a polling loop:

1. Add a Webhooks module and choose Custom webhook, then Add. Make generates a unique HTTPS endpoint.
2. Call POST /api/v1/webhooks against the Android Texter API with that URL and the events you want (message.received at minimum).
3. Back in Make, run the scenario once so it captures the first payload and infers the data structure automatically.
4. From there, route the parsed message (sender, body, thread ID) into whatever the reply should trigger: a CRM note, a Telegram forward, a spreadsheet row, a second automation.

Make's webhook intake can handle up to 300 incoming requests per 10-second window and queues up to several hundred items per webhook depending on plan, per Make's own webhook documentation, which is more headroom than a single operator's reply volume is likely to need.

Scenarios worth actually building

A few shapes that come up constantly for the industries that end up on Android Texter in the first place:

• Payment-due reminders. A scheduled Make scenario reads due dates from a lending or billing system and fires a scheduled send through the API a day ahead, using the scheduled_at field so the message lands at a set local time rather than whenever the scenario happens to run.
• Restock and drop alerts. A cannabis or vape retailer's inventory system pushes a webhook into Make when a SKU comes back in stock; Make filters to the customers tagged for that product and calls the send endpoint for each one.
• Lead-reply logging. A wholesaling or lead-gen operator wants every inbound reply written to a spreadsheet or CRM the moment it lands, so the webhook flow above feeds straight into an Airtable or Google Sheets module.
• Cross-tool forwarding. Inbound messages get forwarded to a Telegram channel for the whole team to see, built the same way as Android Texter's own forwarding rules but useful when you want the message to also trigger something else in the same scenario.

None of this requires Zapier-style per-task billing. Make bills by credits rather than tasks, and each module execution (the HTTP call, the webhook intake) typically costs one credit. The free plan includes 1,000 credits a month across two active scenarios, which is enough to build and test before deciding whether to pay, according to Make's pricing page.

Don't let the automation outrun the phone

An API call is instant; a phone sending 500 texts in the same minute is not something a carrier's velocity filters will treat as normal person-to-person behavior. If a scenario is going to broadcast to a real list, throttle it with a delay between HTTP calls (Make's Sleep module, or a scheduled batch instead of one giant loop), and if the volume is genuinely high, split it across multiple paired Android devices using the device_id parameter rather than hammering one line. That's a carrier-relationship problem, not a Make problem, and no amount of scenario design fixes it if the underlying send pattern looks like a spam blast.

What Make doesn't change

Make automates the mechanics. It doesn't do anything about consent. The TCPA requires prior express consent for non-emergency marketing texts to a wireless number, and violations carry statutory damages of $500 per violation, rising to $1,500 for willful violations, per the FCC's TCPA rules. Nothing about routing a message through Android Texter's API instead of Twilio's changes that exposure. Build STOP, UNSUBSCRIBE, CANCEL, END, and QUIT handling into your scenario the same way you would with any other channel, and keep your own consent records outside of Make, since a scenario log is not a consent record.

Worth flagging if you're building opt-out handling right now: the FCC has a draft item revising how revocation requests work, scheduled for a vote at its September 30, 2026 open meeting. As proposed, it would let a business designate a single exclusive opt-out method rather than having to honor any reasonable one, and would let an opt-out from an informational text stop only that category rather than everything from that sender. It is not yet in effect and won't be final until 30 days after Federal Register publication, per the summary of the draft rule. Don't build automation around it until it's adopted.

Frequently Asked Questions

Does Make.com have a native Android Texter integration?

No, and it doesn't need one. Android Texter's REST API works with Make's generic HTTP module for sending and its Webhooks module for receiving, which is the same pattern Make users already rely on for any app without a certified connector.

Can I keep using Make's Twilio module for clients who are already registered?

Yes. Nothing about adding an HTTP module pointed at Android Texter affects your existing Twilio modules elsewhere in the same scenario or account. Run both side by side and route each client's traffic to whichever channel fits their registration status.

Will the Make free plan work for this?

For testing, yes. The free plan gives 1,000 credits a month across two active scenarios, and each HTTP call or webhook intake generally costs one credit, so a low-volume scenario can run entirely on it before you'd need to upgrade.

Does routing through Android Texter reduce my TCPA risk?

No. Android Texter removes the A2P 10DLC carrier gate, not the TCPA. Consent, opt-out handling, and record-keeping are the operator's responsibility no matter which API sends the message.

How do I test the webhook before going live?

Run the Make scenario once in edit mode after registering the webhook URL with Android Texter, then send yourself a test text. Make captures that first payload to determine the data structure automatically, which is also how you confirm the field names before wiring the rest of the scenario.

If you're building this out for a client or your own operation, Android Texter gives Make something to call that doesn't need a brand ID or a campaign approval to work.