Avochato

Connect AI agents to Avochato, a business texting inbox for SMS, MMS, and live chat. Agents send and schedule messages, manage contacts and tags, assign and update tickets, and publish broadcasts so shared inboxes stay responsive without manual triage.

Verified 58 actions API key available

Avochato website ↗ Platform Documentation ↗ Capability data verified 2026-08-12

An inbound text opens a ticket in the shared inbox and nobody has picked it up

Agent calls Fetch Previous Tickets for that contact to read what the customer has already been told

Agent calls List Messages for the thread to confirm no colleague replied in the last few minutes

Agent calls Add Event By Ticket to write the order status and the account tier into the conversation stream

Agent calls Assign Tickets to route the ticket to the owner whose queue matches the topic

Agent posts the ticket link and the context it gathered into the team channel

The assigned rep reads the context, answers the customer in their own words, and closes the ticket

What This Integration Enables

Avochato is a shared texting inbox, and that noun matters more than the sending. Sixty percent of this connector has nothing to do with dispatching messages: it is tickets, assignment, rosters, tags, events, trackable links, and eleven actions that administer the people who work in the inbox. Only seven actions send anything. The product assumes humans are answering, and it gives an agent the job of making their queue better rather than replacing it. That is a rare shape in a messaging catalog, and it is exactly the shape Orchestration as a Service is designed for: the agent does the gathering, the routing and the record keeping, and a person writes the sentence the customer reads.

The pieces that make this work are the ticket and the event stream. A ticket is Avochato's word for a conversation thread, and Fetch Previous Tickets returns the earlier conversations this contact had, which is how a rep opens a thread already knowing the history. Add Event By Phone, Add Event By Contact and Add Event By Ticket write custom events into that stream, so a purchase, a click or a signup that happened somewhere else appears inline alongside the messages, optionally with revenue attached. Assignment is a first-class surface: assign to a named user by ID or email, hand off to the account's auto assignment roster, unassign back to the pool, or mark a ticket unaddressed to move it in and out of the queue without changing its status. Broadcasts follow a deliberate two-step shape, created as a draft and only sent by an explicit publish. Two operational notes worth knowing. Every inbox scoped action takes an optional Inbox parameter valued by subdomain, so one flow can legitimately address several inboxes rather than needing a connection per inbox. And Avochato authenticates with a token pair carried in the query string or request body rather than a header, which is the vendor's design; FlowRunner's connector masks both values in everything it logs, including inside error messages the vendor echoes back. Avochato publishes no webhook subscription API at all, so this connector has no triggers, and List Messages and List Tickets with their timestamp ranges are the supported polling substitute.

Without FlowRunner

Context assembled per conversation A rep opens a thread and goes looking through other systems before they can say anything useful

Routing by whoever notices Tickets are picked up by availability rather than by fit, and the same customer gets a different owner each time

Broadcast size unknown until billed A promotional send goes out and its true audience becomes clear from the invoice

With FlowRunner

Context arrives with the ticket Order status, tier and prior conversations are written into the stream before a human opens it

Routing follows the topic Assignment happens from the content of the message, with the roster as the fallback rather than the rule

Audience counted before publishing Get Broadcast Audience Count runs first, so the size and cost are a decision rather than a discovery

Use Case Scenarios

The rep opens a thread that already knows the customer

An inbound text arrives and a ticket appears. Before anyone looks at it, the agent calls Fetch Previous Tickets to see what this contact has asked before, pulls the order and account tier from HubSpot, and writes them into the thread with Add Event By Ticket so they sit inline with the messages rather than in another tab. It then calls Assign Tickets based on the topic, or Auto Assign Tickets when no rule matches, which hands the ticket to whoever is next on the roster. The rep opens a conversation that already contains the answer to the first three questions they would have had to ask.

Segmentation built from behavior, not from a static list

A trackable link goes out in a campaign. Create Or Update Link attaches tags that are applied to whoever clicks it, so a click becomes segmentation without anyone maintaining a list. The agent watches for those tags with List Tags and adds its own with Add Tag By Phone when a signal arrives from elsewhere, such as a support case closing in Zendesk. Later, Create Broadcast builds an audience from any combination of those tags, contact IDs, phone numbers and a field match. The audience is a description of behavior rather than a spreadsheet that went stale in March.

