Send SMS from Zapier, Make and Power Automate

You can send SMS from Zapier, Make or Power Automate through CaptiFi Connect today, and none of them has a CaptiFi Connect app to do it with. We haven't built one for any of their directories. What each tool does have is a generic HTTP action that can call any REST API, and a webhook trigger that can receive events from one. That pair covers both directions: the action sends the text, and the trigger brings delivery reports and replies back into the same tool. This post follows each vendor's documentation as it read on 4 November 2026, including the parts that cost money, because two of the three keep the HTTP pieces behind a paid plan.

The ONS asked UK firms with 10 or more staff which technologies they used in 2023, and cloud-based systems and applications came top, at 69%. Automation tools sit in that bucket, along with most of the booking systems and CRMs people want texts to come out of.

The request every tool has to make

Whichever tool you use, the send is one HTTP request, and it's worth setting out once because the three tools ask for its parts in different boxes.

A good answer is a 201 with the message ids under data.messages and what's left of the balance in meta.balance. Anything we couldn't text (a landline, say) comes back in data.rejected with a reason, and isn't charged. The two errors to plan for are 402, which means the balance is empty and nothing went, and 429, the rate limit, which arrives with a Retry-After header in seconds. The quickstart has the same request in cURL, Node.js, Python and PHP.

Two habits matter more here than in your own code. The first is where the key lives: each tool has a proper place for credentials, covered below, and that's where it belongs. Give each workflow its own key, so one can be revoked without breaking the rest; our post on keeping API keys safe has the reasoning.

The second is the idempotency key. All three tools retry failed steps, some of them automatically and quite a lot, and a step that timed out may well have sent its text before it failed. Build the key from the record that started the run (the booking id plus the kind of text), and never from the time or a random value, so every retry carries the same key and gets the first answer back with meta.replayed set to true. Our post on sending a text exactly once explains the mechanics.

How to send SMS from Zapier

Zapier's tool for this is Webhooks by Zapier. Its help centre lists it for the Professional, Team and Enterprise plans, and marks it unavailable on Free. As an action it offers three events named after HTTP methods (GET, POST and PUT) plus a fourth called Custom Request.

POST is the friendlier one. Choose JSON as the payload type, add to, body and client_ref as keys in the Data section, map fields from your trigger into them, and put the headers in the Headers section. Don't leave Data empty. Zapier's help says that if you do, "all fields from the previous step" are sent as the payload, which would post a whole customer record to us when the text needs two fields of it.

Custom Request lets you write the JSON yourself. Zapier "will not parse or format this data for you", so it goes exactly as typed, and a mapped name with a double quote in it can leave you with broken JSON. Stick with POST unless you need something it can't do.

Retries need some thought. Paid plans have Autoreplay, which replays a step that errored. Zapier says it "will attempt to replay the step up to 5 times", with a longer gap each time, and in its own worked example the last replay comes about 10 hours and 35 minutes after the first error. A text that lands ten hours late can be worse than none (a "your table is ready" text certainly is), so decide whether Autoreplay suits each Zap that sends texts. Where it's on, the idempotency key stops a replayed send from going twice.

Sending from Make

In Make it's the Make a request module in the HTTP app. Make's own documentation steers the key away from the Headers field: choose API key as the authentication type and keep the key in a keychain, which it says keeps keys out of your requests and makes rotating them easier. Set the body content type to application/JSON, then pick an input method. With JSON string, you escape reserved characters in mapped values yourself. With Data structure, Make escapes them for you, which is the safer choice when names and messages come from customers.

Two settings change what a failure does. Return error if HTTP request fails, set to Yes, stops the scenario on any 4xx or 5xx answer, so a 402 or a refused number doesn't sail through as if the text had gone. The timeout, under advanced settings, takes anything from 1 to 300 seconds.

For retries Make has a Retry error handler. It stores the failed bundle as an incomplete execution and can complete it automatically; Make's help uses three attempts at 15 minute intervals as its example. It only works with incomplete executions switched on in the scenario settings, and once they're on, Make retries connection errors and rate limit errors by itself. A retried bundle maps the same Idempotency-Key, so it can't send twice.

Sending from Power Automate

Power Automate's HTTP action takes a method, a URI, headers and a body, and Microsoft's training material calls it "The Premium HTTP connection". That decides the licence. On the Free licence, "Connector usage is limited to standard connectors only", so the flow needs a Power Automate Premium licence or a Process licence assigned to it, which Microsoft says lets a flow use premium connectors "no matter what license the owning or triggering user has".

Its retries are the most generous of the three. Microsoft's limits page gives the default policy for flows on Premium and Process licences as "up to 12 retries at exponentially increasing intervals, which scale by seven (7) seconds up to an interval of approximately 1 hour for the last retry". Flows on the Low profile (Free, Microsoft 365 plans and trials among them) get up to two. An outbound synchronous request times out after 120 seconds, and the retry policy can be changed, up to a limit of 90 attempts. Twelve retries of a send with no idempotency key is twelve chances to text someone twice, so add the header.

