Customerly

Connect AI agents to Customerly, a live chat and customer lifecycle messaging platform. Agents sync users and leads, tag and associate them with companies, read conversations, and publish knowledge base content.

30 actions API key available

Platform Documentation ↗ Capability data verified 2026-08-05

A signup or plan change arrives from the product backend, because Customerly has no FlowRunner trigger of its own

Get User by Email confirms whether this person already exists as a user or only as a lead

Create or Update User writes the identified contact with custom attributes and tags in one call

Add User to Company associates the person with their account, creating the company record if it does not exist

List Tags confirms the segmentation tag exists under the exact name the campaign expects before it is applied

The owning teammate is told a new account crossed the threshold that makes it worth a conversation

When a contact asks to be removed, a person decides whether that means unsubscribe or permanent erasure

What This Integration Enables

Customerly draws a line most messaging platforms blur, and the whole connector makes more sense once you see it. A user is an identified contact with is_user set to 1. A lead is someone who engaged but never registered, with is_user set to 0. They have parallel but deliberately unequal action sets: users can be fetched by email or by your custom user_id, listed, deleted by either identifier, unsubscribed, and given attributes; leads can be created or updated, fetched by email, listed, and deleted by email, and that is all. Leads have no user_id because they never had an account. Getting this distinction right at the start of a flow is the difference between a sync that works and one that quietly creates duplicate identities for the same human.

There is a promotion path built into the tag surface, and it is easy to miss. Tag Contacts applies a tag to a set of users and leads, or removes it when Untag is enabled, taking contacts by User IDs, User Emails, or Lead Emails. Users listed by email that do not exist yet are created, and a matching lead is upgraded into a user in the process. That is a write hidden inside what looks like a segmentation call, which makes it powerful and worth handling deliberately: a typo in an email list does not fail, it creates a person.

The messaging surface is smaller than the contact surface and honest about what it is. Send Message sends a message and opens a conversation, with the sender and recipient each being a User, Lead, or Admin teammate. Users and leads are identified by email; admin teammates are identified by an account id you get from List Accounts. The common shape is a message from an admin teammate to a user, or a conversation opened from a user or lead toward a teammate.

The knowledge base is a genuine publishing surface rather than a read-only mirror. List, Get, Create, Update, and Delete exist for both collections and articles. Collections require a title, icon, and slug, with the icon being a Customerly icon name. Articles require a title, body, slug, and parent collection, and carry a Status of Live or Draft plus a Written By field holding the account id of the author, which List Knowledge Base Writers resolves. So yes, an agent can publish help centre content, under a named person's byline, at Live status, and it is worth designing that flow to default to Draft.

There are no triggers on this connector. Customerly does not wake a flow up. A schedule, your product backend, or another system does, and the reads here, List Users and List Leads with pagination and sorting at 100 per page by default, are what a reconciliation flow uses in place of an event.

Without FlowRunner

Product state and messaging state drift The app knows a customer upgraded, the messaging tool still segments them as a trial

Segmentation is done by hand Tags are applied one at a time in the interface, and the tag name is retyped each campaign

Every removal request is treated as a delete A request to stop emailing is answered by erasing the record and the support history with it

With FlowRunner

The profile follows the product Users and leads are created or updated with attributes and tags as the backend changes

Segmentation runs as a batch write A tag is applied across a set of users and leads in one call, matched by email or user id

Removal is a distinction, not a reflex Unsubscribe and permanent deletion are separated, and a person decides which was meant

Use Case Scenarios

The product decides the segment, not the marketer

A customer crosses a usage threshold in the product. The backend calls the flow, and the agent starts with Get User by Email to see the current state, since the correct next action differs depending on whether this person exists as a user, exists as a lead, or is unknown. Create or Update User writes the record matched on user_id or email with custom attributes carrying the usage numbers, and Add User to Company associates them with their account, creating the company if it does not exist. Add Company Attributes then puts the account-level plan and seat count on the company itself, so a campaign can segment by organization rather than by individual. The agent finishes by calling Tag Contacts to apply the lifecycle tag. Nobody opened the Customerly interface, and the segment now reflects what the product actually observed.

