Tars
MessagingSend approved WhatsApp template notifications through a Tars webhook campaign. Agents deliver templated customer messages on the channel most likely to be read.
What This Integration Enables
One action. That is the whole connector, and it is a statement rather than an omission. Everything about the message was already decided before the flow ran: the template was approved by Meta, the wording is locked, the credentials are scoped to one campaign, and the flow's entire contribution is a list of parameters in the right order. Tars publishes no read API, no listing API and no webhook registration, so there is nothing to poll and nothing to subscribe to. Sending is all there is.
What that buys is a reliable seat on the channel customers actually open. Send WhatsApp Notification pushes an approved template to one recipient through a Tars webhook campaign and returns the template name, the delivery status, the message id, the cost and the remaining account balance, which is more accounting detail than most send actions give you. It also carries hidden parameters, which never appear in the message but are readable inside the Tars chatbot flow as urlp values. That is how the order number gets into the conversation before the customer says anything, so when they reply the bot already knows which order they mean and the thread does not start with "what is your reference number." The flow sends. The bot handles what comes back. FlowRunner's job is to decide what is worth sending and to make sure it is right the first time, because on this channel there is no second version.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Shipping notification with the conversation pre-loaded
An order in Shopify moves to fulfilled. The agent assembles the parameters in template order, the customer's first name, the order number and the carrier, and passes the order id and the customer id as hidden parameters. Send WhatsApp Notification delivers the approved template. When the customer replies asking where it is, the Tars bot already holds the order id as a urlp value and answers without asking them for anything. The flow never sees that exchange, and does not need to.
Payment failure recovery on the channel with the highest read rate
An invoice fails in Stripe. Email dunning runs first because it is cheap. If the invoice is still open after the second reminder, the agent escalates to a WhatsApp template with the amount and a payment link, and passes the invoice id as a hidden parameter so the bot can answer follow up questions about that specific invoice. The action returns the cost and the remaining balance, and the agent writes both back to the campaign record so the cost of recovery is visible next to the amount recovered.
Re-engagement driven by a CRM change
A contact in HubSpot moves into a re-engagement stage. The agent resolves which approved template matches the customer's language and segment, fills the parameters from the contact record, and sends. Because credentials are scoped per campaign rather than per account, each campaign carries its own connection, which means an agent can only send through campaigns it has been explicitly given a token for. The scoping is not an inconvenience here. It is what stops a re-engagement flow from reaching for a transactional template it has no business using.
Human-in-Loop Highlight
Parameters are positional. The values fill the template's placeholders in the order the template declares them, and nothing checks that the third value is a date rather than an order number. Swap two entries in the list and the customer receives a grammatically perfect, Meta-approved message that says their order will arrive on 44127 and their reference number is Tuesday. It goes out on WhatsApp, to a real phone, and it cannot be recalled. The cost is not the message fee. WhatsApp template quality is scored by how recipients react, and a template that people block or report loses its rating, and a downgraded template stops being usable at all. One bad ordering can retire the notification path you spent weeks getting approved. So on the first send against any new template, and on any send where the parameter list changes shape, the agent does not fire. It renders the resolved message with the values in position, including the hidden parameters, and posts it: "First send on template order_shipped_v3. Positions resolve to: 1 Maria, 2 SO-44127, 3 Tuesday 14 August. Hidden: order_id 88213. Confirm the ordering, or fix the mapping?" A person reads one sentence and the mapping is either right forever or caught before it reaches anybody. That is the whole reason human-in-the-loop belongs on a one action connector.
Agent Capabilities
1 actions- Send WhatsApp Notification Sends an approved WhatsApp template message to a single recipient through a Tars webhook campaign, returning the template name, delivery status, message id, cost and remaining account balance. Placeholders are filled in order from the parameters list, so the order must match the template exactly, and a template that declares no placeholders must be sent with an empty parameters list. Hidden parameters are not shown to the recipient but are readable inside the chatbot flow as urlp values, which is how conversation context is carried in.
Frequently Asked Questions
What can FlowRunner do with Tars?
FlowRunner agents can run Send WhatsApp Notification in Tars.
Does connecting Tars to FlowRunner require OAuth?
No. Tars connects to FlowRunner with an API key, no OAuth flow required.
Can Tars trigger a FlowRunner workflow automatically?
Tars doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Tars
$100 in credits. No card required. Connect in minutes.