How to Send and Receive SMS in Make.com (Formerly Integromat)

Make, the automation platform formerly known as Integromat, is one of the easiest places to add SMS to a workflow. You already build scenarios that watch forms, spreadsheets, e-commerce events, and schedules, so sending a text at the right moment should be a single extra step.

The catch is that most SMS tutorials assume you will rent a number from a per-message provider. This guide takes a different route: you send and receive SMS through your own Android phone and SIM card using SimGate and Make's generic HTTP module. No dedicated connector, no rented number, no per-SMS fee in the middle.

By the end you will have a scenario that sends a text on any trigger, maps fields from earlier modules, loops over a recipient list, handles errors, and captures inbound replies as new scenario runs.

Why send SMS from Make (Integromat)

If you already searched for "SMS Integromat" and landed on Make, the first thing to know is that nothing about the SMS workflow changed with the rename. Integromat became Make in 2022, but scenarios, modules, and the HTTP module are identical, so any older Integromat SMS walkthrough still maps cleanly onto the current interface.

Teams reach for Make when they want SMS to be one visual step in a larger flow rather than a coding project:

• Text a customer when a Google Sheet row, Airtable record, or webform is submitted
• Send an order or shipping update when a Shopify or WooCommerce event fires
• Notify a team when a monitor, calendar event, or scheduled scenario triggers
• Send appointment reminders on a schedule from a spreadsheet of bookings
• Capture replies and route them back into a CRM, help desk, or database

The reason to pair Make with SimGate rather than a traditional provider is control and cost. The message leaves from your own number, on your own SIM plan, at flat monthly pricing instead of a per-message rate.

How SimGate connects to Make

SimGate is a plain REST API in front of a real Android phone. Make does not need a dedicated SimGate module, because the built-in HTTP module can call any API. The full path looks like this:

Make trigger (form, sheet, e-commerce, schedule)
    -> Make HTTP module
    -> SimGate API (queue, routing, logs)
    -> your Android phone
    -> your SIM card
    -> recipient

Before you build the scenario you need two things from your SimGate account:

• An API key, used in the x-api-key header on every request
• A connected device ID from the Android app, which tells SimGate which phone should send the message

If you have not connected a phone yet, the mechanics of turning a device into a sending endpoint are covered in How to Send SMS via API Using Your Own Phone. The Make-specific summary lives on the Make integration page.

Send your first SMS from a scenario

Start with any trigger you already use, then add one HTTP module after it. The configuration is the same regardless of which trigger sits in front.

1. Add the module HTTP → Make a request after your trigger.
2. Set Method to POST.
3. Set URL to https://api.simgate.app/v1/sms/send.
4. Under Headers, add x-api-key with your SimGate key and Content-Type set to application/json.
5. Set Body type to Raw and content type to JSON.
6. Paste the JSON body with your device ID, the recipient, and the message.

The raw request Make sends looks like this:

POST https://api.simgate.app/v1/sms/send
x-api-key: YOUR_API_KEY
Content-Type: application/json

{
  "deviceId": "android-5q15b182f2704gbz",
  "phoneNumber": "+1234567890",
  "message": "Hello from Make!"
}

Run the scenario once. If the request returns a 2xx response, the message is accepted and queued to your device, and it will show up in your SimGate logs. That single module is the entire integration — everything else in this guide is about making it dynamic and reliable.

Map fields from earlier modules

A hardcoded number is only useful for a test. In a real scenario you pull the recipient and the message text from the trigger. In Make you do that by dragging fields from earlier modules into the body, which renders as mapping tokens like {{1.phone}} where 1 is the module number.

{
  "deviceId": "android-5q15b182f2704gbz",
  "phoneNumber": "{{1.phone}}",
  "message": "Hi {{1.name}}, your order {{1.orderId}} has shipped."
}

Two details save a lot of debugging time here:

• Phone numbers should be in E.164 format, for example +14155550100. If your source data stores raw digits, add a text function in the mapping to prepend the country code.
• Keep the message under one SMS segment (roughly 160 GSM characters) when you can. Longer messages still send, but they are split into multiple segments.

Send SMS to a list of recipients

