Chatra
MessagingConnect AI agents to Chatra, a live chat widget for websites. Agents read visitor conversations, push proactive messages when a flow detects intent, and keep client records attached to each thread.
What This Integration Enables
Chatra is a live chat widget, and this connector wraps the narrow REST surface Chatra exposes around it. There are two ways to speak into a conversation and one way to read and correct who the visitor is. Send Agent Message posts into a visitor's conversation on behalf of an agent, appearing in the chat as if a human sent it. Send Pushed Message proactively pushes an automated message to start or continue a conversation, such as a targeted greeting or a follow-up. Both take the visitor's client ID and both can be attributed, optionally routed to a group in the pushed case. Get Client and Update Client read and write the visitor's stored name, email, phone, and notes.
Every message action has a full lifecycle, and this is genuinely unusual for a chat channel. Get Message, Update Message, and Delete Message operate on agent messages by ID, and Get Pushed Message, Update Pushed Message, and Delete Pushed Message do the same for automated ones. A message can be edited after it is posted, and it can be removed from the conversation entirely. That is a real safety net and it is worth saying plainly how far it goes: it corrects the record, not the reader. A visitor with the chat window open has already seen the text, and Delete Message does not unsee it. Treat the edit path as cleanup, not as an undo.
The connector's biggest design constraint is one you will hit in the first hour. Chatra's REST API exposes no list endpoints for conversations, messages, clients, or agents, so this extension ships no dropdown lookups and every ID is supplied directly. A flow cannot browse for the visitor it wants to message; it must already hold the client ID, which in practice means the ID arrived from the Chatra dashboard webhook or from a record your own systems stored earlier. Design the flow around that or it will not run.
There are no triggers here, and the reason is specific. Chatra does deliver conversation events, chatStarted, chatFragment, and chatTranscript among them, but it delivers them through webhooks configured in the Chatra dashboard rather than through a webhook-subscription REST API an extension could manage. So FlowRunner does not receive Chatra events natively. Point the dashboard webhook at an endpoint of your choosing and let that start the flow. The API is also rate limited to 60 requests per minute per account, which is generous for conversational work and tight for a backfill loop.
Without FlowRunner
With FlowRunner
Use Case Scenarios
The visitor who does not have to repeat themselves
A chat transcript event reaches your endpoint from the Chatra dashboard webhook, carrying the client ID. The agent calls Get Client to see what is already stored, then reads the transcript and writes back what the conversation established: the visitor's name, their email if they gave it, and a note recording what they were trying to do and what was promised. Because Update Client changes only the fields provided and leaves a blank field untouched, a partial conversation does not blank out details from a fuller earlier one. The agent then creates or updates the contact in HubSpot with the same summary. The next time that visitor opens the widget, whoever picks it up sees a person with history rather than a fresh session.
A proactive message that is honest about what it is
A flow watching checkout behaviour decides that a visitor sitting on a plan comparison page for several minutes is worth reaching. Send Pushed Message delivers a targeted greeting and routes it to the sales group, which is precisely what pushed messages exist for: they are automated by design and the platform models them as a separate object type from agent messages. If the visitor replies, the flow notifies the sales group in Slack with the client ID and the page they were on so a human takes the conversation from there. Nothing about this pretends a person was watching, and that is the point. Update Pushed Message and Delete Pushed Message exist for when the campaign copy needs correcting mid-flight.
Turning chats into something the team can read on Monday
Individual conversations are hard to learn from and a week of them is not. A flow collects the transcripts arriving at your endpoint, calls Get Client for each to attach the visitor's stored profile, and appends a row per conversation to Google Sheets with the topic, whether it reached a human, and how it resolved. Where a conversation raised a question the documentation should have answered, the agent drafts a summary and emails it to the content owner through Gmail. The output is a list of things the site fails to explain, ranked by how often visitors ask, which is a considerably more useful artifact than a chat volume chart.
Human-in-Loop Highlight
Send Agent Message has a field that makes it different from every other send action in this catalog. The message appears in the chat as if a human agent sent it, and you can attribute it to a specific agent by ID, or to an external agent by email and display name. So an automated flow can post a reply that a visitor reads as coming from Katrin in support, complete with her name on it. Nothing in the API stops that, and there is no marker in the conversation distinguishing it from something Katrin typed. The gate is not about the message being wrong. It is that the message is being said by someone who did not say it. The visitor answers Katrin, forms a view of Katrin, and quotes Katrin back in an escalation, and Katrin finds out when the complaint arrives. Delete Message removes the text from the conversation but it cannot remove what was read, and Chatra offers no list endpoint that would let a flow audit what has been posted under whose name, so a wrong attribution is not even discoverable after the fact without knowing the message ID. Chatra already ships the honest alternative and it is a different object: Send Pushed Message is the automated channel, modelled separately, and a flow that uses it is not borrowing anyone's identity. So the agent handles everything up to the point where a name gets attached. It calls Get Client for the visitor's profile, drafts the reply from the transcript, and asks the named agent directly in Slack: "Draft reply ready for client 7c41, asking about SSO on the Professional plan. Proposed text: [draft]. Send this under your name in the chat, send it as a pushed automated message instead, or take the conversation yourself?" That is a question about identity rather than about content, which is exactly why it belongs to a person. Making it a human-in-the-loop step is what lets the profile writes, the transcript logging, and the pushed greetings all run without review.
Agent Capabilities
10 actionsMessages
4- Send Agent Message Sends a message into a visitor's conversation on behalf of an agent, appearing in the chat as if a human agent sent it. Requires the target visitor's client ID. Optionally attribute the message to a specific agent by ID, or to an external agent by email and display name, which is the field that decides whose name the visitor sees.
- Get Message Retrieves a single agent message by its ID, returning its text, type, author, and creation timestamp. Since Chatra exposes no list endpoint for messages, a flow can only reach a message it recorded the ID of.
- Update Message Edits the text of an existing agent message by ID, replacing the original in the visitor's conversation. Useful for correcting the record, though it does not retract what an open chat window has already displayed.
- Delete Message Permanently deletes an agent message by ID, removing it from the visitor's conversation. The same caveat applies: it corrects the transcript rather than undoing the read.
Pushed Messages
4- Send Pushed Message Proactively pushes an automated message to a visitor to start or continue a conversation, such as a targeted greeting or a follow-up. Requires the visitor's client ID, and optionally attributes it to an agent or routes it to a group. This is the object type Chatra models as automated, which makes it the honest channel for a flow speaking on its own behalf.
- Get Pushed Message Retrieves a single pushed message by its ID, returning its text, author, and creation timestamp.
- Update Pushed Message Edits the text of an existing pushed message by ID, which is how campaign copy gets corrected mid-flight without deleting and resending.
- Delete Pushed Message Permanently deletes a pushed message by its ID.
Clients
2- Get Client Retrieves a visitor's profile by client ID, including name, email, phone, notes, and any tracked visitor details. The read that tells a flow whether it is dealing with a stranger or a returning account before it decides how to respond.
- Update Client Updates a visitor's name, email, phone, and notes by client ID. Only the fields you supply are changed and a blank field keeps its current value, so writing back a partial conversation will not erase what an earlier, fuller one established.
Frequently Asked Questions
What can FlowRunner do with Chatra?
FlowRunner agents can run Send Agent Message, Get Message, and Update Message in Chatra, plus 7 more actions.
Does connecting Chatra to FlowRunner require OAuth?
Chatra uses a custom authentication method to connect to FlowRunner.
Can Chatra trigger a FlowRunner workflow automatically?
Chatra doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Chatra
$100 in credits. No card required. Connect in minutes.