ThaibulkSMS
MessagingConnect AI agents to ThaibulkSMS, a Thai bulk messaging gateway with SMS, OTP, and transactional email. Agents send bulk SMS with link tracking, request and verify one time passwords, send templated emails, and check credit balances so Thai customer messaging runs across channels.
What This Integration Enables
ThaibulkSMS is a Thai bulk messaging gateway operated by 1Moby in Bangkok, and choosing a domestic Thai gateway over a global one is a decision about deliverability and about sender name approval rather than about features. Sender names are approved in the vendor's dashboard and must be typed exactly as registered, including case, and there is no endpoint anywhere on this API that lists them, so the sender is a free text parameter by necessity rather than by design. The same is true of email template identifiers and approved sender addresses. That constraint is worth stating plainly, because it means the account setup a team does in the dashboard is load bearing, and a flow built on this connector inherits it rather than working around it.
The surface is deliberately compact and it covers four things: bulk SMS with link shortening, click tracking and scheduled delivery, managed one time passwords over both SMS and email, templated transactional email with merge tags and attachments, and the credit balances behind each. The credit structure is the first thing to design for, because there are three separate pools. Standard and Corporate SMS credit are selectable per send, and email credit is entirely separate, so a healthy SMS balance says nothing about whether an email will go out. The second thing is that verification here fails loudly by design. A wrong, expired or already used code comes back as an HTTP error rather than as a negative result in a success body, so a flow branches on the failure rather than looking for a false flag that will never be there.
Authentication uses two credential pairs because the vendor uses two. The SMS and email surfaces take the account API key and secret as HTTP Basic, while the SMS one time password routes belong to a separate OTP App created in the vendor's OTP manager, with its own numeric key and its own secret sent in the request body. That is not a quirk to work around: the OTP App is also where the code length, the message wording, the expiry and the permitted caller IP range are configured, so those settings live once in the vendor's console rather than being passed per request. Rejected numbers, exhausted pools and failed verifications surface as automation exceptions rather than as a send that reports success while reaching fewer people than intended.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A campaign sent with the rejects treated as work
A Thai retailer sends a promotion to a segment. The agent pulls the audience from Shopify, reads Get SMS Credit to confirm the right pool has headroom, and sends in batches of up to five hundred through Send SMS with link shortening on. The shortener only fires on URLs over twenty five characters, and a long tracking link is exactly the kind that eats a message part. The response returns a per number breakdown: accepted numbers each with a message id and credit cost, and rejected numbers separately. That rejected list is the part most integrations discard. Here it goes back into the CRM as bad contact data and into Slack as a count, so the difference between messages sent and customers reached is visible in the same week rather than at the next audit.
Verification that fails in the direction you can act on
A login or checkout step needs a code. Request SMS OTP delivers to one number and returns both the token that verification needs and a short reference number printed in the message, so the recipient can confirm they are answering the right prompt rather than an older one. Verify SMS OTP checks the code, and a wrong or expired code raises rather than returning a false flag, which means the flow's error branch is the real branch and there is no ambiguous middle. Where SMS is not the right channel, Request Email OTP and Verify Email OTP do the same over email, drawing on the email credit pool and the account API key rather than the OTP App credentials. The verified state is written to Postgres only on a clean pass.
Transactional email with a file that is not on the public internet
An invoice or a booking confirmation has to carry a document that is not publicly reachable. Upload Email Attachment fetches the file from a URL, forwards it to the vendor's attachment store, and returns a UUID that Send Email accepts in place of a public link. The template is an approved one, identified by a UUID copied from the dashboard, with merge tags substituted per recipient. Two ceilings shape the design: five attachments per message and five megabytes total, and files are retained for seven days after which both the file and its UUID stop working. That retention window is a feature for a transactional flow, since nothing accumulates, and a hazard for anything that schedules an email further out than a week.
Human-in-Loop Highlight
The gate on ThaibulkSMS is the scheduling parameter on Send SMS, and it is a gate because of something this API does not have. A probe of thirty five invented sibling paths established that the SMS host carries exactly two routes, the send and the credit balance. There is no message status route, no delivery report lookup and no scheduled message listing anywhere on it. The gateway will happily accept a send scheduled up to a year ahead, and once it does, that send is invisible and unrecallable from every surface this connector can reach. There is no action to list it, no action to inspect it and no action to cancel it. The moment of booking is not the beginning of a reviewable window. It is the last moment a decision exists.
That inverts the usual shape of a messaging gate. On most gateways an agent can schedule freely, because a cancel action sits right there and a human can be asked later. Here later does not exist, so the approval has to happen at booking. Into Slack, before the call is made: "Ready to schedule the Songkran promotion to 12,400 numbers for 2026-04-11T09:00:00+07:00. Standard pool shows 61,200 credits, and this send draws an estimated 12,400 with link shortening on. The gateway accepts a schedule up to a year ahead and offers no route to list, inspect or cancel a scheduled send afterwards, so this is the last point at which it can be stopped. Approve the send time and the audience, or hold?"
Ordinary immediate sends do not go through that gate, and they should not: they are the same message with a recoverable failure mode, and the credit pools already answer the spend question without a person. What waits is the send whose consequences are deferred past the point of intervention. The digital andon cord belongs wherever the system stops being able to change its mind, and on this vendor that place is unusually early. Two nearby facts make the same argument in smaller ways and are stated in their own action descriptions instead of gated. The schedule time must carry the Asia/Bangkok offset or it is rejected outright, which is a good failure rather than a bad one. And Delete Email Attachment is permanent, with no way in this API to ask what still references the file. That is Orchestration as a Service doing the thing it is actually for, which is knowing which of a platform's operations have a way back and which do not.
Agent Capabilities
12 actionsSMS
2- Send SMS Sends to up to five hundred Thai or international mobile numbers in one call, in any of the formats the gateway accepts, and returns a per number breakdown separating accepted numbers, each with its own message id and credit cost, from rejected ones. Optionally shortens long links to save credit, tracks link clicks through a placeholder in the body, schedules delivery up to a year ahead in Asia/Bangkok time, sets a retry expiry window, and overrides the account's default Standard or Corporate credit type.
- Get SMS Credit Returns the remaining SMS credit split into the Standard and Corporate pools that the credit type parameter selects between. The pre flight check before a large campaign, since the gateway rejects a send outright once a pool is exhausted.
SMS OTP
2- Request SMS OTP Generates a one time password and delivers it by SMS to one number, returning the token that verification needs plus a short reference number printed in the message so the recipient can confirm they are answering the right prompt. Code length, message wording, expiry and permitted IP range come from the OTP App configuration rather than from this call.
- Verify SMS OTP Checks a code the recipient typed against the token. A correct code answers with a success status, and an incorrect, expired or already consumed code is returned by the gateway as an error rather than as a negative result, so the flow branches on the failure rather than on a field.
- Send Email Sends a transactional email built from an approved template to one recipient, substituting merge tag values and returning the transaction id with credit consumed and remaining. Supports up to five attachments, each given as a publicly reachable URL or as the UUID of a file previously uploaded, within a combined five megabyte ceiling.
- Get Email Credit Returns the remaining email credit, which is a pool entirely separate from the SMS pools. A healthy SMS balance says nothing about whether an email send will succeed, which is why this is its own check rather than an afterthought.
Email OTP
2- Request Email OTP Generates a one time password and delivers it by email from a dedicated template, returning the token verification needs, a reference number shown in the message, and the transaction id. Unlike the SMS one time password routes this authenticates with the account API key and secret and consumes email credit.
- Verify Email OTP Checks a code against the token from the email request. An invalid or expired code is returned as an error rather than as a success body with a false flag, so the failure branch is the real branch here too.
Email Attachments
4- Upload Email Attachment Fetches a file from a URL and forwards it to the attachment store, returning the UUID that a send accepts in place of a public link. This is the way to attach a file that is not reachable from the public internet. Uploads are capped at five megabytes and retained for seven days, after which both the file and its UUID stop working.
- List Email Attachments Lists the files currently held on the account with each entry's UUID, name and size, one page at a time. This is how a flow finds an existing file or checks what is still inside the seven day retention window before composing a send.
- Get Email Attachment Returns the stored details of one attachment by UUID, so a file can be confirmed before it is attached. A UUID whose retention window has lapsed is reported as not found.
- Delete Email Attachment Permanently removes an uploaded attachment. The UUID stops working immediately and anything still referencing it fails, and this API publishes no route that reports what references a file. Files expire on their own after seven days, so deleting early is an optimization rather than a necessity.
Frequently Asked Questions
What can FlowRunner do with ThaibulkSMS?
FlowRunner agents can run Send SMS, Get SMS Credit, and Request SMS OTP in ThaibulkSMS, plus 9 more actions.
Does connecting ThaibulkSMS to FlowRunner require OAuth?
No. ThaibulkSMS connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.
Can ThaibulkSMS trigger a FlowRunner workflow automatically?
ThaibulkSMS doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with ThaibulkSMS
$100 in credits. No card required. Connect in minutes.