FlowRunner
PricingContact
Theme
Start Free

SMSIndiaHub

Messaging

Connect AI agents to SMSIndiaHub, an Indian bulk, transactional, and OTP SMS gateway. Agents send single, scheduled, group, and bulk SMS, pull delivery reports, and check credit balances so high volume notifications go out reliably and spend stays visible.

8 actions API key available
An order confirmation is due and the notification must travel on the transactional route rather than the promotional one
The recipient number and the order reference come out of the order record, with empty entries dropped before the list is assembled
The recipient batch is measured against the 100 number ceiling the gateway documents, and an over-large batch is refused in the flow rather than partially billed
The Channel value is confirmed present, because an empty one would be dropped from the request and the gateway would route on its own default
Send SMS dispatches with the DLT-registered sender header and returns a job identifier plus a per-recipient breakdown
Get Delivery Report resolves the job identifier into per-recipient operator outcomes, which is the only evidence the message actually landed
A person confirms the sender header and message wording against the DLT panel before the first send after any change to either

What This Integration Enables

SMSIndiaHub is a bulk, transactional, and OTP gateway operated by Cloud Wireless Technologies (I) Private Limited in Bhopal, and it exists on this list for one reason: India. Eight actions, three controllers, and no contacts endpoint, no templates endpoint, and no senders endpoint anywhere on the API, which was established by sweeping 47 candidate action names against the gateway's own action resolution behavior. This is not a platform. It is a pipe into the Indian mobile network, and the value of a connector for it is entirely about getting messages onto that network correctly at volume.

Two setup facts belong up front rather than in a footnote. The credential is a username and password that travel as user and password query-string parameters on every call; this API has no header authentication and no token, and the vendor documents the account's API key as a drop-in replacement for the password in that same field. The Region setting selects the host, and the two hosts are not equivalent in one important respect. The India host serves HTTPS normally. The international host's certificate is issued for the India hostname only, so HTTPS to it fails hostname verification and the vendor's own pages use plain HTTP for it, which means credentials on the International region travel unencrypted. Prefer the India region unless your account only exists on the international panel. Stating that plainly is more useful than pretending the choice does not matter.

The regulatory shape is the rest of the story. SMS to Indian numbers is governed by TRAI's DLT regime, where the sender header is registered on an operator's portal and content is checked against a registered template server-side. The consequence is precise and it changes how a flow should be written: a call this API accepts with error code 0 can still be rejected by the operator because the header is not approved or because the body does not match a registered template. Submission is not delivery here, and the delivery report is the only thing that says otherwise. There is a PEId parameter for the DLT Principal Entity identifier, exposed as an optional pass-through because the vendor mentions it exactly once in its entire reference with no parameter row and no example. There is no template identifier parameter anywhere, and no template endpoint, so template registration happens outside the API entirely. There are no triggers: inbound SMS and missed calls are forwarded to a single URL typed into the panel by hand, with no subscription API, so a second registration cannot exist without destroying the customer's own.

Without FlowRunner

Submission mistaken for delivery The API answers with a success code, the flow moves on, and the operator drops the message for an unapproved header nobody checked
Route decided by whatever is default A transactional notification goes out on the gateway's default channel and gets scrubbed against the DND registry like a promotion
Batch size discovered by partial billing A list of 300 numbers is submitted, the gateway takes what it wants, and reconciling what actually sent is guesswork

With FlowRunner

Delivery confirmed by the operator report Get Delivery Report and Get Message Delivery Status resolve a job into per-recipient outcomes, so a success code is treated as a receipt and not a result
Route stated explicitly every time A blank Channel is refused in the flow rather than sent, so the transactional route is never silently swapped for the promotional one
Batch size checked before dispatch The 100 number ceiling is enforced before the request, naming the actual count, so nothing is partially billed

Use Case Scenarios

Transactional notifications that stay transactional

An order system confirms a shipment and a notification is due. The agent assembles the recipient list, dropping empty entries before stringifying so a null from a mapped field can never be dialed as a phone number, and checks the count against the documented 100 number ceiling rather than letting the gateway take an arbitrary prefix. The Channel is set to the transactional value explicitly. That last step is not paperwork. The vendor's own documentation says a missing channel defaults to normal, and for Indian traffic that silently turns a transactional message into promotional-class traffic scrubbed against the DND registry, which means customers on the registry never receive their order update. The connector refuses a blank Channel rather than sending one. The send returns a job identifier, which Get Delivery Report resolves into per-recipient operator outcomes written back to Shopify.

A scheduled reminder that cannot become an immediate send

A clinic wants appointment reminders queued for 08:00 local. Schedule SMS is a separate action rather than an optional field on Send SMS, which is a deliberate design choice: a schedule value that fails to resolve can never turn into an immediate, billed dispatch. The datetime goes out in the gateway's format with an AM or PM suffix. The agent builds the batch from a Google Sheets roster, splits it into requests of at most 100 recipients, and records each job identifier so the following morning's reconciliation can call Get Delivery Report per job rather than guessing which reminders landed.