A help centre that closes its own gaps

Support conversations reveal the same missing article over and over. A weekly flow reads the recurring themes an agent has been logging to Google Sheets, calls List Knowledge Base Collections to find where a new piece belongs, and calls Create Knowledge Base Article with Status set to Draft, the parent collection set, and Written By resolved from List Knowledge Base Writers. It then posts a link to Slack for the documentation owner to review. Setting Draft rather than Live is the whole design decision here. The article is written, filed, and attributed automatically; a person still decides whether it is right before it starts answering customers on the company's behalf. Update Knowledge Base Article promotes it once approved.

One tag, applied consistently, across two identity types

A campaign targets everyone who attended a webinar, and the attendee list contains a mix of registered customers and people who have never signed up. Rather than branching, the agent calls List Tags to confirm the exact tag name already exists, since Customerly matches tags by name and a near miss creates a second tag nobody notices. It then calls Tag Contacts once, passing registered customers under User Emails and everyone else under Lead Emails. Attendees who were leads and are now customers get upgraded to users in the same call. The agent writes the resulting counts back to HubSpot so the campaign owner can see how many of the attendees were already paying. Delete Tag exists for cleanup afterwards and removes the tag from every contact it was applied to, so it is a segment-wide change rather than a tidy-up.

Human-in-Loop Highlight

Customerly gives an agent two ways to answer "take me off your list" and they are not close to equivalent. Unsubscribe User marks a contact by their internal user id so they stop receiving email campaigns and automations. Delete User by Email, and its twin Delete User by ID, permanently delete the person and, in the vendor's own words, all conversations, survey responses, and campaign or automation details for that user are removed forever. Delete Lead by Email does the same on the lead side. The support history goes with it. The survey response that explained why they nearly churned goes with it. There is no restore. What makes this a genuine judgment rather than a policy lookup is that the two requests arrive in identical language: a customer writes "please remove me" and means stop emailing, or means erase everything you hold about me under a data subject request, and only the second one warrants the destructive call. Automating that choice picks a side on every future request without anyone noticing which. The identity risk compounds it, because deletion matches on email, and Tag Contacts elsewhere in this same connector creates users from emails that do not exist yet, so an account can hold a record created by a typo sitting one character away from a real customer. So the agent does the preparation and stops. It calls Get User by Email for the full profile, notes whether any conversations or survey responses exist under it, and asks the support owner: "Removal request from [email protected]. Matching user has 14 conversations, 2 survey responses, and an open subscription. Unsubscribe User stops all campaigns and keeps the support history. Delete User by Email removes the person and every conversation permanently and cannot be undone. Which did they mean?" That question has a legal answer, a commercial answer, and a human answer, and they do not always agree, which is precisely why it goes to a person. Treating it as human-in-the-loop is what makes the thousands of routine profile and tag writes safe to run untouched.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via email

Human decides

Agent resumes with decision

Agent Capabilities

30 actions

Users

Create or Update User Creates a new identified user or updates an existing one, matched by user_id or email, in your workspace. Users represent registered contacts with is_user set to 1. Custom attributes go in as a key/value object and tags as an array of tag names, and the response reports how many records were inserted.
Get User by Email Fetches a single user's complete profile by email, including custom attributes, segments, tags, tracked events, and notes. The read that tells a flow whether it is creating or updating before it writes.
Get User by ID Fetches a single user's complete profile by your custom user_id, returning the same full record. Use it when your backend holds its own identifier and the email may have changed.
List Users Returns a paginated list of users along with match and total counts, supporting pagination and sorting and defaulting to 100 per page. This is what a reconciliation flow reads on a schedule in the absence of any trigger.
Delete User by Email Permanently deletes a user identified by email. All conversations, survey responses, and campaign or automation details for that user are removed forever. This cannot be undone, and it is the action that answers a data subject erasure request rather than an unsubscribe request.
Delete User by ID Permanently deletes a user identified by your custom user_id, with the same total and irreversible removal of their conversations, survey responses, and campaign details.
Unsubscribe User Marks a user as unsubscribed by their Customerly internal user id so they no longer receive email campaigns and automations. The reversible answer to a removal request, and usually the one the customer actually meant.
Add User Attributes Adds or updates custom attributes on an existing user without overwriting the rest of their profile, taking attributes as a key/value object. The safe write when a flow knows one new fact about someone and should not restate the others.

