Automate Skool Join Request Approvals: Complete Guide

If you run a Skool community, the join request queue is the least glamorous part of your week. Someone taps Request to Join. You get a notification, or an email, or nothing at all until you happen to open the Members tab. Then you read their profile, guess whether they are a real person or a spam account, and tap approve. This guide shows you how to automate Skool join request approvals with Creator OS, so the queue moves itself while you keep the final say on anything risky.


  Join request arrives
          |
          v
  +-----------------------+
  |  Your screening rules |
  |  (CLI or AI agent)    |
  +-----------------------+
      |            |
   match        no match
      |            |
      v            v
  approve      hold for you
      |            |
      v            v
  welcome DM   human review
  (optional)   in dashboard

Approve the obvious yes, hold the edge cases for you.

Why Manual Skool Join Request Approvals Don’t Scale

Manual approval has three costs, and only the first one is obvious.

The first is latency. A new member who waits six hours for approval has already lost the momentum that made them click. Communities that grow fast tend to approve fast, because the join request is the top of the funnel and everything else (posts, comments, retention, MRR) sits downstream of it.

The second is inconsistency. On Monday you are strict. On Friday night you approve three accounts you would have rejected on Monday. Your bar moves with your mood, and nobody can audit it later.

The third is that approval is the one place where a bad decision is expensive. Approving a spam account means a DM blast to your members. Rejecting a real customer means lost revenue you never hear about.

What you want is not “let everyone in.” What you want is a rule set you can read, plus an automation that applies it the same way at 3am as it does at noon. Creator OS gives you that through the API, the CLI and its MCP server. You can read the full Skool surface at creatoros.ca/docs/skool.

What You Need Before Automating Approvals (Skool Access and API Setup)

Two things: a Skool connection with the right access, and a way to call Creator OS.

Skool access. You connect Skool by signing in on Skool’s own page and sharing communities read or read and write. Read and write is what you need, because approving and denying members are write actions. Do that once in the Creator OS web app.

A calling method. Pick one of three:

The CLI. Install @creatoros/cli, authenticate, and run commands from a terminal or a cron job. Command reference lives at creatoros.ca/docs/cli.
The MCP server. A hosted server at https://mcp.creatoros.ca/mcp. Nothing to install. You paste the URL into Claude, ChatGPT, Claude Code, Cursor, Codex, Windsurf or VS Code. Setup details are at creatoros.ca/docs/mcp. If you want a longer walkthrough of what an agent can and cannot do inside a community, read the Skool MCP server guide.
The REST API. Authenticated with a Creator OS API key (cos_live_...) and pinned to one workspace. Base URL and request shapes are in the docs at creatoros.ca/docs.

One design note worth internalizing early: an API key is pinned to one workspace, which is one set of socials and one Skool connection. An agent holding that key cannot reach a different workspace. If you run several communities for different clients, that is the boundary that keeps them apart. Agencies that want one agent per client can read the one-agent-per-client setup.

How the Creator OS API Handles Join Request Approvals

On the Skool side, Creator OS exposes join requests as a list you can read and two actions you can take: approve and deny. The MCP tools are the cleanest way to see the shape. An AI agent gets access to Skool tools that include creating posts, reading members by status, and reading revenue and growth. The member side is what matters here: you can read members filtered by status, including pending, and you can approve or deny a specific member by id.

From the CLI, the relevant commands are:

creatoros skool:pending <community>
creatoros skool:approve <community> <memberId>
creatoros skool:deny <community> <memberId>
creatoros skool:members <community> --tab pending --page 1
creatoros skool:growth <community>
creatoros skool:revenue <community>

Notice what is not there. There is no “approve everyone who joined in the last hour” command, and no built in scoring engine. That is deliberate. The rule set is yours, and the automation is whatever you build around these primitives. Creator OS does not ship its own model, so the judgment layer can be Claude running through the MCP server, or a plain script with a keyword list.

