SMSAlert
MessagingConnect AI agents to SMSAlert, a Romanian messaging platform that unifies SMS gateways, GSM modems, Android phones, WhatsApp, Telegram, and push. Agents send, schedule, and bulk-send messages, check delivery status, and list sent and received traffic so one flow covers every attached channel.
What This Integration Enables
SMSAlert is a Romanian messaging platform operated by Xelandru Software SRL in Bucharest, and the thing that separates it from every other gateway in this category is that it has no sender ID. There is no originator parameter, no from field, and no endpoint that lists sender names, because SMSAlert does not think of a message as coming from a name. It thinks of a message as coming from a device. The account has things attached to it, an SMS gateway, GSM modems, an Android phone running SMSAlert Sync, WhatsApp connections, Telegram, and the Alertisimo push channel, and List Devices enumerates them with an identifier, a nickname, a version, and an online flag. Every one of them sends through the same endpoint.
That design makes this connector unusually useful in one specific situation and unusually easy to misuse in another. The useful case is a business that already owns the hardware. A clinic with a SIM in a modem, a logistics office with a spare Android handset, and a support team with a WhatsApp line can all send from the same flow, and the routing is a parameter rather than a separate vendor contract. The risky case is the unpinned send. Send Message and Schedule Message both treat Device ID as optional, and when it is left empty the account's own outgoing rules decide which device carries the message. The API response does not tell you which one it picked. Send Bulk Message goes further and returns a campaign identifier rather than per-message identifiers, so resolving what actually happened means going back through List Sent Messages afterwards.
The WhatsApp picture deserves stating plainly, because SMSAlert runs two different arrangements through that same endpoint. The vendor states it is an Official Meta Partner and documents a WhatsApp Business Platform channel with Meta template approval and the 24 hour customer service window. The vendor also offers unofficial WhatsApp access through a paired connection that appears in List Devices carrying session fields such as a QR pairing token and a last seen timestamp, alongside the GSM modems. Both are legitimate products and both are things you might want. They are not the same commitment, and connected accounts remain subject to WhatsApp's terms. There are no triggers on this connector, because SMSAlert's delivery and inbound callbacks are configured by hand in account settings with no subscription API, and the status hook is a single global slot that a registration would overwrite. Get Message Status and List Received Messages are shipped as polling actions instead, which is what the vendor itself recommends for status.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Appointment reminders that survive a modem going down
A Bucharest clinic sends next day reminders every afternoon. The agent pulls tomorrow's list out of the practice system, normalizes each number to international format, and calls List Devices before it does anything else. Two of the three attached devices report online. The third, the GSM modem that usually carries the SMS half of the run, does not. Rather than sending into a queue that will sit at pending until somebody notices, the agent posts the situation to Slack with the device list attached and the recipient count. An operator either brings the modem back up or pins the run to the WhatsApp connection instead. The reminder text is checked against the 735 character limit first, so a template that grew past it fails in the flow rather than at the gateway.
A scheduled campaign for a fixed local hour
A retailer wants a Saturday morning promotion to land at 09:00, not whenever the flow happens to run. Schedule Message queues each message for a future datetime written as YYYY-MM-DD HH:MM:SS, interpreted in the account timezone rather than UTC, and the format is validated in the flow before the request is issued so a malformed value never reaches a billed send path. The agent builds the schedule from a Google Sheets segment, pins the device, and queues the batch. Because the vendor's specification and its two SDKs disagree on what the scheduled datetime field is called, the connector submits the same value under all three documented names in one request rather than guessing. It is worth confirming the first scheduled send against a live account.
Inbound replies that become work items
Customers answer the reminders. Some confirm, some ask to move, and a few say something that is neither. The agent polls List Received Messages on a schedule, which returns sender, text, seen flag, and timestamp, and classifies each one. Confirmations update the appointment in HubSpot and close. Reschedule requests with an unambiguous date get a proposed slot back through Send Message on the same device the original went out on. Everything else is an automation exception: the agent does not guess at a message it cannot parse, it hands the thread to a person with the original reminder and the reply side by side.
Human-in-Loop Highlight
The gate on SMSAlert is the device, and it is a real gate because Device ID is the only thing standing between a broadcast and the account's own routing rules. Leave it empty and SMSAlert picks. What it picks from is a list that mixes a supervised SMS gateway, a GSM modem with a SIM in it, and, on many accounts, a paired WhatsApp session. That session belongs to an actual person, and it appears in List Devices carrying a connection token and a last seen timestamp rather than WhatsApp Business account fields. Those are different products with different terms, and the send response does not name which one carried the message. On Send Bulk Message the response does not even carry per-message identifiers, only a campaign identifier, so the question of what went where is answered after the fact by paging List Sent Messages.
So the agent does everything except choose. It has already assembled the recipients, measured the body against the 735 character limit, and called List Devices to see what is online. What it posts is a question with the consequences attached: "Reminder batch ready for 340 recipients. Three devices online: SMS gateway dev_1042, Android Sync dev_1188, WhatsApp wa_0031 (paired session, last seen 11 minutes ago). No Device ID set, so account routing would choose. Pin the SMS gateway, or send this one over WhatsApp?" A person answers that in the Flow conversation, and the answer is what runs Send Bulk Message.
That is the shape human-in-the-loop takes under Orchestration as a Service. The judgment is not whether the copy reads well, which the agent could have handled. It is which of several genuinely different delivery arrangements a customer facing broadcast should travel on. That depends on facts the API does not model: which SIM has the plan, whose personal account the paired session is, and whether this campaign is the kind of traffic that belongs on it. One related caution belongs in the same treatment. Schedule Message accepts a datetime in the account timezone, which defaults to Europe/Bucharest, so a flow assembling times from a system that thinks in UTC will queue messages hours away from where the operator expected them.
Agent Capabilities
7 actionsMessaging
3- Send Message Sends one message to one recipient through the unified endpoint. The account's routing rules choose the channel unless Device ID pins it to a specific device. Supports GSM 03.38 conversion to reduce billed segments and automatic URL shortening with click tracking, and returns the message identifier along with the billed segment count.
- Schedule Message Queues one message for a future datetime given as `YYYY-MM-DD HH:MM:SS` in the account timezone, which defaults to Europe/Bucharest. The format is validated in the flow before the request is issued, so a malformed datetime never reaches a billed send path.
- Send Bulk Message Sends one identical message to up to 50 recipients in a single request, optionally scheduled. SMSAlert creates a campaign and paces the individual messages itself, and returns a campaign identifier rather than per-message identifiers. Use List Sent Messages afterwards to resolve the campaign into individual sends.
Reporting
3- Get Message Status Reads the current delivery status of one message by identifier. This is the poll that replaces a delivery webhook, and the vendor recommends it specifically because a message can sit at pending when the sending device loses its connection.
- List Sent Messages Pages through outbound messages with recipient, text, status, failure reason, and timestamp, up to 100 per page. The route that turns a bulk campaign identifier back into a per-recipient account of what happened.
- List Received Messages Pages through inbound messages with sender, text, seen flag, and timestamp, up to 100 per page. The mechanism that lets a flow act on replies without a callback endpoint the account cannot register anyway.
Devices
1- List Devices Pages through the devices attached to the account, the Android app, WhatsApp and Telegram connections, and GSM modems, each with an identifier, nickname, version, and online flag, up to 10 per page. Read this before a batch: it is the only place hardware that dropped its connection becomes visible.
Frequently Asked Questions
What can FlowRunner do with SMSAlert?
FlowRunner agents can run Send Message, Schedule Message, and Send Bulk Message in SMSAlert, plus 4 more actions.
Does connecting SMSAlert to FlowRunner require OAuth?
No. SMSAlert connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.
Can SMSAlert trigger a FlowRunner workflow automatically?
SMSAlert doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with SMSAlert
$100 in credits. No card required. Connect in minutes.