Userlist

Userlist is lifecycle email and in-app messaging for SaaS companies. Agents push users and companies, link them together, record behavioral events that drive campaigns, and send transactional messages through the Push API.

Verified 8 actions API key available

Userlist website Platform Documentation Capability data verified 2026-08-19

A workspace finishes its first successful data import in the product

Agent reads the workspace, the account owner, and the properties the onboarding sequence reads

Create Or Update Company pushes the workspace with its plan and seat count

Create Or Update Relationship links the owner to the workspace with their role, embedding the user so both land in one call

Create Event records the activation milestone under a stable snake_case name

Agent posts the day's pushed milestones to the customer success channel

Before any account is removed from Userlist, a person confirms the identifier, because a delete answers the same way whether it matched anything or not

What This Integration Enables

Userlist's Push API has no read route anywhere. No list, no get, no search, no export. Eight operations, all of them writes, and that is the entire published surface. This is not a gap to apologize for, it is a position: your product is the source of truth about your customers, and Userlist is downstream of it. You push facts, and Userlist's own engine decides what mail those facts earn. Teams who want a marketing tool that owns the customer record will find this frustrating. Teams running a SaaS product who already know exactly who their users are will find it exactly right, because it removes the reconciliation problem instead of adding one.

FlowRunner agents push into that model continuously: users and companies, the relationships between them with roles, behavioral events that drive campaigns, and transactional messages over email or in-app. Two details shape how a workflow is built. Anywhere one resource references another you can pass an identifier or embed the whole object, and the embedded form creates or updates that object in the same transaction, which collapses ordering problems into single calls. And every success is a 202 with no body, meaning the payload was valid and taken rather than that anything has happened yet. FlowRunner's connectors layer reports that honestly rather than implying more, and the human-in-the-loop gate goes exactly where an agent cannot see the result of its own action.

Without FlowRunner

Product facts arrive by export Lifecycle mail is keyed off a CSV somebody uploaded, so the sequence describes a state the customer left last week

Two systems, two identity schemes Userlist is keyed on email while the product is keyed on an internal ID, and a customer changing address breaks the link

Cleanup done hopefully A deletion pass runs against identifiers nobody can verify, and the API accepts every one of them

With FlowRunner

Product facts arrive as they happen Users, companies, relationships, and events are pushed at the moment they become true

One identity, carried across Your own identifier addresses the user, so an address change updates a property rather than orphaning a record

Cleanup goes through a person The agent assembles the deletion set with evidence from your own systems, and a person confirms it before it runs

Use Case Scenarios

Onboarding that tracks the product rather than the calendar

Activation milestones happen in the product and land in PostgreSQL. The agent watches for them and calls Create Event as each one occurs: first import completed, first teammate invited, first report shared. Userlist normalizes event names to snake_case whatever case they arrive in, so the workflow settles on one form and stays with it. The onboarding campaigns keyed to those names advance on their own. When a milestone is missed past its usual window, the agent does not send anything itself; it posts the account to Slack so a customer success manager can decide whether that is a product problem or a customer who simply has not started yet.
Billing state pushed without a nightly sync

Subscription changes in Stripe reach the agent as they happen. Create Or Update Company pushes the workspace with its new plan, seat count, and renewal date. Updates here are partial, so sending two properties does not wipe the rest, and an explicit null is how a stored value is cleared rather than kept. The agent writes null deliberately when a trial end date genuinely no longer applies and omits the field entirely otherwise, because those are different instructions and only one of them destroys a value.
One call that pushes a company, its user, and the role between them

A new teammate is invited inside a workspace. Rather than three ordered calls with three chances to half-fail, the agent calls Create Or Update Relationship and embeds both objects: the company with its current properties, the user with their name and email. Userlist creates or updates all three in one transaction. The role travels with the relationship, which is what lets an admin-only sequence exist at all. A summary of the week's role changes goes to the account's shared thread in Intercom so support sees the same picture the lifecycle mail is working from.

Human-in-Loop Highlight

Delete User is the operation where this API's write-only design turns from a convenience into a blind spot. Deleting a user who does not exist is accepted and ignored, and every success returns 202 with no body. Put those together and a delete aimed at a stale identifier, a typo, or the wrong environment's ID space produces a response byte-for-byte identical to a correct one. There is no read route to check before, and none to check after. The agent will never find out that it removed the wrong person, and neither will anyone else until a customer stops receiving mail they were relying on.

So a cleanup run assembles its case from the systems that can actually be read, and hands it over. It posts: "Deletion set ready: 63 identifiers. 58 are accounts closed in the billing system more than 90 days ago. 5 have no matching row in the product database at all, which usually means the identifier is stale rather than the account is gone. Userlist will accept all 63 without telling us which ones matched. Run all 63, or the 58 with billing evidence?" The customer success owner answers. Everything else on this connector runs unattended all day, because a push that is wrong can be corrected by pushing again. A delete cannot.

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

8 actions

Users

Create Or Update User Pushes a user by your own identifier or by email, with properties and subscription preferences. Updates are partial, and an explicit null is how a stored property is cleared.
Delete User Removes a user. Idempotent and silent: a call that matched nothing is accepted exactly like one that matched, which is why this operation waits for a person.

Companies

Create Or Update Company Pushes a company by identifier, with properties such as plan, seat count, and renewal date. A company always needs an identifier, because there is no email to fall back on.
Delete Company Removes a company. Idempotent in the same way, and worth the same care.

Relationships

Create Or Update Relationship Links a user to a company with a role. Either side can be embedded as a full object, which creates or updates it in the same transaction and removes the ordering problem entirely.
Delete Relationship Removes the link between a user and a company without deleting either. The right operation when someone leaves a workspace but stays a customer elsewhere.

Events

Create Event Records a behavioral event against a user or a company. Event names are stored in snake_case whatever case is sent, and these are what lifecycle campaigns are keyed to.

Transactional Messages

Send Message Sends one message over email or in-app, from a stored template or from a supplied subject and body. An in-app message needs a known user and no bare address, and message properties are what the content reads through its templating.

Frequently Asked Questions

What can FlowRunner do with Userlist?

FlowRunner agents can run Create Or Update User, Delete User, and Create Or Update Company in Userlist, plus 5 more actions.

Does connecting Userlist to FlowRunner require OAuth?

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

Can Userlist trigger a FlowRunner workflow automatically?

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

Start building with Userlist

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us