SimGate accepts one recipient per request, so to text a list you loop. In Make you put an Iterator (or a search module that returns multiple rows, like "Search Rows") in front of the HTTP module. Make then runs the HTTP module once per item, or "bundle," and maps the current row into the body.

Schedule trigger (daily 9:00)
    -> Google Sheets: Search Rows (bookings for today)
    -> HTTP: Make a request (one call per row)
         phoneNumber = {{2.phone}}
         message     = "Reminder: your appointment is at {{2.time}}."

Two guardrails matter for bulk sends. First, respect your plan and carrier limits — a phone on a consumer SIM is not a bulk marketing cannon, and pushing thousands of messages per hour will get the number flagged. Second, add a short delay between messages with a Sleep module if you send larger batches, so the device paces itself. The same volume and consent considerations are discussed in the appointment reminders use case.

Handle errors and retries

A scenario that assumes every send succeeds will fail silently the first time a phone goes offline. Make gives you error handling directly on the HTTP module: right-click it and add an error handler route.

• Attach a Break directive to retry the HTTP module automatically a few times with a delay, which covers brief device reconnects.
• Route persistent failures to a fallback path — log the row, flag it in your sheet, or send yourself an alert — so nothing disappears.
• Treat non-2xx responses from SimGate as real failures. The status code and body tell you whether the problem is the API key, the device being offline, or a bad phone number.

The deeper reliability picture — queueing, device health, and delivery states — is not something Make handles for you. SimGate does that on its side, and the reasoning is laid out in What Makes a Reliable Android SMS Gateway?.

Receive incoming SMS in Make

Sending is only half of a real workflow. To act on replies — a customer texting YES to confirm, a lead texting your number, a technician replying DONE — you need inbound SMS to start a scenario. Make makes this simple with a custom webhook trigger.

1. Create a new scenario and add Webhooks → Custom webhook as the trigger.
2. Click Add, name the webhook, and copy the generated URL.
3. In your SimGate dashboard, set that URL as the inbound webhook for your device.
4. Send a test text to your SimGate number. Make captures the payload so it can learn the data structure.

SimGate forwards each incoming message to that webhook as JSON, so every reply becomes one scenario run:

{
  "sender": "+1234567890",
  "message": "YES",
  "receivedAt": "2026-07-03T10:42:00.000Z",
  "deviceId": "android-5q15b182f2704gbz",
  "messageId": "inbound-82a13d4a"
}

From there, add a Router with filters to branch on the message body — a YES confirms a booking, a STOP unsubscribes the contact, anything else routes to a human. Because the sender number arrives with the payload, you can look the contact up and reply with a second HTTP module in the same scenario, giving you full two-way SMS. The inbound side is covered end to end in How to Receive SMS via Webhook Using an Android Phone.

Make's Twilio module vs your own SIM

Make ships a native Twilio module, so a fair question is why use the HTTP module and SimGate instead. The two approaches solve related problems with different tradeoffs.

If you need to blast large volumes across dozens of countries, a managed provider is the safer bet. If you want texts to come from a number your customers recognize, at predictable cost, on infrastructure you control, the HTTP-plus-SimGate route is usually the cleaner fit. The broader argument is in Twilio Alternative SMS API: Send SMS With Your Own SIM Card.

Common Make SMS scenarios

Form submission to instant text

A Typeform, Google Form, or webhook trigger fires, and the HTTP module texts the submitter a confirmation and your team a heads-up. This is the fastest win and a good first scenario to build.

E-commerce order and shipping updates

A Shopify or WooCommerce event maps the customer phone and order number into the message body, so buyers get an SMS the moment their order ships from a number tied to your business.

Scheduled reminders from a spreadsheet

A daily schedule reads today's rows and iterates over them, texting each person a reminder. This pairs the Iterator pattern above with a Sleep module for pacing.

Two-way confirmations and keyword replies

Combine an outbound send with the inbound webhook scenario so a reply of YES, DONE, or STOP updates a record automatically. If you would rather build the same flow in a different tool, the same pattern works in n8n and Zapier.

The whole integration comes down to one HTTP module for sending and one custom webhook for receiving. To try it, connect a phone from the download page and create a SimGate account to get your API key and device ID.

FAQ