Approval decisions also feed the same analytics layer as everything else, which means the same connection that approves members can also answer “how did this cohort retain” later. Growth and revenue commands read MRR, 30 day growth, engagement, and member status counts, so you can close the loop on whether your screening rules let in good members or just quiet ones.

Step-by-Step: Build Your First Auto Approval Workflow

Start small and dry. Here is a workflow you can run today.

Authenticate and confirm the connection. Run creatoros auth:check, then creatoros skool:account and creatoros skool:profile to confirm which Skool identity you are acting as.
Pull the pending queue. Run creatoros skool:pending <community>. This is your working set. Everything below operates on this list.
Read the members. Run creatoros skool:members <community> --tab pending. You get the fields you need to screen on: name, status, and whatever approval metadata Skool exposes.
Apply your rules. For each pending member, decide approve, deny, or hold. Rules are covered in the next section. If you are doing this with an AI agent over MCP, this is the step where you hand it your written policy and ask it to classify each member.
Approve the clear yeses. Run creatoros skool:approve <community> <memberId> for each one. Clear yes means every rule passed with room to spare.
Hold the rest. Do nothing with them. Leaving a request pending keeps it in your human review queue, which is exactly where you want an ambiguous case. Do not deny just because your script could not decide.
Log the decision. Write the member id, the rule that fired, and the outcome to a file or a sheet. You will want this when you tune the rules.
Schedule it. Once the dry run looks right, run the same sequence on a timer. If you prefer an agent to own the whole loop, the open source Social Agents harness at github.com/kevinbadi/social-agents interviews you about your brand and then runs your socials on Creator OS, with a local dashboard you can watch. Start it with npm start creatoros social-agents.

That is the whole loop. The interesting part is step four, and that is where most people get it wrong.

Writing Screening Rules: Keywords, Questions, and Risk Signals

Good approval rules are boring on purpose. Write them as a list of conditions that must all pass, plus a separate list of signals that force a hold.

Signals that lean approve. A filled out profile with a real name and a photo. A coherent answer to your join question that references the topic. An email on a normal domain. A public social profile that matches the name. If you have a paid community, a completed checkout.

Signals that force a hold, not a deny. Empty or one word answers. Names that are obvious keyword stuffing. Links in the join answer. An email domain that has nothing to do with the person. Multiple requests from the same person. Anything where you catch yourself guessing.

Keywords get their own category. Skool communities often ask a join question like “what do you want to get out of this community.” That answer is your richest screening data and also your most dangerous one, because keyword matching is brittle. Two rules that survive contact with real traffic:

Match on intent phrases, not single words. A person writing “I want to stop guessing what to post” is a yes. A person who happens to type “post” is not necessarily a yes.
Never let a keyword match alone trigger a deny. Keyword deny rules produce false negatives on real customers and you will never see the revenue you lost.

If you already run keyword automations, the exact same matchMode thinking applies. Creator OS automations support exact, contains and word matching, and you can create one with creatoros automations:create using --keywords and --matchMode. The comment-to-DM and reply side of that is covered in the replies API guide.

Write the policy down in plain language first. One page. “We approve people who can describe a specific problem in their own words and appear to be one human. We hold anyone we cannot verify. We deny only obvious automation accounts that fail three separate checks.” That page is what you paste into an agent, and it is also the document you edit when something goes wrong.

Routing Edge Cases to Human Review Instead of Auto Rejecting

The single biggest mistake in automated approvals is treating deny as the default for uncertain cases. It is not. Deny should be rare and narrow, because a denied join request is silent. The person does not email you to argue. They just leave.

Use three buckets, not two.

Bucket	When	Action
Approve	Every rule passes, no hold signal present	`creatoros skool:approve`
Hold	Any hold signal, or any rule you could not evaluate	Leave pending, review yourself
Deny	Only when the account is clearly automated and fails multiple independent checks	`creatoros skool:deny`

