--- title: "Customerly Integration" description: "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." url: https://flowrunner.ai/integrations/customerly date_modified: 2026-08-11T09:36:14-07:00 --- # Customerly [Messaging](https://flowrunner.ai/integrations/category/communication-messaging) 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. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 30 actions · API key · available [Platform Documentation](https://www.customerly.io) · Capability data verified 2026-08-05 1. A signup or plan change arrives from the product backend, because Customerly has no FlowRunner trigger of its own 2. Get User by Email confirms whether this person already exists as a user or only as a lead 3. Create or Update User writes the identified contact with custom attributes and tags in one call 4. Add User to Company associates the person with their account, creating the company record if it does not exist 5. List Tags confirms the segmentation tag exists under the exact name the campaign expects before it is applied 6. The owning teammate is told a new account crossed the threshold that makes it worth a conversation 7. 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](https://flowrunner.ai/integrations/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](https://flowrunner.ai/integrations/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](https://flowrunner.ai/integrations/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 m.oyelaran@nordkap.de. 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](https://flowrunner.ai/concepts/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 8 - **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 4 - **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 2 - **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. ### Tags 3 - **List Tags** Returns every tag name defined in your workspace. Read it before applying a tag, because tags match by name and a near miss silently creates a second one. - **Tag Contacts** Applies a tag to a set of users and leads, or removes it when Untag is enabled, taking contacts via User IDs, User Emails, or Lead Emails. Users listed by email that do not exist yet are created, and a matching lead is upgraded to a user in the process, so this segmentation call is also a write that can create people. - **Delete Tag** Permanently deletes a tag from the workspace by name, removing it from every contact it was applied to. A segment-wide change rather than a local cleanup. ### Messaging 2 - **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 11 - **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. **Work at Customerly?** This integration exposes Customerly to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/customerly. Site index: https://flowrunner.ai/llms.txt