Getting delivery reports and replies back

We post webhook events when a text is sent, delivered or fails, when someone replies (message.received), when someone texts STOP (opt_out.created) and when a tracked link is tapped (link.clicked). Each tool's webhook trigger gives you a URL to add under Developers, Webhooks in the dashboard. The message events carry your client_ref, so a delivery report can find the row that sent it.

• Zapier's Catch Hook trigger parses the JSON into fields, and Catch Raw Hook passes the body unparsed and "includes headers", up to 2 MB. By default Zapier answers each request with a 200, and says "it's not possible to customize this response". The limit is 20,000 requests every 5 minutes per user, with a 429 above that.
• Make's Custom webhook takes up to 300 requests per 10 second interval into a queue, answering 200 "Accepted", or 400 "Queue is full" and 429 "Too many requests" when it can't. Under advanced settings, Get request headers and JSON pass-through expose the headers and the raw body.
• Power Automate's trigger is called When an HTTP request is received. Its "Who can trigger the flow?" setting has two options that need a Microsoft sign-in token in the request, which our webhooks don't carry, so it has to be set to Anyone. Microsoft calls that a "Legacy setting" with "open access without any additional authentication support".

When a trigger refuses an event (a full queue, a 429), we try again after 1, 5, 30, 120, 360 and 720 minutes, and switch an endpoint off after 100 failures in a row. A retry carries the same delivery id header as the first attempt, so a workflow that stores it can skip repeats. We wait 8 seconds for an answer. All three tools answer faster than that by default, but in Power Automate, if you add a Response action, put it near the top: Microsoft allows an inbound request 120 seconds, and we stop waiting long before.

Checking the signature without writing an app

Every event we send is signed. The X-Connect-Signature header carries t=, the time in Unix seconds, and v1=, an HMAC SHA-256 in hex of the time, a full stop and the raw body, keyed with the endpoint's secret. The webhooks guide has the check in three languages, and our post on webhook signatures explains why it's there. Without that check, a trigger URL works like a password: anyone who has it can start your workflow with whatever they choose to post.

Make can do the check with no code at all. Its sha256 function takes an optional key, and "If the key argument is specified, sha256 HMAC hash is returned instead". With JSON pass-through on, the body arrives as text, so you can feed the time from the header, a full stop and that text into sha256 with your secret, compare the result with v1 in a filter, and let through only events that match. Try it with the endpoint's test button before you rely on it, because the check only passes if the text Make hands over is byte for byte what we signed.

In Zapier, Catch Raw Hook gives a Code by Zapier step the headers and the unparsed body to check. Power Automate is the awkward one. Keep the trigger URL where only the flow's owners can see it, and if it leaks, Microsoft documents how to regenerate the SAS key inside it. Either way, before a workflow does anything that matters with an event, look the message up with GET /messages/{id} and your own key. An id from your account comes back with its status; a made-up one comes back 404.

Testing, and the hour it sends

Build each workflow with a cc_test_ key first. Test sends go through the same checks, cost nothing, reach no phone and still fire signed message.sent and message.delivered events a second or two later, so you can run the whole loop: the trigger fires, the HTTP step sends, the webhook trigger catches the delivery report. Test keys are capped at 50 numbers a request and 300 texts an hour. A test send can't produce a reply or a STOP, so for those use the test button on the endpoint, which sends a signed webhook.test event, and see the test keys page for what else test mode skips.

These tools send whenever their trigger fires, which might be a booking made at two in the morning. Our campaign quiet hours (21:00 to 09:00 London time by default) hold back sends to a list, and a single text sent to a number isn't held. If a text should wait for a decent hour, put a time in schedule_at (up to a year ahead), and it waits on our side; our scheduled SMS page covers the rest.

Common questions

Is there a CaptiFi Connect app for Zapier?

No. CaptiFi Connect has no app in the Zapier, Make or Power Automate directories. You connect it with each tool's own HTTP action and webhook trigger, calling the same REST API any developer would use, and the integrations page shows an example request.

Do I need a paid Zapier plan to send SMS through an API?

Yes, for this method. Webhooks by Zapier, the app that makes the HTTP request, is listed for the Professional, Team and Enterprise plans and marked unavailable on the Free plan.

Can Power Automate send a text message without a premium licence?

Not through the HTTP action. Microsoft describes the HTTP connection as premium, and the Free licence is limited to standard connectors. A Power Automate Premium licence, or a Process licence assigned to the flow, covers premium connectors.

How do I stop an automation sending the same text twice?

Send an Idempotency-Key header built from the record that started the run, such as the booking id and the kind of text. If the tool retries a step that had already got through, CaptiFi Connect returns the first answer and sends nothing. A key that changes on every attempt can't do that, so build it from data that stays the same.