Two practical notes on holds. First, holds should be visible. Put a number on them. If your hold bucket is sixty percent of requests, your rules are too strict and you have not automated anything, you have just renamed the queue. Second, holds should expire into a decision. Set a rule for yourself: anything pending for more than a day gets read by a human. In practice, the pending tab in creatoros skool:members <community> --tab pending is the fastest way to review them in one pass.

If you are nervous about giving an agent write access at all, the MCP server supports read only connections, and the API refuses writes from them. That is a good way to run this for a week: let the agent classify, you click. You will learn more about your own rules in that week than in a month of theorizing. The same staged approach for publishing is described in what to automate and what to keep manual.

Combining Approvals With Welcome Messages and Onboarding

Approval is a moment, not a task. The value comes from what fires immediately after.

After you approve someone, a welcome DM is the highest leverage message you will ever send them, because you have their full attention and nothing else has happened yet. Creator OS supports Skool DMs. From the CLI, the shape is straightforward:

creatoros skool:chats --unread --limit 30
creatoros skool:messages <chatId> --before 30
creatoros skool:send <chatId> --text "Welcome in. Start here..."
creatoros skool:start-chat <userId> --community <slug>

You can also welcome the whole community with a new member post. Skool posting in Creator OS handles posts and polls with media, and creatoros skool:multi-post lets you publish the same post to several communities at once with --communities slug,slug, which matters if you run a main community plus a paid tier. The MCP tools skool_create_post and skool_multi_post do the same job from an agent.

Two rules for welcome messages. Keep them short, and make the first line do work. “Welcome, here is the one post to read first” beats a paragraph about community values. If you need a longer look at what community owners typically build, this piece on community owner workflows goes into onboarding and engagement in more depth.

Onboarding also has a maintenance half. Approval is where you let people in. creatoros skool:members <community> --tab churned and the growth and engagement commands are where you find out whether they stayed. If you also care about the email side, creatoros skool:emails <community> --tab active reads collected emails by status.

If you would rather watch the whole thing being built than read about it, there are walkthroughs of Creator OS, Social Agents and the open source tools on the KevBuildsApps YouTube channel. The launch video for the open source side is here: youtube.com/watch?v=-QBJH_PK3pY.

Common Mistakes When Automating Skool Approvals

Automating deny before automating approve. Approve is low risk and high volume. Deny is high risk and low volume. Automate the first one first.
No dry run. Pull the pending queue, classify it, and write down what you would have done without executing anything. Compare that to what you actually did manually last month. The disagreements are your rule bugs.
Rules nobody can read. If you cannot explain why a member was approved in one sentence, you cannot debug it later.
Treating silence as success. A denied member never complains. Track your approve rate and your hold rate, and check them against revenue occasionally with creatoros skool:revenue <community>.
Letting approval live in a different place than everything else. If your rules run in one tool and your posting runs in another, you will end up reconciling two systems. Creator OS puts publishing, replies, analytics and Skool in one place, reachable from the web app, the CLI, the API and the MCP server.
Forgetting the human layer entirely. An approval that no one ever looks at is a policy no one ever fixes. Keep the pending tab in your weekly routine.

One more, specific to agents: destructive actions are marked as destructive in the MCP server, so an AI app asks before deleting a post, deleting a comment, disconnecting an account or deleting an ad. Read that list and make sure your agent is not skipping confirmations because you told it to be fast.

Get Started With Creator OS

You do not need a big stack to do this. One Skool connection plus one calling method gets you a working approval loop, and the API keys, the MCP server, the CLI and the agent skills are included in every plan, including the Creator plan at $19.99/month or $59.99/year with up to 8 connected accounts (7 socials plus Skool).

Start with the dry run: pull your pending list with creatoros skool:pending <community>, write your three bucket policy on one page, and see how much of the queue a simple rule set actually clears. If you would rather have an agent do the classifying while you watch, install the Claude Code skills with npx @creatoros/cli@latest init and read the Skool docs at creatoros.ca/docs/skool.