MemberVault
Education & LMSConnect AI agents to MemberVault, a course and membership platform. Agents fetch products, add or remove users from products, and delete users so enrollment stays aligned with purchases and refunds.
What This Integration Enables
This connector has four actions, and that is a position rather than a gap. MemberVault's Webhooks API is deliberately narrow: list the products, add a user to one, remove a user from one, delete a user. There is no progress surface, no messaging, no catalog structure below the product, no reporting. What MemberVault is saying is that the entitlement ledger is the part worth exposing to other systems, and everything else belongs inside the platform where the creator works. An agent built against this connector therefore has exactly one job, and it is a job that goes wrong quietly when nobody automates it: keeping who has access to what in agreement with who paid for what.
There is one detail in that small surface that says more about the design than the action list does. Add User To Product accepts a special product id of negative one, which adds or creates the user in the account without granting access to anything. MemberVault is drawing a line between being known and being entitled, and that line is genuinely useful to an agent. A lead who filled in a form, a webinar registrant, a buyer whose payment is still pending: all of them can exist as accounts, ready to be granted access the moment a decision is made, without anyone having to guess whether presence in the account implies a purchase. It is also the safest possible landing spot for an ambiguous order.
The connector is honest about its edges too, which matters more than it sounds. MemberVault returns an HTTP 200 with a plain-text body when the site URL or key is wrong rather than an error status, so a naive script reads a misconfiguration as a success and keeps running. This connector detects that response and raises a clear failure instead, meaning a broken credential stops the flow rather than producing a run that looks fine and grants nothing. Configuration takes two values, the full site URL of your MemberVault instance and the Webhooks API key from the admin under Integrations, and the key travels as a query parameter.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Purchases and refunds keeping one ledger honest
Orders settle in Stripe and land as rows the flow reads on a schedule. For each purchase the agent calls Get Products to resolve the product name to an id, then Add User To Product with the buyer email, which creates the account if MemberVault has never seen that address. For each refund it calls Remove User From Product against the same id, so a buyer who bought three things and refunded one keeps the other two. Anything whose product name does not resolve, usually because the product was renamed on one side and not the other, becomes an automation exception with both names in the message rather than a best guess. The reconciliation nobody enjoys stops being a monthly cleanup and becomes a run that either succeeds or asks.
Leads present in the account before they are customers
A webinar registration or a form submission arrives. The agent calls Add User To Product with product id negative one, which puts the person in the MemberVault account with no access granted. The record exists, the email is normalized, and there is no duplicate waiting to be created later, because MemberVault matches on email and avoids creating a second user for the same address. When that person buys, the same action runs again with a real product id and access is added to the account they already have. The list of people who exist without entitlement, written into Airtable, is a clean pipeline view: everyone who is close enough to be in the system and has not bought yet.
A removal request that gets read before it gets executed
Someone asks to be removed. That request arrives in one shape and means two different things: cancel my subscription, or erase me. The agent does not decide which. It calls Get Products, works out what the account currently holds, and posts the picture into Slack with the request text alongside it. If the answer is cancellation, Remove User From Product handles it and the person keeps their account, their other products and their history. If the answer is erasure, a person runs Delete User knowing what it costs. The agent's contribution is that the decision is made with the facts visible, not from the wording of an email.
Human-in-Loop Highlight
The gate here is the difference between Remove User From Product and Delete User, and it is a real gate rather than a cautious one because the two requests that lead to them are indistinguishable at the point they arrive. Both start as an email address and a reason. Remove User From Product revokes one product, keeps the account, keeps every other product, and can be reversed by running Add User To Product again. Delete User removes the person and all of their associated data, which MemberVault names explicitly as progress, access and engagement. It is irreversible, and the platform's own guidance is that it is there for full removals such as an erasure request. Those are not two settings on the same idea. One is an accounting correction and the other is the end of a record.
So the agent takes the narrow lever and brings the wide one to a person, with the cost of the wide one already worked out. It calls Get Products, establishes what the account holds beyond the product in question, and asks in Slack: "Refund posted for Jamie Cole on Signature Program. They also hold two other products and eleven months of progress. Remove Signature Program only, or is this a full erasure request?" The person answers in one word and the flow continues. That is the digital andon cord working the way it should: the agent did not stall on ambiguity and it did not resolve the ambiguity by picking, it pulled the line and handed over a decision that was already framed.
The negative one product id is the quiet partner to that gate. When an order is ambiguous, meaning a product name that does not resolve or a payment that has not settled, the agent has somewhere safe to put the person: in the account, with no access, waiting. Nothing is granted that might have to be taken back, and nothing is lost while a person looks at it. A connector with four actions still gives an agent a way to pause without doing nothing, which is more than most larger surfaces manage.
Agent Capabilities
4 actionsProducts
1- Get Products Retrieves every product in the account as returned by the Webhooks API, including the product ids the user actions need. There is no server-side filtering or pagination here, so the flow reads the full list and matches against it. The step that turns a product name on an order into something grantable, and the step that catches a rename before it becomes a wrong grant.
Users
3- Add User To Product Grants a user access to a product by email, creating the account first when the address is new, and MemberVault matches on email so a repeat buyer does not become a second user. First and last name apply only when the user is newly created. Passing product id negative one adds the person to the account without granting any access, which is the right landing spot for a lead or an order that has not resolved.
- Remove User From Product Revokes one product's access from a user by email. The account survives, every other product survives, and the same grant can be reissued later, which makes this the correct action for a refund, a downgrade or a cancellation.
- Delete User Permanently removes a user and all of their associated data, including progress, access and engagement. This cannot be undone and is intended for full removals such as an erasure request. It is not a larger version of Remove User From Product, and a flow that treats it as one is deleting records to solve billing problems.
Frequently Asked Questions
What can FlowRunner do with MemberVault?
FlowRunner agents can run Get Products, Add User To Product, and Remove User From Product in MemberVault, plus 1 more action.
Does connecting MemberVault to FlowRunner require OAuth?
No. MemberVault connects to FlowRunner with an API key, no OAuth flow required.
Can MemberVault trigger a FlowRunner workflow automatically?
MemberVault doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with MemberVault
$100 in credits. No card required. Connect in minutes.