A broadcast that is priced before it is sent

The draft exists. The agent calls Get Broadcast Audience Count, which is the only way to see the size and therefore the cost of the send before committing to it. If Update Broadcast has been used to widen the audience, that count is checked again, because the audience parameters on the update are additive rather than replacing, and a second widening can double a send nobody intended to double. The count and the message go to the campaign owner in Slack. On approval, Publish Broadcast runs with either a scheduled time or Send ASAP explicitly set, one of which the action requires precisely so a publish cannot happen through an empty parameter.

Human-in-Loop Highlight

The sharpest risk on this connector is a class of operation where leaving a filter out does not mean "do nothing", it means "do everything". Remove All Contacts is the worst of them, and the vendor states it plainly: with no query, every contact in the inbox is permanently removed. That is not a delete of a segment, it is the address book, and with it every conversation history a rep would have opened tomorrow. FlowRunner's connector refuses to run the action unless a query is supplied or a confirm-all flag is explicitly turned on, and that flag never leaves the flow, because nothing in the request itself distinguishes a deliberate purge from an accidental one. A local guard is the only guard there can be.

Which is exactly why a human belongs at the decision. The guard stops an empty request; it cannot tell whether the query an agent built resolves to the 40 test contacts a CRM sync flagged or to 40,000 real customers because a field name changed upstream. So the agent runs List Contacts with the same query, counts what comes back, samples a handful, and stops: "This purge query matches 11,204 contacts in the support inbox. Here are five of them by phone and name. Expected scope was the 40 records tagged test-import. Run the purge, run it with the tag filter added, or cancel?" Someone with authority over that inbox answers. The same shape covers the two siblings that widen in the same way. Remove All Contacts From Campaign takes every contact off a campaign step and cancels their pending messages, and it exists as its own action precisely so an empty phone list can never silently become everyone. Delete User permanently destroys a colleague's membership of the inbox, unassigns their tickets and revokes their access, where Disable User does the reversible version of the same intent. When an operation cannot be undone and its blast radius is set by something the agent inferred rather than something a person stated, the agent stops. Everything else here, the sending, the tagging, the assignment, the event writing, runs unattended.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

58 actions

Messaging

Send Message Sends an SMS or MMS to a contact by phone number, creating the contact if it does not exist. The sending number is the inbox the credentials belong to unless a From number from the same inbox is given, and there is no sender ID to set. A media URL makes it an MMS, capped by the vendor at 500kb. Messages to a contact marked opted out are refused by Avochato rather than by the flow.
Send Scheduled Message Schedules a message for a future time given as a Unix timestamp, recallable with Cancel Scheduled Message as long as it has not been delivered. Everything else behaves as an ordinary send, which makes the gap between scheduling and delivery the only window in which a mistake is still fixable.
Send Live Chat Message Sends into an active Live Chat session rather than over SMS. The recipient is a live chat session identifier rather than a phone number, and passing a phone number here will not reach a chat session. Use Send Message for SMS.
List Messages Lists messages in the inbox, newest first, filterable by search query, direction, delivery status, the numbers involved, the contact, the ticket, the sending user and a created-at range. Because Avochato publishes no webhook subscription API, this is what a flow polls to learn what happened to a send.
Get Message Retrieves one message by its event ID, including its delivery status. The narrow read for a specific outcome rather than a sweep.
List Scheduled Messages Lists messages queued to send in the future, including campaign follow-ups, individually scheduled messages and delayed auto-responses, filterable by when they are due as well as when they were created. The daily review that shows what is about to go out while there is still time to stop it.
Cancel Scheduled Message Stops a scheduled message from sending. It applies only to messages not yet delivered, since a message already sent cannot be recalled.

Contacts

