FlowRunner
PricingContact
Theme
Start Free

SMS Niaga

Messaging

Connect AI agents to SMS Niaga, a Malaysian bulk SMS platform from Web Impian. Agents send text messages to Malaysian numbers, check credit balances, and manage sender IDs and subscriber groups so local campaigns and alerts go out without manual handling.

Verified 12 actions API key available
SMS Niaga website ↗ Platform Documentation ↗ Capability data verified 2026-08-11
Scheduled pull of tomorrow's confirmed bookings
Agent normalizes each customer's Malaysian mobile number into the published format
Agent reads Get Balance and confirms the remaining credit covers the batch
Agent runs Send SMS in preview mode so the request is processed without anything being delivered
Agent sends the reminders for real, split into batches inside the per-request recipient limit
Per-batch result written back onto each booking record
Account owner approves any change to the sender ID set before the agent applies it

What This Integration Enables

SMS Niaga is a Malaysian bulk SMS platform from Web Impian, and the interesting thing about this connector is how little it does. Twelve actions: send a message, read the balance, and manage sender IDs and subscriber groups. There is no campaign object, no template library, no blacklist API, no delivery report lookup. That is not a gap in the build, it is what the vendor publishes, and it tells you what the product is for. SMS Niaga is a local sender for Malaysian businesses that need order confirmations, booking reminders and short broadcasts to reach Malaysian handsets reliably, without buying into a CPaaS they will never use nine tenths of.

Two design details are worth knowing before you automate against it. The first is that Send SMS carries a preview mode, which processes a request fully without delivering anything. That is a dry run the vendor built, and it is what lets an agent validate a resolved recipient list against the live API before spending a credit. The second is that a sender ID is addressed two different ways: Send SMS takes the sender's registered name, while the get, update and delete operations address a sender by its UUID. Two separate lookups exist in FlowRunner for exactly that reason. It is a small ambiguity, and it is the kind of small ambiguity that turns a routine cleanup into an outage.

Without FlowRunner

Reminders sent by hand Someone copies tomorrow's list into the SMS panel each evening
Credit discovered when it runs out A batch fails partway and the shortfall is found in the delivery result
Sender identity edited casually Sender IDs are added and removed in the dashboard without anyone tracking which flows depend on them

With FlowRunner

Reminders driven by the booking Tomorrow's confirmed bookings become tomorrow's reminders with no retyping
Credit checked before the batch The balance is read in Ringgit and the run stops before it starts if it will not cover the send
Sender identity is a controlled change Adding, updating or deleting a sender ID goes through an approval, because every send depends on it

Use Case Scenarios

Booking Reminders From the Calendar the Team Already Uses

A dental clinic keeps its appointments in Cal.com. Each evening a flow pulls tomorrow's confirmed bookings, normalizes each patient's number into the published Malaysian format, and reads Get Balance to confirm the credit covers the run. It sends the reminders under the clinic's registered sender name, splitting the list into batches that respect the per-request recipient limit so an oversized list is never rejected wholesale. Each patient gets a reminder with their own time, and the front desk stops spending the last half hour of every day in the SMS panel.

Subscriber Groups Kept in Step With the Source of Truth

A retailer manages customer segments in HubSpot and mirrors them into SMS Niaga so campaigns can be addressed by group. A nightly flow reads List Subscriber Groups, compares the set against the segments in the CRM, and calls Create Subscriber Group for new segments and Update Subscriber Group when a segment is renamed. Deletions are the exception: rather than calling Delete Subscriber Group automatically, the agent lists the groups that no longer have a matching segment and posts them for review, because a group that vanished from the CRM might have been renamed rather than retired.

A Broadcast Rehearsed Before It Is Sent

A restaurant wants to tell its regulars about a one-night menu. The agent assembles the recipient list, then calls Send SMS with preview mode enabled. The API processes the whole request, applies its own validation, and returns without delivering anything. The agent reads that result, confirms every number was accepted and the body rendered as intended, and only then repeats the call with preview mode off. The rehearsal costs nothing and catches a malformed number before it becomes a failed send that still consumed the operator's attention.

Human-in-Loop Highlight

On a twelve-action connector the irreversible operation is easy to find, and it is not the send. Delete Sender ID permanently removes a registered sender from the account, and once it is gone no message can go out under that name. Registering a replacement is not instant. Worse, the sender ID is the one object on this API with two identities: Send SMS refers to a sender by its registered name, while the get, update and delete operations refer to it by UUID. An agent reconciling sender IDs against another system is matching names on one side and UUIDs on the other, and a mismatch there deletes the identity every reminder, confirmation and broadcast is sent under. Create Sender ID and Update Sender ID carry a quieter version of the same risk, because marking an entry as default replaces the current default and silently changes the originator on anything that relies on it.

So the agent does the reconciliation and stops before it writes. It posts to the account owner: "Sender ID reconciliation found 1 entry to remove. Name: KLINIKGG, UUID 8f2c..., currently marked default, added 14 months ago. It has no matching record in the CRM sender list. Deleting it is permanent and no message can be sent under that name afterward, and because it is the account default, sends that do not name a sender explicitly will change originator. Approve deletion, or confirm it should stay and I will stop flagging it." The human-in-the-loop pause here protects the brand name on every message the business sends, which on a connector this small is very nearly the whole account.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via preferred channel
Human decides
Agent resumes with decision

Agent Capabilities

12 actions

Messaging

1
  • Send SMS Sends one text message to a batch of Malaysian mobile numbers in a single request, from a registered sender ID. Numbers are given in the published format and a leading plus sign is removed automatically. Preview mode processes the request without delivering anything, which is the dry run to use before a real broadcast.

Account

1
  • Get Balance Retrieves the remaining credit on the account, returned in Malaysian Ringgit both as an integer number of cents and as a preformatted string. Used as the guard before a batch so a send never starts underfunded.

Sender IDs

5
  • List Sender IDs Retrieves every sender ID registered on the account, with the UUID used to address it on the get, update and delete operations and a flag showing which one is the account default.
  • Get Sender ID Retrieves a single registered sender ID by its UUID, including its name, description and whether it is the account default.
  • Create Sender ID Registers a new sender ID. The name is what appears as the originator of a message and is what the send operation expects. Marking the new entry as default replaces the current default, so this operation can change the originator on existing flows.
  • Update Sender ID Updates the name, description or default flag of an existing sender ID by UUID. Fields left blank are omitted from the request rather than cleared.
  • Delete Sender ID Permanently removes a registered sender ID by UUID. Messages can no longer be sent under that name afterward, which makes this the natural approval point on the connector.

Subscriber Groups

5
  • List Subscriber Groups Retrieves every subscriber group on the account with its UUID, name and creation time. The UUIDs returned here are what the other group operations address.
  • Get Subscriber Group Retrieves a single subscriber group by its UUID.
  • Create Subscriber Group Creates a new subscriber group and returns its UUID, which the other group operations use to address it.
  • Update Subscriber Group Renames an existing subscriber group by its UUID.
  • Delete Subscriber Group Permanently removes a subscriber group by its UUID. Worth routing through a review step in any sync flow, since a group missing from the source system may have been renamed rather than retired.

Frequently Asked Questions

What can FlowRunner do with SMS Niaga?

FlowRunner agents can run Send SMS, Get Balance, and List Sender IDs in SMS Niaga, plus 9 more actions.

Does connecting SMS Niaga to FlowRunner require OAuth?

No. SMS Niaga connects to FlowRunner with an API key, no OAuth flow required.

Can SMS Niaga trigger a FlowRunner workflow automatically?

SMS Niaga doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with SMS Niaga

$100 in credits. No card required. Connect in minutes.