Spend visible per route, not just in total

A finance owner wants to know where the messaging budget is going, and on an Indian account the promotional and transactional routes are provisioned and priced separately. Get Balance returns the single figure, which is also the cheapest way to confirm a stored credential still works. Get Credit Balance By Route returns the breakdown, parsed from the packed string the gateway answers with, and the agent posts both into a weekly summary in Slack alongside volume from the delivery reports. When one route runs down while the other has headroom, that is an automation exception: the agent reports it rather than deciding on its own that a transactional send should be rerouted.

Human-in-Loop Highlight

The gate on SMSIndiaHub is the first send after any change to the sender header, the Principal Entity identifier, or the message wording, and it is a gate because there is nothing on this API that can verify any of the three. Under the DLT regime the header must be approved on an operator's portal and the body must match a registered content template. This API has no senders endpoint, no templates endpoint, and no groups endpoint, which was confirmed by probe rather than assumed. Error code 24 for template mismatch proves the gateway is checking content against a registration it will not let you read. So an agent that changes one word of an order confirmation has changed something the operator may reject, and the only signal it will get is a success code followed by messages that never arrive.

So the agent stages everything and asks for the one confirmation it cannot obtain itself. It has the batch assembled, the count validated against the 100 number ceiling, the Channel set explicitly, and the sender header and body ready to go. What it posts is a question that names exactly what it cannot check: "Order confirmation template changed. New body: Your order {{ref}} has shipped and will arrive by {{date}}. Track at {{link}}. Sender header SIHUBS, PE ID 1101...4417. I cannot verify from this API whether that header is DLT-approved or whether this wording matches a registered content template, because no senders or templates endpoint exists. Confirm both against the DLT panel, and I will send to one test number and read Get Delivery Report before releasing the remaining 2,340." A person answers that in the Flow conversation, and the confirmation is what releases the test send.

That is the shape human-in-the-loop takes under Orchestration as a Service. The agent is not asking somebody to proofread. It is reporting that a compliance fact required for delivery lives in a portal this API cannot see, and that a full batch dispatched on an unverified header is credit spent on messages the operator will drop. The one-number test send followed by a delivery report is the pattern that makes the whole thing safe, and it works only because the agent treats the success code as a receipt rather than as proof. One related caution belongs in the same treatment. The sender header length is documented two ways by this vendor, as six characters in the DLT context and as up to eleven alphanumeric characters in the older international document. Neither is enforced in code, because the correct ceiling depends on which market you are sending to.

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

8 actions

Messaging

4
  • Send SMS Sends one message body to up to 100 numbers in a single request and returns a job identifier plus a per-recipient breakdown of message identifiers and message parts. Takes the sender header, the channel, the encoding, and an optional flash toggle. The batch ceiling is enforced in the flow, naming the actual count, rather than dispatched and partially billed.
  • Schedule SMS Queues the same dispatch for a future date and time in the gateway's format with an AM or PM suffix. A separate action rather than a flag on Send SMS, so a schedule that fails to resolve can never become an immediate billed dispatch.
  • Send SMS To Group Sends one message body to every contact of a group stored in the panel, addressed by its numeric group identifier. Extra mobile numbers may be supplied alongside the group, because the vendor's India reference marks that parameter required while its international reference omits it. A blank group selector is refused rather than sent, since it is not a documented way to address every group.
  • Send Bulk SMS Sends a different body to each recipient in one request using the gateway's JSON form. This is the route when the text varies per recipient, and it batches natively so no action loops per item.

Reports

2
  • Get Delivery Report Returns the per-recipient delivery report for one send, by numeric job identifier. This is the evidence that a message reached the handset, as distinct from the send response, which only confirms the gateway accepted the submission.
  • Get Message Delivery Status Returns the operator status, submit time, and done time for one individual message by message identifier. Only the last two days of data are available through this route, so a flow that needs it should call it promptly.

Account

2
  • Get Balance Returns remaining credit as a single figure. Also the cheapest way to confirm a stored credential still works, since this API answers HTTP 200 for authentication failures and reports the real outcome in the body.
  • Get Credit Balance By Route Returns remaining credit broken down per route. The gateway answers with a packed string carrying whatever labels the account is provisioned for, including the vendor's own misspelling of one of them, so the action returns both the parsed breakdown and the raw text.

Frequently Asked Questions

What can FlowRunner do with SMSIndiaHub?

FlowRunner agents can run Send SMS, Schedule SMS, and Send SMS To Group in SMSIndiaHub, plus 5 more actions.

Does connecting SMSIndiaHub to FlowRunner require OAuth?

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

Can SMSIndiaHub trigger a FlowRunner workflow automatically?

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

Start building with SMSIndiaHub

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