Mentortools
Education & LMSConnect AI agents to Mentortools, a German online course and membership platform. Agents grant and revoke member course access on each scheduled run so purchases unlock content and refunds close it without manual work.
What This Integration Enables
Mentortools is a German course and membership platform, and this connector has two actions. Not two groups of actions. Two. Grant Course Access and Revoke Course Access, sitting on endpoints that the platform itself names payment and refund. That is not a partial implementation waiting to be filled in, it is Mentortools stating what its API is for: access is a consequence of money, and the integration surface exists to carry money events into the school. Everything a larger platform would expose, meaning member lists, progress, groups and reporting, stays inside the product where the course creator works.
Two consequences follow from that, and both shape how an agent should be built here. The first is that this connector is write-only. There is no Get Member, no List Members, no lookup of any kind. An agent cannot ask whether an account already exists, cannot confirm that a grant landed, and cannot verify that a revocation took effect. It can only assert. The second consequence follows from the first: because there is no read to reconcile against, the flow's own execution record becomes the audit trail. That is a real argument for putting these calls in a flow rather than in a script, because a script that grants access leaves nothing behind, while a flow leaves a run history with the buyer, the courses and the result of every call.
What the two actions do carry is more than their names suggest. Grant Course Access takes a buyer email, a first name and one or more course ids, and a single call grants every listed course to the same buyer. If no account exists for that email, Mentortools registers the member and sends them its standard welcome and login email. If the account does exist, the courses are simply added. Revoke Course Access is the mirror image and the refund counterpart: the account is kept, and access to each listed course is disabled so the content is no longer viewable. Course ids come from the Mentortools course settings, which means the mapping from your product catalog to those ids is a piece of configuration your flow owns, and getting it wrong grants the wrong content to a real buyer.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A German checkout wired straight into the school
Mentortools sits in an ecosystem where the checkout is usually Digistore24, and the API's payment and refund shape reflects that lineage. The agent reads settled orders on a schedule, maps each product to its Mentortools course ids, and calls Grant Course Access with the buyer email and first name. Refunds and chargebacks read from the same source call Revoke Course Access against the same email with the same ids, so the reversal is symmetric with the grant rather than a separate reconstruction. Products with no course mapping never reach either call; they are held as automation exceptions with the product name attached, because an unmapped product plus a guess is how a buyer ends up inside a course they did not purchase.
Bundles and upsells granted in one call
A bundle sells three courses together, and an order bump adds a fourth. Because Grant Course Access accepts a list of course ids and grants every one of them to the same buyer in a single request, the agent does not loop and does not risk a partial grant where two courses land and the third fails silently. The mapping from product to id list lives in one place the flow reads, so adding a course to a bundle is a configuration change rather than a code change. The run history records exactly which ids went to which buyer, which is the record that answers the support question three weeks later about why somebody can see one module and not another.
Refunds that close access at the moment finance sees them
A refund posts. Rather than waiting for someone to work a list, the agent reads the reversal, resolves the course ids from the original order, and calls Revoke Course Access. The member's account survives, so their history and any other purchases are untouched, and only the refunded courses go dark. The run posts a line into Slack naming the buyer and the courses closed, and writes the same record into Google Sheets beside the refund so the finance reconciliation has both halves in one row. The gap between the money moving back and the access closing stops being a matter of who was available.
Human-in-Loop Highlight
The gate on this connector exists because of an action that is missing rather than an action that is dangerous. Grant Course Access, called with an email Mentortools has never seen, does not just create a record. It registers a member and sends that address the platform's standard welcome and login email. That email reaches a real inbox, and nothing on this connector can take it back or check first, because there is no lookup action to ask whether the address is already a member and no read to confirm what the call did. The agent is asserting into a system it cannot observe, and the first thing the system does with a wrong assertion is contact a stranger with a login.
That changes what the pause is for. The judgment is not about whether the buyer should get the course, because the payment already settled that. It is about whether this address is the buyer's address. Payment payloads carry typo domains, addresses keyed by hand into a phone order, support inboxes that forwarded a receipt, and shared team addresses that resolve to whoever opens them first. So the agent verifies every email against the order record in the checkout system, which is the only place a verification is possible, and any address that does not match exactly stops before the write. It asks in Slack: "Order 20418 for the Positioning Intensive lists buyer email j.wagner@gmial.com. No matching contact in Digistore24. Grant access to this address, which will send it a Mentortools login, or correct it first?" That is human-in-the-loop at the only point where a human still has leverage, because after the send there is nothing left to decide.
The revocation side carries a smaller version of the same constraint and deserves saying plainly. Revoke Course Access returns no state you can read back, so the flow cannot confirm that a member lost access, only that the call was accepted. The honest response to that is not to pretend otherwise but to keep the record where it can be checked: log every revocation with the buyer email and the course ids in the run history, and reconcile against the refund list rather than against the platform. A connector that cannot be queried is still perfectly safe to automate. It just means the automation has to be the thing that remembers.
Agent Capabilities
2 actionsCourse Access
2- Grant Course Access Grants a member access to one or more Mentortools courses in a single call, matched on buyer email. If no account exists for that email, Mentortools registers a new member with the supplied name and sends them its standard welcome and login email; if the member already exists, the courses are added to the account they have. Course ids come from the Mentortools course settings, and every id in the list goes to the same buyer.
- Revoke Course Access Revokes a member's access to one or more courses, the counterpart of a refund. The member's account is kept and their other purchases are untouched, but each listed course is disabled so its content can no longer be viewed. Matched on the same buyer email and course ids that granted the access, which is what makes a reversal symmetric with the original order rather than a reconstruction of it.
Frequently Asked Questions
What can FlowRunner do with Mentortools?
FlowRunner agents can run Grant Course Access and Revoke Course Access in Mentortools.
Does connecting Mentortools to FlowRunner require OAuth?
No. Mentortools connects to FlowRunner with an API key, no OAuth flow required.
Can Mentortools trigger a FlowRunner workflow automatically?
Mentortools doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Mentortools
$100 in credits. No card required. Connect in minutes.