DEV Community: Андрей Джабаров

Trigger SMS from a webhook in 30 seconds, no Twilio

Андрей Джабаров — Fri, 29 May 2026 13:09:17 +0000

Three times in the last month I wanted to send myself an SMS from a script and the answer involved Twilio. Three times I bounced off the same things.

First, Twilio's minimum is $0.0079 per SMS in the US and you pay setup costs that dwarf the per-message price for low-volume use. Second, US 10DLC registration is now mandatory and the verification flow takes days. Third, my account got auto-suspended once for sending three test messages back-to-back from a new number.

For a small-team alerting setup, that is too much friction. PagerDuty starts at $19/user/month. Opsgenie at $9. Both overkill if all you want is "send an SMS to my own phone when the build fails."

What actually worked was a cheap Android phone with a SIM card in a drawer, an API key, and one curl call.

This is the cloud-SMS-forwarder approach. I built SMS Sender 24 because it scratched my own itch, and this article walks through using it (or the open-source equivalents) to trigger SMS from a webhook in 30 seconds.

Three scenarios where this actually helps

Deploy failed at 11 PM. GitHub Actions detects the failure, posts to Slack, but Slack notifications get muted on the on-call phone after hours. Slack is fine for context, not great as the wake-up channel. An SMS cuts through Do Not Disturb without the full critical-alert entitlement song and dance.

Payment of $X received in Stripe. You want to know without checking the dashboard every time. Email works, but at high volume your eyes glaze over. An SMS for transactions above a threshold (say $500) brings the relevant ones to the surface.

Uptime Kuma says the database is down at 4 AM. Push notifications from one more app on your phone get lost. SMS lands in the same inbox as your bank and your boss, which is why it gets read.

The common pattern: you already have the trigger source (CI, payments, monitoring). You already have the destination (your own phone). The annoying middle piece is "get this string to that SIM card without a $500/year contract."

Why Twilio is overkill for this

Twilio is built for sending tens of thousands of SMS per month with regulatory compliance, deliverability guarantees, and global routing. For that use case it is the right answer.

For "send myself 5 SMS per day from internal scripts" it is the wrong answer:

Per-message floor pricing that does not amortize for low volume.
A2P 10DLC registration for US numbers, which now takes days to process and requires a registered business entity.
Account verification friction if you signed up with a personal email or used a VoIP number for SMS receiving.
Random auto-suspensions because the abuse-detection model is tuned for high-volume senders, and your 5 messages from a new number look anomalous.

You can work around all of this. You should not have to.

The alternative: an Android phone with a SIM

Strip the problem down. SMS over the GSM network is sent by a SIM card. If you have a SIM card you can put it in a phone. If the phone is Android you can put a small app on it that pushes the SMS for you when you POST to an endpoint.

The Android phone is the gateway. The SIM is the credential. Your script is the trigger. Total moving parts: 3.

I do not care which cloud forwarder you use, this pattern works with several open-source projects too (SMS2Tg, SMS Forwarder by Spirit532, custom Tasker setups). For the walk-through below I will use the one I built, but the architecture is the same.

Walk-through: pair, get API key, curl

Step 1: register and pair an Android transmitter.

Sign up at smssender24.com on the Free plan. Install the Android app on a phone with the SIM you want to send from (an old phone works, Android 8.0 minimum). In the web dashboard, click "add device", scan the QR code with the Android app. The phone is now your sender gateway.

Step 2: get an API key.

In the dashboard, go to API keys, generate one. Copy it. It looks like a long hex string. Treat it like a password.

Step 3: send an SMS with curl.

curl -X POST https://smssender24.com/api/outgoing-sms \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "recipient": "+15551234567",
    "message": "Deploy failed: builds/2348 (commit abc123, exit code 1)"
  }'

The backend wakes the paired Android via FCM. The Android sends the SMS through the SIM. Total latency from curl to phone vibrating: under 10 seconds typical, sometimes 30 if the Android was deep-sleeping.

