ASPSMS
MessagingConnect AI agents to ASPSMS, a Swiss SMS gateway operated by VADIAN.NET. Agents send text and token SMS, verify two-factor codes, check credits, and manage originators and vouchers so notification and verification flows run through one Swiss gateway.
What This Integration Enables
ASPSMS has been run out of St. Gallen by VADIAN.NET AG for long enough that the API's shape tells you what it was built for. It is a Swiss gateway whose unit of account is the credit, not the message, and whose second product is verification rather than campaigns. There is no contact list here, no segment builder, no broadcast. There is a send with a full option set, a minimal send, a two-factor token flow with its own storage and its own status vocabulary, and a set of operations for moving credit around. That is a deliberate surface. Pick this connector when the messages you send are transactional and the thing you actually need to be right about is whether the code arrived and whether the balance holds.
The verification flow is the part worth designing around. Send Token SMS generates a code from a mask or takes one you supply, stores it against the recipient number and a token reference, and Verify Token checks a user-entered value against it. Because the reference is part of the match, several tokens can be outstanding for the same number without colliding, which is what makes the flow usable for a person who requests a new code before the first one arrives. The outcomes come back as documented status codes rather than a boolean: authorized, already authorized, not authorized, expired. Those four are different facts about a user's session and an agent should branch on them differently. Around that sit the operational actions: Check Credits before a run, Inquire Delivery Notifications to poll outcomes by transaction reference, and the originator operations that decide which sender identity a message can legitimately carry. ASPSMS delivers receipts by requesting a notification URL supplied per message rather than through any subscription API, so this connector has no triggers, and polling is the supported path.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Step up verification that branches on the real outcome
An administrator in Okta requests an action that policy says needs a second factor on file. The agent calls Send Token SMS with a mask and a five minute validity, holds the token reference, and waits. When the code comes back from the user, Verify Token returns one of four documented outcomes. Authorized proceeds. Already authorized means the code was consumed once before and the agent treats the second attempt as a replay rather than a success. Expired sends a fresh token. Not authorized increments a counter and, past a threshold, stops and pages the security owner instead of letting an agent grind through a code space.
Alerts that stop before they fail silently
A monitoring flow pages the on call engineer by SMS at any hour. Before dispatching the batch, the agent calls Check Credits, because a send made against an exhausted balance fails and an alert that fails is worse than no alerting at all. If the balance is below the run's requirement, the agent posts to the engineering channel in Slack with the remaining figure and the number of pages queued, and the team tops up before the shift rather than during an incident. When the pages do go out, Send Text SMS carries a transaction ID appended to each recipient so a later Inquire Delivery Notifications call can report exactly which handset received which page.
Reminders sent with the sender identity settled first
Appointments booked through Calendly generate a reminder the day before. The reminders go out under a numeric sender the clinic owns so that recipients recognize it, which means the number has to be authorized. The agent calls Check Originator Authorization and reads the status: no restrictions on the account, pending, not authorized, or already authorized. Only the last two are safe to send from. A pending or unauthorized result stops the run and hands the unlock decision to a person, because completing it means dispatching a chargeable code to that handset.
Human-in-Loop Highlight
Most gates on a messaging connector are about a message reaching the wrong person. The sharpest one here is not about messages at all. Create Voucher takes ASPSMS credits out of this account and turns them into codes, and those codes are bearer instruments: they have no expiration date and any ASPSMS user who holds one can redeem it. Nothing about the operation distinguishes a voucher created to fund a subsidiary from a voucher created because a compromised flow was asked to produce one, and once the code is out there is no revoke action in the API to call. Get Voucher Transactions will tell you afterward what was created and redeemed, which is a record rather than a remedy. So the agent is free to send, to verify tokens, to poll delivery, and to check the balance as often as it likes, all unattended. When a flow reaches Create Voucher, it stops. It pulls the current figure from Check Credits, states what the request would move, and asks the operations owner: "This will convert 5,000 credits into 5 voucher codes, leaving 1,240 credits on the account. Voucher codes do not expire and can be redeemed by any ASPSMS account that holds them. Approve, change the amount, or cancel?" A person answers before any credit leaves. Redeem Voucher sits on the same footing in the other direction, and Send Originator Unlock Code deserves a look too, since it dispatches a chargeable message to a number in order to claim it as a sender. Spending is routine. Transferring is a decision, and decisions that move value belong to people. That distinction is the whole point of Orchestration as a Service: the agent does the work, the human keeps the calls that carry risk.
Agent Capabilities
14 actionsMessaging
2- Send Text SMS Sends a text message to up to 1000 recipients with the full option set: scheduled delivery, flash messages, forced GSM 7-bit to avoid an accidental Unicode surcharge, and per-message delivery, non-delivery and buffered-message notification URLs. Encoding is detected automatically and long messages are concatenated. Each recipient can carry a transaction ID appended after a colon, which is echoed back in delivery notifications and is what makes a later reconciliation possible.
- Send Simple Text SMS Sends a text message with the minimal parameter set: originator, recipients, body and an optional GSM 7-bit restriction. Used where none of the scheduling, flash or notification options apply and the extra parameters would only be noise in the flow. The same length and encoding rules apply.
Two-Factor Authentication
2- Send Token SMS Sends an ASPTOKEN verification code by SMS, generated by ASPSMS from a mask or supplied explicitly. The code is stored against the recipient number and the token reference and is valid for five minutes unless a different validity is given. Used to open a verification step; hold the reference so the matching check can be scoped to this attempt rather than to the number generally.
- Verify Token Checks a code entered by a user against the token previously sent to that number, matched together with the token reference so several tokens can be outstanding for the same handset. Returns four distinct outcomes: authorized, already authorized, not authorized and expired. An agent should branch on all four, because a replay and a wrong code are different facts about a session.
Delivery Reports
1- Inquire Delivery Notifications Looks up the delivery status of previously submitted messages by their transaction reference numbers, returning the delivery status and reason code with their descriptions plus the service centre submission and notification timestamps. This is the polling route for message outcomes when no notification URL was configured on the send.
Originators
3- Check Originator Authorization Checks whether a numeric sender number is authorized for the account, returning four states: the account has no originator restrictions, authorization is pending, the originator is not authorized, or it is already authorized. Used as a guard before a campaign that depends on recipients recognizing the sender.
- Send Originator Unlock Code Asks ASPSMS to generate a random unlock code and send it by SMS to the phone number being claimed as an originator. This is the first half of the two-step unlock flow and it dispatches a chargeable message to a real handset, which makes it a claim of control rather than a lookup.
- Unlock Originator Completes the unlock by submitting the code received on the handset. Once unlocked, the number can be used as the originator of outgoing messages, which is what lets a recipient see a sender they recognize and reply to.
Vouchers
3- Create Voucher Creates one or more voucher codes that transfer ASPSMS credits from this account to whoever redeems them. Vouchers have no expiration date and can be redeemed by any ASPSMS user, including the creator. There is no revocation route, so this is the operation on this connector that belongs behind an explicit human approval.
- Get Voucher Transactions Lists every voucher this account has created or redeemed. Creation date and remarks are returned only for vouchers this account created; for redeemed third-party vouchers those fields are omitted. This is the audit surface for credit movement, and the evidence a person wants before approving another transfer.
- Redeem Voucher Redeems a voucher code and adds its credits to this account's balance. The status codes distinguish a successful transfer from a code that is not a valid voucher, so a failed redemption is a named outcome rather than a silent no-op.
Account
3- Check Credits Returns the number of ASPSMS credits currently available. Credits are consumed per message part and never expire. Used as the guard at the top of any bulk run, because a send attempted against an exhausted balance fails and an alert that fails is discovered by the person who needed it.
- Get API Version Returns the version of the ASPSMS JSON API currently serving requests. Requires no credentials, which makes it a clean connectivity check that does not depend on a working key.
- List Status Codes Returns the full reference list of status codes the API can return, each with its description. Used to resolve a status from any other operation into a human-readable reason before it is written into a log or an escalation message. Requires no credentials.
Frequently Asked Questions
What can FlowRunner do with ASPSMS?
FlowRunner agents can run Send Text SMS, Send Simple Text SMS, and Send Token SMS in ASPSMS, plus 11 more actions.
Does connecting ASPSMS to FlowRunner require OAuth?
No. ASPSMS connects to FlowRunner with an API key, no OAuth flow required.
Can ASPSMS trigger a FlowRunner workflow automatically?
ASPSMS doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with ASPSMS
$100 in credits. No card required. Connect in minutes.