List Contacts Lists contacts in the inbox, optionally narrowed by a search query and a created-at range, with cursor based paging rather than page numbers. Deleted contacts are hidden unless the include option is turned on. This is the action to run before any destructive operation, because it shows what a query actually matches.
Fetch Contacts Retrieves one or more contacts by ID, several in a single call. Cheaper than looping when a flow already holds the identifiers.
Create Or Update Contact Creates a contact or updates the existing one with the same phone number, since the number is the identity and there is no separate create. Only supplied fields change, and by default an empty value leaves the stored value alone rather than clearing it, which the allow-empty option reverses. Setting opted out stops Avochato delivering outbound messages to this contact, and blocked stops calls and texts in both directions.
Update Multiple Contacts Creates or updates many contacts in one call, each matched on its phone number, with the same field rules as the single contact action. Use this instead of looping when loading a list, both for speed and so the whole load is one auditable step.
Remove All Contacts Permanently removes contacts from the inbox, and with no query supplied that means every contact in it. The connector refuses to run unless a query is given or an explicit confirm-all flag is turned on, and that confirmation never reaches the API because nothing in the request distinguishes the two intents. Deletion cannot be undone.

Events

Add Event By Phone Writes a custom event into a contact's conversation stream, addressed by phone number, so something that happened outside Avochato appears inline alongside the messages a rep is reading. A click, a purchase, a signup, optionally with revenue recorded against it.
Add Event By Contact Writes a custom event into a contact's conversation stream, addressed by contact ID rather than phone number. The same capability where the flow already resolved the contact.
Add Event By Ticket Writes a custom event into a ticket's conversation stream, addressed by ticket ID. This is the action that puts an order status or account tier into the thread itself rather than into a note somewhere else.
Fetch Ticket Events Reads the event stream of one or more tickets, which is the full record of what happened in those conversations including the custom events written by the other event actions. The read that reconstructs a conversation for an audit or an escalation.

Tickets

List Tickets Lists tickets, Avochato's term for a conversation thread, optionally narrowed by a search query. Used to find work waiting on a human and to obtain the ticket IDs the other ticket actions take.
Fetch Tickets Retrieves one or more tickets by ID with their status, owner and contact, several in one call, which is cheaper than looping.
Fetch Previous Tickets Returns the tickets that came before a given one for the same contact, which is how a flow reads a customer's earlier conversations from inside the current thread. The single most valuable read for context gathering here.
Update Ticket Status Sets the status of one or more tickets. Choosing Closed also marks the ticket addressed, which is documented vendor behavior rather than a convenience: closing and addressing are not separate steps, so a flow cannot close a ticket while leaving it in the queue.
Set Ticket Unaddressed Marks one or more tickets addressed or unaddressed. An unaddressed ticket is one still waiting on your team, so this moves work in and out of the queue without changing its status, which is the right lever for a follow-up that is not a reopen.
Assign Tickets Assigns one or more tickets to a user, identified by either their user ID or their email address, exactly one of the two. Assigning does not change the ticket's status, so routing and workflow state stay independent.
Auto Assign Tickets Reassigns one or more tickets to whoever is next on the account's auto assignment roster. If the roster has no active users, ownership is left unchanged rather than cleared, which means an empty roster degrades quietly rather than dumping tickets into the void.
Unassign Tickets Removes the owner from one or more tickets, returning them to the unassigned pool. The clean handoff when someone goes on leave and their queue needs to be redistributed.

Broadcasts

List Broadcasts Lists broadcasts in the inbox, optionally within a created-at range. A broadcast is a message prepared for many recipients that stays a draft until it is published, so this list shows both what went out and what is still pending review.
Fetch Broadcasts Retrieves one or more broadcasts by ID, including whether each has been published and how large its audience is. Several IDs can be fetched at once.
Get Broadcast Audience Count Returns how many contacts a broadcast would reach. Call it before publishing: it is the only way to see the size, and therefore the cost, of a send before committing to it, and it is what turns a publish approval into an informed one.
Create Broadcast Creates a broadcast as a draft. It does not send until the publish action runs, which is what makes the two step shape safe. The audience is built from any combination of tags, contact IDs, phone numbers and a field match, such as every contact whose city is Denver.
Update Broadcast Changes a draft's message or name, or adds more contacts to its audience. The audience parameters are additive: they widen who will receive the broadcast rather than replacing the audience, so the count should be checked again after every update.
Publish Broadcast Sends a broadcast to its whole audience, and this is the point of no return. Either a scheduled time or Send ASAP is required, one of the two, so a publish can never happen through an empty parameter. Every contact in the audience receives a real, billed message.