If you have multiple transmitters paired and want to pick a specific one, add "apiKeyId": <id>. Omit it and the backend uses whichever transmitter is online.

That's it. The other 27 minutes of setup are picking which webhooks to wire up.

Webhook recipes

GitHub Actions on failure. Add a step to your workflow:

- name: SMS me on failure
  if: failure()
  run: |
    curl -X POST https://smssender24.com/api/outgoing-sms \
      -H "X-API-Key: ${{ secrets.SMSAPI }}" \
      -H "Content-Type: application/json" \
      -d "{\"recipient\":\"+15551234567\",\"message\":\"CI failed: ${{ github.repository }} @ ${{ github.sha }}\"}"

Stripe payment_intent.succeeded over a threshold.

@app.post("/stripe/webhook")
def stripe_webhook(payload: dict):
    if payload["type"] == "payment_intent.succeeded":
        amount_cents = payload["data"]["object"]["amount"]
        if amount_cents >= 50000:  # $500 and up
            requests.post(
                "https://smssender24.com/api/outgoing-sms",
                headers={"X-API-Key": API_KEY},
                json={"recipient": "+15551234567",
                      "message": f"Big payment: ${amount_cents/100:.0f}"},
            )
    return "ok"

Sentry critical issue. Sentry alerts can hit a webhook. Point that webhook at a small Cloudflare Worker that POSTs to outgoing-sms. The Worker is 20 lines.

Uptime Kuma down-alert. Uptime Kuma natively supports custom webhooks. Configure one to POST to the API with the down URL in the SMS body.

The pattern is always the same: source webhook fires, your tiny adapter formats the SMS body, curl to outgoing-sms. The adapter exists because most webhooks send rich JSON and you want to flatten it to one line.

Honest pricing comparison

This matters most for international numbers, where Twilio gets expensive fast.

Channel	Cost per SMS (US)	Cost per SMS (EU)	Setup friction
Twilio	$0.0079	varies, ~€0.04 to €0.06	A2P 10DLC, business verification
SMS Sender 24 Free	€0 (up to 300/mo)	included	sign up, pair phone, done
SMS Sender 24 Pro	€9/mo flat, unlimited SMS	included	same
Open-source APK + your bot	€0 software	+ your time	manage Android, write router

