SMSKUB
MessagingConnect AI agents to SMSKUB, a Thai bulk SMS gateway with a managed OTP service. Agents send quick messages and scheduled campaigns, pull delivery reports, request and verify one time passwords, and check credit balances so Thai customer messaging and verification run without manual work.
What This Integration Enables
SMSKUB is the Thai bulk-SMS gateway operated by SMS KUB CO., LTD. in Bangkok, an NBTC Type-One licensed telecommunications operator, and it is the connector to reach if you are messaging Thai handsets. Eighteen actions cover two clearly separated jobs. One is campaign messaging, with immediate quick sends on one side and scheduled, repeating campaigns with tracked short links and per-recipient tag merge on the other. The other is a managed one-time-password service that is not a send helper but a product with its own object model: OTP projects that fix the sender, the wording, the expiry, the code length, the reference-code format, and an allowed source IP list.
That object model is the reason this connector is worth understanding before wiring it up. When you create an OTP project, SMSKUB compiles your message wording into a regular expression, and that compiled pattern later validates any custom code supplied on a request. The wording is not copy. It is part of the verification contract. Request OTP then generates and sends the code against a project and returns the reference number shown to the user, and Verify OTP checks what the user typed. Both are shaped by whichever project they name.
Two response behaviors change how flows should branch. SMSKUB wraps every response in a code, data, and message envelope and reports a number of failures inside an HTTP 200 body, so a send with no credit left answers 200 carrying a 500 code and an error string. This connector inspects the body code as well as the transport status, so a failure can never come back as a silent success. The more subtle case is Verify OTP: a wrong code is a successful request. It answers 200 with a validation result of false, and a flow must branch on that result rather than on the absence of an error. A code that was never requested, has expired, or has already been verified is a genuine error instead, and those three are distinguishable. There are no triggers on this connector, because SMSKUB publishes no webhook subscription API and no delivery-receipt or inbound payload shape anywhere in its documentation. Delivery outcomes are read by polling List Campaign Delivery Reports and List Messages instead.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Login verification the flow does not generate
A signup or login needs a phone number confirmed. The agent calls Request OTP naming an active OTP project, and SMSKUB generates the code, applies the project's wording, expiry, and code length, and sends it from the project's approved sender. What comes back is the reference number the user sees on screen, which is what makes a support conversation possible when somebody says the code did not arrive. When the user submits, Verify OTP returns a verdict inside a successful response, and the flow branches on the verdict. The sender type matters here in a way that is easy to miss: an OTP-type sender is whitelisted and reaches every handset, while a marketing sender is subject to the recipient's marketing opt-out, so a verification message sent from the wrong sender simply will not arrive for some users.
A Thai campaign priced in the language it is written in
A retailer wants a scheduled promotion with a tracked short link and per-recipient names merged from a saved contact list. The agent calls Get Credit Balance first, which returns the remaining credits and the expiry date of the current credit package, then builds the campaign with Send Campaign. The cost model is the part worth planning around: credits are pre-paid and one credit covers one message part, and a Thai-language body fits fewer characters per part than a Latin one, so the same message length costs meaningfully more in Thai. The agent reports the estimated parts alongside the balance to Slack before scheduling. After the send, List Campaign Delivery Reports returns per-recipient status, credits, and baht charged, which reconciles the campaign against the balance.
A scheduled campaign caught before its window closes
A campaign is scheduled for Friday and on Thursday the offer changes. Update Campaign rewrites a scheduled campaign that has not yet been sent, and Delete Campaign removes one along with any remaining repeats. Both stop working once the start time has passed, and the platform answers with a plain refusal at that point. So the agent watches the clock rather than the queue: it lists scheduled campaigns, flags any whose start time is within the next few hours, and raises anything that needs changing as an automation exception while there is still time to act. Update Campaign is a whole-body replacement, so the agent reads Get Campaign first and carries every field forward rather than sending only what changed.
Human-in-Loop Highlight
The gate on SMSKUB is Update OTP Project, and it earns that position because of what a single call to it actually does. The vendor publishes no partial-update semantics, and its only documented example sends the complete body, so this connector requires the full set of fields rather than guessing which subset the API tolerates. That means one call rewrites the sender, the message wording, the expiry, the code length, the reference-code length, the allowed source IP addresses, and the active flag together. Anything the caller did not carry forward is gone. And the wording is not decorative: SMSKUB recompiles it into the regular expression that later validates codes submitted against this project. This is the login path for real customers, and an agent that "just changes the copy" can quietly shorten a code, narrow an IP allowlist, or deactivate the project outright.
So the agent assembles the replacement and refuses to send it. It has already read Get OTP Project for the live values, including the compiled pattern, and confirmed with List Usable Senders that the named sender is still approved and is an OTP-type sender rather than a marketing one. It has also checked the proposed wording for the required {otp} and {ref_code} placeholders and the code lengths against the documented range. What it posts is the diff with the carried values shown, not hidden: "Updating OTP project login-th. Changing wording only. Carrying forward unchanged: sender KUBAUTH (OTP type, approved), expiry 300s, code length 6, ref length 6, IP allowlist 3 entries, active true. New wording: รหัสยืนยันของคุณคือ {otp} (อ้างอิง {ref_code}). SMSKUB recompiles the validation pattern from this wording. Approve the full replacement?" A person answers that in the Flow conversation, and the approval is what runs Update OTP Project.
That is the shape human-in-the-loop takes under Orchestration as a Service. The judgment being asked for is not about the Thai wording, which somebody in the product team already wrote. It is confirmation that a whole-object replacement on the live authentication path is carrying forward everything it should, on a platform where the update route offers no other shape. Two neighboring actions belong behind the same treatment. Delete OTP Project is permanent, and every integration still requesting codes against that identifier is refused outright, which means the failure lands on customers trying to log in rather than on whoever ran the delete. Get Message returns the recipient list and, for OTP traffic, the code that was issued, so a flow reading it is reading live verification secrets and should be built with that in mind.
Agent Capabilities
18 actionsAccount
2- Get Credit Balance Returns the account's remaining credits and the expiry date of the current credit package. Credits are pre-paid and one credit covers one message part, so this is the read that turns a recipient count into a spend estimate.
- List Usable Senders Returns every approved, currently usable sender name with its traffic type and registration state. Sender type matters operationally: an OTP-type sender is whitelisted and reaches every handset, while a marketing sender is subject to the recipient's marketing opt-out.
Messages
4- Send Quick Message Sends one message to one or more numbers immediately, with no scheduling, link tracking, or tag substitution. Returns how many numbers were accepted and blocked, the credits used, and the estimated balance afterwards.
- List Messages Returns a paginated list of sent messages with cost, traffic type, sender, and aggregate delivery counters. Covers both quick sends and the messages a campaign generated.
- Get Message Returns one message by identifier, including the recipient list, the reference number and, for OTP traffic, the code that was issued. A flow reading this action is handling live verification secrets.
- List Campaign Delivery Reports Returns per-recipient delivery results for one campaign: destination, status, credits and baht charged, and the send and update timestamps. This is the route to poll for delivery outcomes, since no webhook exists.
Campaigns
5- Send Campaign Creates and sends a campaign. It can be scheduled and repeated daily, weekly, monthly, yearly, or on a custom interval, can rewrite a link into a measurable SMSKUB short link, and can merge per-recipient values from a saved contact list.
- List Campaigns Returns a paginated list of campaigns with recipients, schedule, cost, and counters.
- Get Campaign Returns one campaign by identifier. Read this before any update, because the update route replaces rather than patches.
- Update Campaign Rewrites a scheduled campaign that has not yet been sent. It is a whole-body replacement, and it stops working once the start time has passed.
- Delete Campaign Removes a scheduled campaign, including any remaining repeats. Like the update, it is refused once the start time has passed.
One-Time Passwords
2- Request OTP Generates a code and sends it using an OTP project's template, code length, reference-code format, and expiry. Returns the reference number shown to the user, which is what makes a support conversation about a missing code possible.
- Verify OTP Checks a code a user entered. It sends no message and consumes no credits. A wrong code returns a successful response carrying a false validation result, so the flow branches on the result rather than on an error. A code never requested, expired, or already verified is a distinct error instead.
OTP Projects
5- Create OTP Project Fixes the sender, the message wording (which must contain the `{otp}` and `{ref_code}` placeholders), the expiry, the code and reference-code lengths, the allowed source IP addresses, and the active state. SMSKUB compiles the wording into a regular expression that later validates any custom code supplied on a request.
- List OTP Projects Returns a paginated list of projects, optionally narrowed to active or inactive.
- Get OTP Project Returns one project including its compiled validation pattern. The mandatory first read before any change, because the update is a full replacement.
- Update OTP Project Replaces a project in full and recompiles its message template. Every field not carried forward is lost, and the project is the live authentication path for real customers.
- Delete OTP Project Permanently removes a project. Any integration still requesting codes against that identifier is refused, so the failure surfaces on customers trying to log in.
Frequently Asked Questions
What can FlowRunner do with SMSKUB?
FlowRunner agents can run Get Credit Balance, List Usable Senders, and Send Quick Message in SMSKUB, plus 15 more actions.
Does connecting SMSKUB to FlowRunner require OAuth?
No. SMSKUB connects to FlowRunner with an API key, no OAuth flow required.
Can SMSKUB trigger a FlowRunner workflow automatically?
SMSKUB doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with SMSKUB
$100 in credits. No card required. Connect in minutes.