TopMessage
MessagingConnect AI agents to TopMessage, a business messaging platform that sends SMS and WhatsApp through one API. Agents send templated and personalized messages, list and retrieve message history, and verify one-time codes so customer notifications and verification flows run from a single route.
What This Integration Enables
TopMessage is a small surface on purpose, and the size is the argument rather than a gap. Four actions: Send Message, List Messages, Get Message, and Verify Code. One API key, one route, and two networks behind it. SMS and WhatsApp are not separate products with separate credentials and separate consoles here, they are a parameter on the same call, which is a genuinely different proposition from stitching a gateway to a WhatsApp Business provider and reconciling two message logs afterward. The vendor is TopX CJSC, an Armenian company, and its own catalog listing describes the platform as bulk SMS without mentioning WhatsApp at all, which undersells what the API does.
Send Message covers every documented case through one route: a plain SMS, a bulk send, a templated message, a personalized message with per recipient values, a scheduled send, and both WhatsApp modes. Personalization works through a parameters map keyed by recipient number, so a single call can carry different values for every person in the batch. On WhatsApp an approved template identifier is required to open a conversation outside the recipient's messaging window, and free form text works only inside it, which is Meta's official Business Platform behavior rather than an unofficial session gateway. There is also a verification convention worth knowing about: a placeholder in the message body is replaced with a code TopMessage generates, and Verify Code later checks what the recipient typed against it. That makes one time code delivery a first class flow on this connector rather than something you assemble yourself.
Two properties shape how an agent should behave here, and both are honest strengths once you design for them. TopMessage returns real HTTP status codes, which is uncommon among comparable vendors: insufficient balance and rate limiting arrive as their proper statuses rather than as a success envelope with an error string buried in it. And Verify Code is a read, not a send, so it is not billed as a message and reports a mismatch as a successful call with an empty result rather than as an error. Branch on the result, not on whether the call threw. The absent pieces are equally clear. There is no balance action among the four, so an account running dry announces itself as a payment status on the next send. There is no sandbox and no test mode anywhere in the API, and every send is real and billed.
Without FlowRunner
With FlowRunner
Use Case Scenarios
The proof send that stands in for a test environment
An operations team pushes a service notification to a few thousand customers across SMS and WhatsApp. The agent assembles the recipient set from PostgreSQL, builds the parameters map so each recipient's own values land in the placeholders, resolves the channel explicitly, and validates the scheduled timestamp before it goes near the API. Then it does not send the batch. It sends one message, to a number an operator nominated, on the exact channel and with the exact body the batch will use, and confirms with Get Message that it landed. The proof and the batch summary go into Slack together. This is not caution for its own sake. TopMessage offers no dry run, so a real send to a known number is the only rehearsal that exists.
One route, two networks, one decision per customer
An ecommerce operator wants order updates on WhatsApp where the customer has an open conversation and SMS everywhere else. When a fulfillment event fires in Shopify, the agent decides the channel per recipient rather than per campaign. Inside the messaging window, free form text on WhatsApp carries the update. Outside it, the same content goes through an approved template identifier. For customers with no WhatsApp relationship at all, the identical call goes out as SMS with the sender name the account is permitted to use. Because both networks run through Send Message on one credential, List Messages returns one history rather than two that have to be reconciled, and the reporting written into Google Sheets counts a customer once.
One time codes that fail the way they should
A product team runs phone verification at signup. The agent calls Send Message with the code placeholder in the body, TopMessage generates the code and delivers it, and the user types it back. The agent then calls Verify Code, which is a read and is not billed as a message. The important part is how the answer is shaped: a match returns a non empty result, a mismatch returns a successful call with an empty one, and expired codes are always excluded. A flow that branches on whether the action raised an error would treat every wrong code as a valid one, so the branch goes on the result instead. When the mismatch rate on a given route climbs past what the team expects, the agent reports it with the message identifiers attached rather than retrying into the same failure.
Human-in-Loop Highlight
TopMessage has no sandbox, no test mode, and no dry run flag anywhere in its API, and no cancel action among its four operations. Those two facts together decide where the digital andon cord hangs on this service. Once Send Message returns, the send has happened and List Messages is the only instrument left. There is nothing to recall and nothing to inspect beforehand, which means the only rehearsal available is a real, billed message to a real phone that somebody owns. That is not a workaround, it is the design the vendor shipped, and an agent operating on this connector should be explicit about it rather than pretending a validation step is a test.
So the gate is the proof send, and what the agent asks for is a number rather than permission. Into Slack: "Service notification ready. 4,120 recipients: 2,860 SMS, 1,260 WhatsApp of which 1,090 need the approved template because their window is closed. Scheduled 2026-08-13T07:00:00Z, validated as UTC and round tripped, so it is not going to silently become now. Link shortening is on, which rewrites the URLs in the customer's message. TopMessage has no test mode and no cancel, so I would like to send one proof to a number you name, on the WhatsApp template path since that is the half most likely to be wrong. Which number, and confirm the send time?"
The two parameters that message calls out are the two this API will get wrong quietly rather than loudly. Channel defaults to SMS, so an unrecognized value would deliver an SMS where a WhatsApp message was intended, billed on the wrong network with no error anywhere. The scheduled time defaults to now, so a malformed timestamp turns a Tuesday morning campaign into an immediate one. This connector refuses both locally before the request goes out, which closes the machine half of the problem. What no validation can settle is whether this recipient list and this moment are the intended ones, and that is precisely the kind of judgment human-in-the-loop exists to route to a person under Orchestration as a Service. The agent has already done everything it can prove. It stops at the one thing it cannot.
Agent Capabilities
4 actionsMessaging
3- Send Message Sends over SMS or WhatsApp through a single route with a single credential. One call covers a plain message, a bulk send, a stored template by identifier, a personalized send with per recipient values supplied as a map keyed by phone number, a scheduled send, and both WhatsApp modes. Supply either free form text or a template identifier, never both. On WhatsApp an approved template is required to open a conversation outside the recipient's messaging window. Link shortening is available and rewrites the URLs in the customer's message, and the scheduled time must be a real UTC timestamp because an unparseable one would otherwise be treated as an instruction to send immediately.
- List Messages Returns the account's message history. This is the polling substitute for the trigger this API cannot support, and with no cancel operation anywhere in the surface it is also the instrument for finding out what a send actually did.
- Get Message Retrieves a single message by identifier, which is how a flow confirms a specific send landed rather than inferring it from a batch summary.
Verification
1- Verify Code Checks a code the recipient entered against the one TopMessage generated for the message. This is a read rather than a send, so it dispatches nothing and is not billed as a message. Read the result carefully: a match returns a non empty result and a mismatch returns a successful call with an empty one, so branch on the result rather than on whether the call raised an error. Expired codes are always excluded from the check.
Frequently Asked Questions
What can FlowRunner do with TopMessage?
FlowRunner agents can run Send Message, List Messages, and Get Message in TopMessage, plus 1 more action.
Does connecting TopMessage to FlowRunner require OAuth?
No. TopMessage connects to FlowRunner with an API key, no OAuth flow required.
Can TopMessage trigger a FlowRunner workflow automatically?
TopMessage doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with TopMessage
$100 in credits. No card required. Connect in minutes.