(SMS-per-message cost on this approach is whatever your SIM's own tariff is — many prepaid SIMs bundle hundreds of SMS for a few euros, or include them free. The table prices the platform, not the carrier.)

If you are sending 50 SMS a month to your own phone from internal scripts, you are well inside the Free tier. The math only flips toward Twilio when you need real deliverability guarantees or high-volume global routing.

Where this is weaker than Twilio

I want to be honest, because the audience for this article is people who know their infrastructure choices.

You depend on a SIM card. Twilio gives you a virtual long code or short code with deliverability guarantees. A SIM card can run out of money, get blocked by the carrier for spam patterns, or just die. Have a process for monitoring it.

No phone number routing. Twilio can pick the best route per destination country. With one Android and one SIM, you send from one country.

Compliance. If you are sending marketing SMS to customers, you need 10DLC, consent records, opt-out handling, and an actual SMS-marketing platform. This article is about internal alerts to your own phone. Do not use it to spam customers, that is a different problem and the cheap solution is the wrong solution.

Volume ceiling. SIM cards have practical limits before the carrier flags them. If you are sending more than a few hundred SMS per day, this is the wrong tool.

What I would build next

If I were rebuilding this from scratch I would add idempotency keys to outgoing-sms so retried webhook deliveries do not double-send the SMS. I have not done this yet because nobody has hit the bug in practice, but it is on my list.

Launch offer

If you read this far and the webhook-to-SMS pattern fits something you actually want to wire up, here is the launch deal: take a 5-question survey and get 6 months of Pro free, no card. Pro is unlimited SMS (Free is 300/mo), 5 transmitters, and 90 days of history. The trade is honest — I need real feedback more than I need your money right now, so 5 minutes of your time buys 6 months of the paid tier.

Details: smssender24.com/launch-promo.html. The survey button appears in the dashboard right after signup, and Pro unlocks instantly when you submit. The Free plan is enough for personal alerting if the survey is not your thing.

If you give it a try, my support email is at support@smssender24.com and I read everything. The most useful feedback is "I tried to wire this up to X and got stuck at Y". That is the data I cannot get from analytics.

Originally published at https://smssender24.com/en/

How to watch SMS from multiple Android phones in one iOS app

Андрей Джабаров — Mon, 25 May 2026 20:54:52 +0000

I have an iPhone in my pocket, an old Android with my home SIM at the family house in another country, and a second Android with an Uzbek SIM I use for marketplace OTPs.

For two years I kept solving the same problem the wrong way. SMS from a bank or a delivery service would arrive on one of those Androids, and I had to either ask someone to read it to me, or VPN into a remote desktop, or worse, ship the SIM back to me.

What I actually wanted was simple: every SMS, on every device I owned, in real time, without moving SIM cards.

The shape of the solution is a multi-device viewer. One Android phone holds the SIM and pushes every incoming SMS to a small backend. Every other device (iPhone, iPad, second Android, browser tab) subscribes to that backend and gets a native push the moment the SMS arrives. The SIM never moves.

This post walks through the architecture, the trade-offs against forwarding to Telegram or email, and a 5-minute setup using SMS Sender 24, the tool I built to scratch this itch.

One availability note before the walkthrough: the Android transmitter and web dashboard are live today. The iOS viewer flow is working in early access while the public App Store listing is being finalized, so if you are reading this before the App Store button is live, use the launch promo at the end and I will send the current access path.

TL;DR

Use a multi-device viewer when the SIM has to stay in one Android phone, but the people reading the SMS are somewhere else.

Android keeps the SIM and acts as the transmitter.
iPhone, iPad, Android viewer, and web subscribe as viewers.
Each viewer can see the whole workspace or only one phone's stream.
Viewer pairings are unlimited on every plan.
Telegram/email/webhook still work as channels, but they are not the same thing as per-device access.

Approach	Best for	Where it breaks
Multi-device viewer	SMS on iPhone, iPad, Android and web, with per-phone scope	Needs a backend and a paired transmitter
Telegram forwarding	One person or one shared group chat	No per-user or per-phone access control
Email forwarding	Archival and audit trail	Slow, noisy, no native mobile inbox
Tasker or MacroDroid	One local phone, one owner	Hard to manage for teams or multiple devices
Custom backend	Total control	You own every edge case

Why "forward to Telegram" stops working at two people

The classic SMS forwarder ships every incoming SMS to a Telegram chat. That works perfectly until two things happen at once.

First, two people need to see the same SMS stream but you do not want them to see each other's chats. Second, you want one person to see SMS from a specific phone only, not from every phone in your workspace.

A Telegram chat has no per-user filter. You either invite a person to the chat (they see everything), or you do not (they see nothing). For a small family or a one-phone setup this is fine. For a small team that shares a corporate Android, an agency that holds five client SIMs, or a developer who has two personal numbers and one work number, it falls apart.

Email forwarding has the same problem with extra latency. Webhooks let you build whatever you want, but now you maintain a service.

The multi-device viewer approach treats each device as a real subscriber with its own scope.

What "multi-device viewer" means architecturally

Three pieces.

Transmitter. An Android phone with the SIM. Runs a small app that listens for incoming SMS, packs them up, and pushes them to the backend. One transmitter per SIM. You can have many transmitters in one account.

Backend. A multi-tenant pub/sub server. Each incoming SMS triggers two independent fan-outs. The first goes to "channels" (Telegram, email, Slack, Discord, webhook). The second goes to "viewers" via APNs (iOS) or FCM (Android) push.

Viewers. Any device in receive-only mode. iPhone app, iPad app, second Android in viewer mode, a browser tab. Each viewer has its own pairing with three knobs: can_send (almost always false for viewers), can_view (true), and scope.

The same backend can also trigger outgoing SMS from an API or webhook, but I am intentionally keeping that out of this walkthrough. The narrow problem here is viewing SMS from multiple physical phones without moving SIM cards.

The scope is the interesting one.

scope = tenant: the viewer sees SMS from every transmitter in the workspace.
scope = device: the viewer is locked to one transmitter's stream. SMS from any other transmitter is invisible to this viewer.

That second scope is the unlock. It lets you give your accountant a viewer pairing that only sees the corporate SIM, not your personal one. It lets a freelancer hand a single client a viewer pairing that only sees that client's SMS.

Viewer pairings do not count against your device quota. Free plan = 1 transmitter + unlimited viewers. That pricing pattern alone fixes most of the awkward "we share one login" workarounds I see teams using.

Walk-through: 5 minutes to your first SMS on iPhone

This is what I did to set up my own family inbox, replacing the "forward to a Telegram group" hack I had been running.

Step 1: register a workspace. Sign up at smssender24.com with a Google or email account. You get a free plan and an empty workspace.

Step 2: pair the transmitter. Install the Android app on the phone holding the SIM. Open the web dashboard, click "add device", scan the QR code with the Android app. The phone starts forwarding SMS to your workspace within a second.

Step 3: pair the iPhone as a viewer. Install the iOS viewer app if you have access to the current build. Open the web dashboard, click "add device" again, this time pick scope "tenant" (full workspace). Scan the QR with the iOS app camera. Done.

Now send a test SMS to the SIM in the Android transmitter. The iOS app shows the message in real time, and a lock-screen banner pings the iPhone the same way Apple Messages would.

Step 4: pair an iPad. Repeat step 3 with an iPad. The same iOS app, the same workspace, a second QR pair. The iPad starts getting the same push notifications independently of the iPhone.

Step 5 (optional): add a second workspace. Tap the active connection in iOS Settings → Connections, then "add another phone". Scan a QR from a different workspace (a client account, a family-shared account, a side project). The iOS app now holds two workspaces at once. Tap to switch. No re-login, no two apps.

That last step is the one that surprised me the most. I expected to install five copies of the iOS app for five clients. Instead it is one app, five Connections, instant switching.

Advanced: per-phone delegation with scope=device

Say you run a small team. One Android phone holds the corporate SIM. Three managers each need to see SMS from that specific corporate SIM, but you do not want them to see SMS from any other transmitter you might add later (personal numbers, the founder's number, the test SIM).

When you generate the pairing QR for each manager, pick scope "device" and point it at the corporate transmitter. The manager's iOS or Android viewer app gets SMS from that one phone, and only that one phone, even if you add ten more transmitters tomorrow.

Behind the scenes the backend writes a device_filter_id on the viewer's API key, and the push fan-out checks it before sending. Same backend, same workspace, surgical isolation.

This single feature replaced a Google Sheets + Zapier rule I was using to extract OTP codes from a shared inbox. It saved me 40 minutes a week and removed two moving parts.

Where this approach is weaker

I want to be honest about the cases where this is not the right tool.

Single phone, single person, single Telegram chat. Just use one of the free open-source APKs like SMS2Tg. You do not need any of the multi-device machinery. Smaller blast radius, no SaaS dependency.

Regulated environments where SMS cannot leave a controlled network. The backend is a third-party cloud service, even if I never read your SMS. If your compliance policy says zero third-party processing, self-host the open-source forwarders or write a custom Android collector and your own backend.

You want zero data anywhere. SMS Sender 24 stores SMS for a retention window so the viewer apps can show history. Configurable down to 7 days, but not zero. If your bar is zero, this is not the tool.

Pricing note

Free plan: 100 SMS per month, 1 transmitter, unlimited viewer apps. The "unlimited viewers" part is the one I see people miss. If you only need the multi-device viewer angle and your total SMS volume is light, the Free plan is the entire product for you.

Pro and Business plans raise the SMS count and the transmitter count. The viewer count stays unlimited on every plan.

Launch offer: 6 months of Pro for 5 minutes of feedback

I just opened a launch promo: anyone who signs up and takes a 5-question survey gets 6 months of Pro for free. No card, no auto-renewal, no "first N only" limit. That is $54 of value at the Pro rate, mostly because I would rather pay you in product than do my own bug-hunting.

The five questions: what you tried to do, how you used to solve it, what worked, what is missing, what you would have typed into Google to find this. That is the whole deal. The form is anonymous if you want, and Pro extends automatically the moment you submit.

Details: smssender24.com/en/launch-promo.html. Free plan stays free regardless, so even without the survey you can pair an Android and an iPhone and try the multi-device viewer at no cost.

What I am improving next

The next improvement I care about is making important SMS easier to separate from routine ones.

On iOS, that means better push categories and optional time-sensitive notifications for things like OTP codes or server alerts. Apple lets Time Sensitive notifications break through Focus and Notification Summary, but users can turn that behavior off, so I would not treat it as a guaranteed emergency channel.

On the backend, it means better delivery visibility: which viewer devices received the push, which channel failed, and whether a webhook needs to be replayed. Boring logs beat clever abstractions when an SMS code is missing at the worst possible moment.

If you give it a try, I read every email at support@smssender24.com and I am the person who replies. The most useful feedback is "I tried to do X and could not figure out Y". That is the data I cannot get from analytics.

How to Forward Android SMS to Telegram Automatically

Андрей Джабаров — Fri, 22 May 2026 22:45:45 +0000

Bank codes, server alerts, delivery updates and team OTP messages still arrive on one physical Android phone.

If that phone sits in an office drawer, a courier bag or another country, the whole team waits.

This guide compares five practical ways to forward Android SMS to Telegram, from free APKs to Tasker, n8n and a cloud SMS forwarder.

TL;DR: best options

Method	Best for	Setup time	Main trade-off
Cloud SMS forwarder	Teams, multiple devices, business workflows	2-5 min	SMS passes through a third-party service
Open-source APK	Personal use, strict privacy, one phone	15-30 min	Manual setup and maintenance
Tasker / MacroDroid	Power users already using Android automation	30-60 min	Fragile rules and battery optimization issues
n8n webhook	Teams with existing automation infrastructure	1-2 hours	You maintain the workflow and endpoint
Custom app	Regulated environments or internal tooling	Days/weeks	Highest maintenance cost

What SMS-to-Telegram forwarding requires

Every implementation has the same basic pipeline:

An Android app receives incoming SMS using the SMS permissions.
The app formats the message and decides whether it should be forwarded.
A Telegram bot sends the message to a chat, group or channel.

The difference is where the routing logic lives. It can live on the phone, in Tasker, in an n8n workflow, in your own backend or in a SaaS dashboard.

1. Cloud SMS forwarder

A cloud SMS forwarder pairs your Android phone with a web dashboard. Incoming SMS are sent securely to the service, matched against routing rules, then delivered to Telegram, Email, Slack, Discord, X2Chat or a webhook.

Pros: quick QR pairing, multi-device management, routing by sender or keyword, delivery history, team access, webhooks and less manual Telegram bot configuration.

Cons: SMS passes through a cloud service. If your use case requires zero third-party processing, a self-hosted or open-source option is a better fit.

SMS Sender 24 is in this category. It works well when one team needs to share OTP codes, server alerts or business SMS from several Android phones without maintaining Android automation on every device.

2. Open-source Android apps

Projects such as Spirit532 SMS Forwarder and similar APKs can read SMS locally and send them directly to Telegram Bot API or a webhook.

This is the cleanest option if you want to inspect the code and avoid a cloud account.

Pros: free, auditable, no SaaS dependency, good for one phone and one or two destinations.

Cons: you maintain every phone manually. Rules, bot tokens, chat IDs and battery settings are configured per device. Some projects go years without updates, which matters on newer Android versions.

Example Telegram Bot API call:

POST https://api.telegram.org/bot<TOKEN>/sendMessage
Content-Type: application/json

{
  "chat_id": "-1001234567890",
  "text": "SMS from +15551234567: Your verification code is 482913"
}

3. Tasker or MacroDroid

Tasker and MacroDroid can listen for SMS events and call Telegram Bot API through an HTTP action. This is powerful if you already understand Android automation.

Pros: very flexible, cheap, local-first, can combine SMS with other Android triggers.

Cons: hard to support as a team workflow. A missed battery permission, Android update or broken profile can silently stop forwarding. Debugging is usually on the person holding the phone.

This method is great for personal automation. It is less great when three people depend on that phone to receive production alerts or bank OTP codes.

4. n8n webhook workflow

If your team already runs n8n, Make or another automation platform, the Android app can send SMS to a webhook. The workflow can then filter messages and forward them to Telegram.

Example payload:

curl -X POST https://n8n.example.com/webhook/sms \
  -H "Content-Type: application/json" \
  -d '{
    "sender": "AWS",
    "body": "Your alarm is in ALARM state",
    "sim": "work",
    "received_at": "2026-05-23T09:15:00Z"
  }'

Pros: great for teams that already automate alerts and business workflows. You can branch to Telegram, Slack, email or CRM.

Cons: you still need a reliable Android collector app, a public HTTPS endpoint, secrets management, monitoring and retries.

5. Custom Android app

Building your own Android app is reasonable for regulated environments, internal device fleets or very specific routing requirements. It gives you full control over data handling and backend architecture.

Pros: maximum control, private backend, custom security model.

Cons: Android SMS permissions, background execution, foreground services, device reboot handling and battery optimization are easy to underestimate.

The first version is the simple part. Keeping it reliable is the real work.

Android 14/15 pitfalls

SMS forwarding is not just an HTTP problem. Modern Android aggressively limits background work, especially for apps installed outside Google Play.

Watch for these issues:

Battery optimization: the app may stop receiving or forwarding after several hours unless excluded from battery restrictions.
Foreground service rules: long-running background services need a visible notification and correct service type.
Boot handling: forwarding should resume after the phone restarts.
Connectivity gaps: the phone needs Wi-Fi or mobile data. Good apps queue messages and retry.
Dual SIM: personal and work SIMs often need different routing rules.

Which method should you choose?

Scenario	Recommended method	Why
One personal phone, one Telegram chat	Open-source APK	Free and simple enough
Team OTP codes	Cloud SMS forwarder	Rules, history and team destinations matter
Server SMS alerts	Cloud forwarder or n8n	Reliability and routing are more important than novelty
Strict privacy / no third party	Open-source or custom app	Keep data under your control
Existing automation stack	n8n webhook	Easy to plug into current workflows

Honest note

SMS Sender 24 is an independent cloud tool built to solve a real SMS forwarding problem.

It is convenient for teams, but it is not the right choice if your policy requires zero third-party processing. In that case, use an open-source app or self-host the whole pipeline.

FAQ

Can I forward only specific SMS?

Yes. Use sender names, phone numbers, keywords or SIM slots as routing conditions.

For example, bank OTP messages can go to one Telegram chat while courier updates go to another.

Does the Android phone need internet?

Yes. The phone needs Wi-Fi or mobile data to forward messages.

If connectivity drops, a reliable app should queue messages and retry when the connection returns.

Is this different from SMS gateways like Twilio?

Yes. Twilio and similar services provide virtual numbers or outbound messaging APIs.

SMS forwarding starts from a real Android phone and forwards incoming messages from its SIM card.

Can it work with two SIM cards?

Yes, if the collector app records the SIM slot and the service supports SIM-based rules.

This is useful when one phone has both personal and work SIM cards.

Is Telegram the only destination?

No. Telegram is the most common destination, but many teams also forward to Email, Slack, Discord, X2Chat or a webhook.

Originally published at https://smssender24.com/en/blog/forward-android-sms-to-telegram.html