Campaigns

List Campaigns Lists the campaign steps configured in this inbox. Campaigns are the automated sequences built in Avochato, and the API can read them and remove contacts from them but cannot create them, which is worth knowing before a design assumes otherwise.
Fetch Campaigns Retrieves specific campaign steps by their keywords, which is how a flow confirms a campaign exists and reads its configuration before removing anyone from it.
Remove Contact From Campaign Takes one contact out of a campaign step by phone number and cancels any messages that step still had pending for them. The include-later-steps option removes them from every subsequent step as well, which is the difference between pausing and exiting.
Remove Contacts From Campaign Takes several contacts out of a campaign step at once by phone number, canceling the pending messages for each. Used when an event elsewhere disqualifies a group from a sequence.
Remove All Contacts From Campaign Takes every contact currently on a campaign step out of it and cancels all its pending messages. This cannot be undone, and contacts would have to be re-entered into the campaign. It is a separate action precisely so an empty phone list can never silently become everyone.

Calls

Create Call Token Creates a short-lived token that authorizes a voice call from the browser or a client application. The token is what a calling client exchanges for a session; this action does not place a call itself, which keeps the connector's voice surface an enabling step rather than a dialer.

Accounts

List Accounts Lists the inboxes these credentials can reach with the subdomain of each. Those subdomains are what every action's Inbox parameter takes, so this is where a flow looks when it needs to work across more than one inbox.
Fetch Accounts Retrieves one or more inboxes by subdomain with the name and phone number of each. Used to confirm an inbox exists before an action is addressed at it.
Get Current Credentials Returns which user and which inbox these credentials belong to. The cheapest possible connection check: it sends nothing and costs nothing, and it names the inbox the tokens are bound to, which is the fact people most often get wrong.

Users

List Users Lists the users in this inbox with their email, name, phone, last login, MFA status and creation date. The read behind an access review or an on call roster check.
Get User Retrieves one user's details, role, enabled status, permissions, MFA status and last login, identified by either their encoded ID or their email address.
List User Inboxes Lists every inbox a given user can reach within the organization, with each inbox's subdomain, name, phone number and creation date. The answer to what someone can actually see, which is rarely what a single inbox's user list suggests.
Add User Adds a user to this inbox by email address. An existing Avochato user is added and notified; a new email creates a user and sends an invite. Supplying a phone number starts their MFA setup, and a user role applies a notification preference template that only takes effect for a brand new user.
Update User Role Changes a user's permission level in this inbox. Requires manager or owner rights, and a manager cannot promote anyone to owner or change an existing owner, which is the vendor keeping a floor under privilege escalation.
Delete User Permanently removes a user's membership of this inbox, unassigning their tickets and revoking all their access. Their Avochato login survives; only the membership is destroyed. Use Disable User when the intent is temporary, because this one cannot be undone.
Disable User Suspends a user's access to this inbox. They stop receiving notifications and stop being assigned conversations, their history is preserved, and the change is reversible. The correct action for leave, suspension or an investigation.
Re-enable User Restores a previously disabled user's access to this inbox. Requires manager or owner rights.
Set User MFA Phone Sets or replaces a user's two-factor phone number. The number is stored as pending until the user verifies it with the code Avochato sends them, so this starts the process rather than completing it. Requires organization level permissions.
Trigger Password Reset Emails a user a password reset link that expires after 48 hours. Requires manager or owner rights. This sends a real email to a real colleague, which makes it a poor candidate for a retry loop.
List User Roles Lists the custom user role notification templates defined for this inbox. Their IDs are what the add-user action's role template parameter takes, so read this before inviting anyone rather than guessing at a value.

Frequently Asked Questions

What can FlowRunner do with Avochato?

FlowRunner agents can run Send Message, Send Scheduled Message, and Send Live Chat Message in Avochato, plus 55 more actions.

Does connecting Avochato to FlowRunner require OAuth?

No. Avochato connects to FlowRunner with an API key, no OAuth flow required.

Can Avochato trigger a FlowRunner workflow automatically?

Avochato doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Avochato

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us