Memberspot
Education & LMSConnect AI agents to Memberspot, a German online course and membership platform. Agents manage users, grant or revoke offer and chapter access, set order states, and read course progress and exam results so access provisioning stays aligned with payments.
What This Integration Enables
Memberspot is a German course and membership platform, and among the platforms in this category it is the one whose API is built around the order rather than around the member. Most course platforms give you a member and let you attach things to them. Memberspot gives you three separate levers keyed on your own order id: set the state of that order for one user by email, for one user by their Memberspot uid, or for every user attached to that order across the entire school. That design tells you what the platform expects to be wired to, which is a checkout such as Digistore24 or CopeCart pushing order lifecycle events, and it is why the connector reads more like a fulfillment surface than a course admin.
That order-first design is what makes the money-and-access question tractable here. When you grant an offer you can attach your own order id, and from then on the access carries the provenance of the transaction that created it. A refund does not require the flow to remember which offers were granted or to reconstruct entitlement from a member profile: the order id is enough. Set Order State By Email fulfills or revokes the offer tied to one order for one person, and the operation is symmetric, so the same identifier both opens and closes the door. For a finance team reconciling what was sold against what is currently accessible, that symmetry is the whole point.
The rest of the surface fills in around it. Offers are granted by email or by uid, activated and deactivated without deletion, and given expiration dates as ISO timestamps so limited-term access ends by itself. Grant Chapter Access By Email and Grant Chapter Access By UID unlock a single chapter inside a course, which is how drip release and partial unlocks are done without duplicating the course. Custom user properties, defined per school, are set one at a time or in batches, so external attributes such as a company name or a license reference travel with the member. Create Login Token issues a single-use, one-hour sign-in URL for seamless entry from your own funnel. On the read side, List Users pages through the school with filters for offer, course and active state, List Course Progress and Get Course Progress report active and completed post counts, and List Exam Results returns who took an exam and how they did. Paging is keyset based and capped at twenty per page, so sweeps are iterative by design.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Order lifecycle driving access end to end
A payment settles in Digistore24 or Stripe. The agent maps the product to an offer id from List Offers, calls Find User By Email to see whether the buyer exists, and calls Grant Offer By Email with the order id attached, which creates the account when there is none. If the offer is time-limited, Set Offer Expiration writes the end date immediately so nobody has to remember it later. When the same order later moves to refunded, the agent calls Set Order State By Email against that order id and the access closes without any lookup of what was originally granted. Orders whose product maps to no offer are held as automation exceptions, because a guessed offer unlocks content that was never paid for.
Drip release that follows the cohort, not the calendar
A program releases chapters weekly, but the cohort does not start on the same day. The agent runs a schedule over List Users filtered to the offer, reads each learner's position with List Course Progress, and calls Grant Chapter Access By UID to unlock the next chapter for the people who have finished the previous one. Learners who have not moved in two weeks are not unlocked further; instead they are collected into a coaching list that goes to the program owner in Slack. Release follows readiness rather than a global drip schedule, and nobody is silently handed content they are not ready for.
Reconciling access against revenue
At month end the agent pages through List Users for each offer, pulls Get Course Progress for the active members, and writes the roster into Google Sheets beside the settled orders from the payment system. Three lists come out of the comparison: people with access and no matching settled order, people with a settled order and no access, and people whose access expired while their subscription is still billing. The first two are ordinary reconciliation, and the third is the one finance actually wants to see. None of the three is corrected automatically, because each one is a different mistake with a different owner.
Human-in-Loop Highlight
The gate on this connector is Set Order State (All Users), and it is a gate because of blast radius rather than reversibility. The action activates or deactivates every offer associated with a given order id across every user in the school in a single call. That is genuinely useful for the case it was built for, meaning one corporate order that granted seats to a team, and it is dangerous for the reason all bulk levers are dangerous: the payload does not tell you how many people it is about to affect. An agent processing a batch of payment failures cannot see the difference between an order that covers one person and an order that covers a department, because the request looks identical in both cases.
So the design rule is that an agent may deactivate a single named user's order on its own, because Set Order State By Email and Set Order State By UID affect exactly one account and reactivating restores what was there. The school-wide lever is not its to pull. Before it asks, it does the work that makes the question answerable: it calls List Users filtered by the offer to count who is currently holding access under that order, and it names them. Then it asks in Slack: "Order DS-44190 moved to chargeback. Deactivating it school-wide would remove access for nine users on the Leadership Track offer, listed below. Deactivate all nine, or only the account that paid?" A person answers in seconds because the count is in the question. That is human-in-the-loop as Orchestration as a Service means it, meaning the agent does the gathering and a person owns the consequence.
Two deletion actions sit outside that logic and need their own handling. Delete Users By Email and Delete Users By UID both take a list, both remove the users and their access from the school, and neither can be undone. A list parameter on a permanent operation is exactly the shape that turns one bad upstream filter into a school-wide incident, so these belong in a controlled flow with a named owner and an explicit count in the approval, never in a general access-sync path. Set Offer State is the right instrument when the intent is to close access, because deactivation removes the content while keeping the account, and reactivating puts it back.
Agent Capabilities
25 actionsSchool
1- Get School Returns the school the configured API key belongs to. The connection check that confirms which academy a key actually points at before any write runs against it.
Users
6- List Users Pages through the users in the school with optional filters for offer, course and active state, using keyset pagination capped at twenty per page. The read behind every roster, reconciliation and cohort sweep.
- Find User By Email Looks up one user by email and returns their profile with granted offers, active state and custom properties. Returns null rather than an error when nobody matches, so a flow can branch on existence cleanly.
- Find User By UID Looks up one user by their Memberspot user id and returns the same full profile. Used once a uid is already in hand from an earlier step.
- Create Login Token Issues a single-use login token and URL that signs the given user straight into the school, expiring after one hour. The action behind seamless entry from your own funnel or site.
- Delete Users By Email Permanently deletes one or more users identified by email, removing them and their access from the school. This cannot be undone, and it takes a list, so it belongs behind a person with an explicit count.
- Delete Users By UID Permanently deletes one or more users identified by uid. Same permanence and same list-shaped risk as the email variant.
Offers
6- Grant Offer By Email Grants access to an offer by email, creating the user with the supplied name when no account exists. Attaching your own order id here is what makes the access traceable to the transaction that paid for it.
- Grant Offer By UID Grants an existing user access to an offer by uid, with the same optional order id. Used when the flow already resolved the user in a previous step.
- Set Offer State By Email Activates or deactivates one offer for one user identified by email. Deactivation removes the content while keeping the account, and reactivating restores it, which makes this the right lever for a payment problem.
- Set Offer State By UID Activates or deactivates one offer for one user identified by uid. The same reversible lever, addressed by id.
- Set Offer Expiration Sets or updates when a user's access to an offer ends, as an ISO 8601 timestamp. Hands the deadline to the platform instead of to a reminder somebody has to honor.
- List Offers Returns every offer in the school with its id, name and the courses it unlocks. The catalog read that maps a product on an order to something grantable.
Orders
3- Set Order State By Email Activates or deactivates the offer tied to one order for one user identified by email. The symmetric counterpart to fulfillment, keyed on the same order id that granted the access.
- Set Order State By UID Activates or deactivates the offer tied to one order for one user identified by uid.
- Set Order State (All Users) Activates or deactivates every offer under one order id across all users in the school in a single call. Built for orders that granted access to several people, and the one action on this connector whose blast radius is not visible in its own payload.
Chapters
2- Grant Chapter Access By Email Unlocks a single chapter inside a course for a user identified by email. The action behind drip release and partial unlocks that follow a learner's actual position.
- Grant Chapter Access By UID Unlocks a single chapter for a user identified by uid, for the same purpose.
Custom Properties
4- List Custom User Properties Returns the custom property definitions configured for the school, each with its id, name and type. The lookup that turns a property name into the id the set operations require.
- Set Custom Property By Email Sets one custom property for a user identified by email, clearing it when the value is empty. Used to carry an external attribute such as a company or licence reference onto the member record.
- Set Custom Property By UID Sets one custom property for a user identified by uid, with the same clearing behavior.
- Set Custom Properties By Email Sets several custom properties at once for a user identified by email, each entry a property id and a value. The batched form for a sync that writes multiple attributes per run.
Course Progress
2- List Course Progress Pages through a user's progress across every course they can access, identified by email, reporting active and completed post counts per course. Keyset paginated and capped at twenty per page.
- Get Course Progress Returns a user's progress for one specific course, including whether their access is still active. The targeted read behind drip decisions and completion checks.
Exams
1- List Exam Results Pages through the results of users who have taken a given exam. The read behind certification reporting and follow-up for people who did not pass.
Frequently Asked Questions
What can FlowRunner do with Memberspot?
FlowRunner agents can run Get School, List Users, and Find User By Email in Memberspot, plus 22 more actions.
Does connecting Memberspot to FlowRunner require OAuth?
No. Memberspot connects to FlowRunner with an API key, no OAuth flow required.
Can Memberspot trigger a FlowRunner workflow automatically?
Memberspot doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Memberspot
$100 in credits. No card required. Connect in minutes.