Nimba SMS
MessagingConnect AI agents to Nimba SMS, an SMS gateway serving Guinea and the wider West African region. Agents send SMS and WhatsApp template messages, verify phone numbers, manage contacts, and check delivery status and balances so regional customer outreach runs without manual dispatch.
What This Integration Enables
Nimba SMS is operated from Conakry, Guinea, and serves Guinea and the wider West African region. That is the reason to choose it, and it is not a footnote. A global aggregator will quote you a route into West Africa. A gateway operating from inside the region has direct carrier relationships there, and the difference shows up in whether a one time code arrives in seconds or in minutes. For a login screen, that is the difference between working and not working. This connector authenticates over HTTP Basic using a service identifier and secret token that are self serve from the account's API keys page, which is a materially lower barrier than the enterprise CPaaS providers competing for the same traffic.
The platform's real shape is three channels sharing one account and two separate wallets. Send SMS Message is a text send to up to thirty recipients per request. Send WhatsApp Template Message delivers a template that has already been validated on the account, with its numbered placeholders supplied as variables. Send Message is the same endpoint with the channel chosen at run time, across SMS, WhatsApp, or email. And Get Message Balance returns the remaining SMS credits and the remaining WhatsApp credits as two distinct numbers, because they are two distinct pools. That is the fact to design around: a flow that elects a channel dynamically is also electing which wallet it draws from, and one of those wallets can be empty while the other is comfortable.
Sitting alongside that is a first class verification service rather than a do it yourself code loop. Request Phone Verification has Nimba SMS generate a code of four to eight digits, deliver it over SMS or WhatsApp or both, with validity configurable between five and thirty minutes and attempts between three and ten, and verification traffic runs on a high priority queue. Check Phone Verification settles it and returns the resulting status, including the too many attempts case. The connector submits the code as text rather than as a number, deliberately, because a generated code can begin with a zero and a numeric field would silently eat it.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Account verification for a West African user base
A fintech signs users up on a mobile app. The agent calls Request Phone Verification with a validity window matched to how long the app's own screen stays open, and a code length the app's input field actually accepts. When the user types the code, Check Phone Verification returns approved, expired, or too many attempts. Each of those is a different downstream path rather than a single failure branch. Expired offers a resend. Too many attempts locks the flow and opens a support case in Supabase with the verification identifier attached. The support case matters because it is the only durable record. The gateway's message history covers API sends only, so anything a person sent by hand from the Nimba SMS dashboard will not appear in it.
Notifications that respect a thirty recipient ceiling
A logistics operator notifies customers when a shipment is ready for pickup. A single send request accepts at most thirty numbers, so the agent chunks the day's list rather than assuming a larger batch will be quietly split for it. Numbers are accepted in local, country code, or full international form, and blank entries are dropped before the request goes out, so a spreadsheet export with holes in it does not produce an empty recipient list posted to the gateway. Each chunk returns a message identifier, and Get Message Delivery Status reads back a summary per recipient state across to send, sent, received, read, failure, and not available. Those last two states are the ones that go somewhere. They land in Slack as an automation exception with the shipment attached, so somebody calls rather than assuming the customer was told.
Keeping an address book that matches the CRM
Nimba SMS holds contacts and contact groups of its own, and a marketing team selecting a group in the dashboard needs it to mean the same thing the CRM means. A nightly agent reconciles the two. Find Contact By Phone Number is the lookup, and it is worth understanding how it matches. It compares digits only, so local, country code, and international forms of the same number all resolve. When lengths differ, it compares the last nine digits, the length of a Guinean mobile subscriber number. That is exactly right for the market, and exactly the thing to be careful with on international numbers, where two different subscribers can share a nine digit tail. The agent treats a differing length match as a candidate rather than a certainty, creates the contact through Create Contact only on an exact match failure, and writes ambiguous pairs back to HubSpot for a person to settle.
Human-in-Loop Highlight
The gate on Nimba SMS is the channel election, and the reason is structural rather than stylistic. Send Message chooses SMS, WhatsApp, or email at run time. Get Message Balance returns SMS credits and WhatsApp credits as separate numbers. A WhatsApp send requires a template already validated on the account, and Send WhatsApp Template Message will not carry arbitrary copy. There are no triggers, because Nimba SMS pushes status notifications to a URL configured in the dashboard with no subscribe endpoint, so nothing pushes a failure at you. Put those together and you get a failure mode with no alarm attached. An agent instructed to prefer WhatsApp because it is cheaper flips a verification flow onto a channel whose wallet is empty, or whose template was never validated. The only symptom anywhere in the system is a slow rise in users who cannot sign in.
So on any flow where the message is the thing standing between a person and their account, the agent stops before the first send and asks the question the API cannot answer for itself. Into Slack: "Ready to move sign up verification from SMS to WhatsApp for Guinea traffic, about 900 codes a day. Get Message Balance returns 12,400 SMS credits and 780 WhatsApp credits. WhatsApp sends draw only on the WhatsApp pool and require a template validated on this account. Nimba SMS pushes delivery status to a dashboard configured URL with no subscription API, so a channel level failure will not raise anything here. Confirm the WhatsApp template is validated and the pool is topped up, or keep verification on SMS?" That is a two part fact about account configuration and budget, and it lives with the person who administers the account.
That is human-in-the-loop placed at a channel decision rather than at a message, which is where it belongs under Orchestration as a Service for a connector like this one. Notice what is not gated. Sending an individual notification, verifying a code, creating a contact, and reading delivery status all run unattended, because each is reversible, small, and evidence producing. The judgment being escalated is about which pipe an entire class of traffic runs through, and about two facts that live in the account rather than in the API: whether a template is validated and whether the pool behind it has anything in it.
Agent Capabilities
16 actionsMessaging
5- Send SMS Message Sends a text message to up to thirty recipients in one request. Bodies of up to 1,071 characters are billed as up to seven concatenated parts, so the length of a template is a cost decision as well as a copy decision.
- Send WhatsApp Template Message Sends a WhatsApp template already validated on the account, with its numbered placeholders supplied as variables. Draws on the WhatsApp credit pool rather than the SMS one.
- Send Message The same send endpoint with the channel chosen at run time across SMS, WhatsApp, and email. The flexible form, and the one whose channel argument decides which wallet the send draws from.
- Get Message Details Returns a sent message with its body, sender name, send timestamp, overall status, and per recipient delivery records. Note that only messages sent through the API appear here, not messages sent from the dashboard.
- Get Message Delivery Status Reads the same message and returns a delivery summary: the overall status plus a count per recipient state across to send, sent, received, read, failure, and not available. The failure and not available counts are the ones worth routing to a person.
Verification
2- Request Phone Verification Starts a phone verification. Nimba SMS generates a code of four to eight digits and delivers it over SMS, WhatsApp, or both, with validity configurable from five to thirty minutes and attempts from three to ten. Verification traffic runs on a high priority queue.
- Check Phone Verification Confirms the code the recipient entered and returns the resulting status, including approved, expired, and too many attempts. The code is submitted as text rather than as a number, so a code beginning with a zero survives intact.
Contacts
4- List Contacts Returns stored contacts with their groups, paged with limit and offset. The read behind any reconciliation against a CRM.
- Create Contact Adds a contact to the address book, optionally assigning it to groups. Used to keep the audience a marketer selects in the dashboard aligned with the audience the CRM defines.
- Find Contact By Phone Number Looks a contact up by number, comparing digits only so local, country code, and international forms all match. When lengths differ it compares the last nine digits, the length of a Guinean mobile subscriber number, which is right for the market and worth treating as a candidate rather than a certainty on international numbers.
- List Contact Groups Returns contact groups with the number of contacts in each. The inventory a segment rebuild works against.
Sender Names
2- List Sender Names Returns registered sender names with their approval status. The source of truth for what this account is currently allowed to send as.
- Get Sender Name Status Resolves the approval status of one sender name. Sender names are case sensitive and must be accepted before use, since pending and refused names are rejected at send time, which makes this the pre-flight for any new or changed sender.
Account
2- Get Account Information Returns the account identifier, the SMS and WhatsApp balances, the configured delivery webhook URL, and related resource links. The one read that shows where delivery notifications are currently being sent.
- Get Message Balance Returns just the remaining SMS and WhatsApp credits as two separate numbers. The read that belongs before any channel decision, because these pools deplete independently.
Billing
1- List Purchases Returns SMS credit purchase history with amount, quantity, payment method, reference, and invoice link. The reconciliation read behind a monthly messaging cost review.
Frequently Asked Questions
What can FlowRunner do with Nimba SMS?
FlowRunner agents can run Send SMS Message, Send WhatsApp Template Message, and Send Message in Nimba SMS, plus 13 more actions.
Does connecting Nimba SMS to FlowRunner require OAuth?
No. Nimba SMS connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.
Can Nimba SMS trigger a FlowRunner workflow automatically?
Nimba SMS doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Nimba SMS
$100 in credits. No card required. Connect in minutes.