Leads

Create or Update Lead Creates a new lead or updates an existing one matched by email. Leads are contacts who engaged but are not yet registered users, with is_user set to 0. Custom attributes go in as a key/value object and tags as an array of names.
Get Lead by Email Fetches a single lead's complete profile by email, including custom attributes, segments, tags, tracked events, and notes. Leads are addressable by email only, since they have no user_id.
List Leads Returns a paginated list of leads with match and total counts, supporting pagination and sorting and defaulting to 100 per page.
Delete Lead by Email Permanently deletes a lead identified by email, removing all conversations, survey responses, and campaign or automation details for that lead forever. This cannot be undone.

Companies

Add User to Company Associates a user with a company, creating the company if it does not exist. Identify the user by internal id, custom user_id, or email, only one of which is required, and optionally set the company name and custom attributes. This is what makes account-level segmentation possible rather than person-level only.
Add Company Attributes Adds or updates custom attributes on a company identified by its custom company id, optionally renaming the company. Attributes go in as a key/value object.

Messaging

Send Message Sends a message and opens a conversation, setting the sender and recipient each as a User, Lead, or Admin teammate. Identify a user or lead by email and an admin teammate by their account id. The common shape is a teammate messaging a user, or a conversation opened from a user or lead toward a teammate.
List Accounts Returns the accounts, meaning admins and teammates, in your workspace with their account ids and emails. Resolve an id here before using it as the sender or recipient of a message.

Knowledge Base

List Knowledge Base Collections Returns knowledge base collections, optionally embedding each collection's articles, paginating, and filtering by locale, defaulting to 20 per page.
Get Knowledge Base Collection Fetches a single collection by id, optionally embedding its articles and filtering by locale.
Create Knowledge Base Collection Creates a new collection. Title, icon, and slug are required, with description and locale optional. The icon is a Customerly icon name rather than a file.
Update Knowledge Base Collection Updates an existing collection by id, setting title, icon, slug, and optional description.
Delete Knowledge Base Collection Permanently deletes a collection by id, which removes the container the articles inside it were filed under.
List Knowledge Base Articles Returns knowledge base articles, optionally restricted to a single collection and paginated, defaulting to 20 per page.
Get Knowledge Base Article Fetches a single article by id, including its HTML body, status, and reaction counts. The reaction counts are the closest thing here to a signal that an article is answering the question it claims to.
Create Knowledge Base Article Creates a new article inside a collection. Title, body, slug, and parent collection are required. Status controls whether the article is Live or Draft, and Written By is the account id of the author, so an automated publish carries a real person's byline. Defaulting to Draft is the deliberate choice.
Update Knowledge Base Article Updates an existing article by id, setting the parent collection, title, body, slug, and optional status, author, and description. The action that promotes an approved draft to Live.
Delete Knowledge Base Article Permanently deletes an article by id, which also removes whatever inbound links and search results pointed at it.
List Knowledge Base Writers Returns the knowledge base writers, each entry giving the account id, name, and email. Resolve the author here before setting Written By on an article.

Frequently Asked Questions

What can FlowRunner do with Customerly?

FlowRunner agents can run Create or Update User, Get User by Email, and Get User by ID in Customerly, plus 27 more actions.

Does connecting Customerly to FlowRunner require OAuth?

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

Can Customerly trigger a FlowRunner workflow automatically?

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

Start building with Customerly

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

Start Building Free Talk to us