Skool Group Scraper & Creator's Other Communities

Skool Group Scraper — Members, Pricing and Creator Portfolio

Skool Group Scraper & Creator's Other Communities walks Skool discovery pages, returns every community it finds as structured JSON — displayName, totalMembers, monthlyPrice, privacy, numCourses, plus the full owner record — and then opens each owner's public Skool profile to map the other communities that same creator runs into an ownerCommunities[] block on the same row. 66 keys per community, no login, no cookie. Paste a discovery URL and press Start.

What is Skool Group Scraper & Creator's Other Communities?

It is an Apify Actor that reads Skool's server-rendered __NEXT_DATA__ payload from three public page types — the discovery listing, each community's /about page, and each owner's profile at skool.com/@handle — and merges all three into one row per community. The creator-footprint step is what separates it from a plain group scraper: one discovered community becomes a view of that creator's whole Skool portfolio.

No Skool account, login, cookie or session token is required or accepted. There is no credential field anywhere in the input schema, and the browser context is created without stored state, so every request is exactly what a logged-out visitor receives. The only credential involved is your Apify token, and only if you call the Actor through the API rather than the Console.

It is built for market researchers sizing the paid-community space, lead-generation and partnership teams looking for creators who run more than one community, and developers and AI engineers feeding a community graph into a dashboard or retrieval index.

What Skool community data is publicly available to scrape?

Skool renders a community's identity, price, member count and owner profile to anonymous visitors on its discovery listing and its /about landing page, and renders a creator's community list on their public profile. What is gated is what happens inside a community, not the community's own metadata.

Data Category	Public, logged out	Requires Skool login and membership
Community name, slug, ID and branding (color, initials, logoUrl)	✅ Public on discovery	—
Description and full landing-page copy with attachments	✅ Public on /about	—
Member, admin, post and rule counts	✅ Public on /about	—
Monthly and annual price, membership model, privacy code	✅ Public on /about	—
Course and module counts, tab visibility flags	✅ Public on /about	—
Owner name, handle, bio, location, avatar and social links	✅ Public on /about	—
Support email, when Skool publishes it in the owner payload or the landing copy	✅ Public on /about	—
The other communities on a creator's public profile	✅ Public on skool.com/@handle, partial by design	—
Individual member profiles and the member roster	❌	Membership + login
Posts, comments, classroom lessons, calendar and chat	❌	Membership, frequently paid

Skool Group Scraper & Creator's Other Communities only returns publicly visible data — what any logged-out visitor sees. Nothing behind a login wall.

⚠️ Your input is a discovery URL, not a group URL

This matters more than any other setting, because the Actor will not tell you that you got it wrong.

urls expects Skool discovery links — https://www.skool.com/discovery, or a filtered variant such as https://www.skool.com/discovery?q=marketing. The Actor reads the community list out of props.pageProps.groups in that page's payload, which is a key that only discovery pages carry. Point it at a single community's page instead and that key is absent, so the discovery step starts from an empty list and falls straight through to pagination.

Pagination does not carry your query string. Page one comes from the URL you supplied. Every page after it is requested from https://www.skool.com/_next/data/{buildId}/discovery.json?p=N — Skool's global discovery feed, with no q parameter forwarded. The URL you gave is sent only as the Referer. Two consequences worth planning around:

• A keyword-filtered discovery URL is filtered for the first page only. If maxItems is larger than one page of results, the remainder arrives from the unfiltered global listing. Keep maxItems at or below one page if you need strictly on-keyword results, and filter the rest yourself afterwards.
• A non-discovery Skool URL does not error. It contributes nothing of its own and then pulls generic discovery communities from page two onward.

The fix is the same in both cases: check that the displayName values coming back match what you asked for, and treat maxItems as a crawl depth into Skool's discovery feed rather than a filtered result count.

What data can I extract with Skool Group Scraper & Creator's Other Communities?

Every dataset row is one Skool community, carrying 66 top-level keys across four groups: what the community is, what it costs and who can join, how big and how content-rich it is, and who runs it — followed by that creator's other communities. Two nested arrays expand the row to 81 distinct field paths in total.

Field Name	Description
id	Skool's community ID. Stable join key, and the key the Actor deduplicates on within a run
name	URL slug, e.g. skoolers. Also the value used to build the /about request
displayName	Community display name as shown on Skool
description	Short community description from the discovery payload
landingPageDescription	Full landing-page copy from /about. The longest text field on the row
supportEmail	Owner email from the /about payload. Falls back to the first mailto: link or bare email address found in landingPageDescription. null when neither exists
monthlyPrice	Monthly price in major units. Skool publishes amounts in minor units; the Actor divides by 100 except for zero-decimal currencies (JPY, KRW, VND and others). null for free communities and for annual-only pricing
monthlyCurrency	Lower-case currency code for monthlyPrice, e.g. "usd"
annualPrice	Annual price, normalized the same way. null unless Skool's recurring interval is year
annualCurrency	Lower-case currency code for annualPrice
color	Community theme colour hex from Skool's metadata
initials	Community initials used in Skool's avatar fallback
privacy	Skool's raw privacy code as an integer. Returned unmapped — the Actor does not translate it to a label
membership	Skool's membership code. Set from membershipModel on the discovery payload, then overwritten with membership from /about when enrichment succeeds — two different Skool keys land in this one field
plan	Skool's plan code from /about. null when enrichment did not complete
landingPageAccessType	Skool's lpAccessType code, controlling who can view the landing page
affiliatePercent	Constant 0. Present for shape compatibility; never populated from Skool
pluginAutoDmEnabled	Constant 0. Never populated
pluginMinChatLevelEnabled	Constant 0. Never populated
surveyEnabled	Constant 0. Never populated
surveyQuestions	Constant []. Never populated
surveyUpdatedAt	Constant null. Never populated
logoUrl	Community logo URL from the discovery payload
logoBigUrl	Large logo URL from /about
coverSmallUrl	Small cover image URL from the discovery payload
faviconUrl	Community favicon URL from /about
customLinks	Constant []. Never populated
totalMembers	Skool's published member count. Set from discovery, refreshed from /about
totalOnlineMembers	Members Skool reports online at fetch time. A point-in-time reading, not an average
totalAdmins	Number of admins Skool publishes for the community
totalPosts	Lifetime post count as Skool publishes it
totalRules	Number of community rules published
numCourses	Number of classroom courses Skool publishes
numModules	Number of classroom modules across those courses
audioChatVisible	Boolean from Skool's tabs payload — is the audio-chat tab shown
calendarVisible	Boolean — is the calendar tab shown
classroomVisible	Boolean — is the classroom tab shown
mapVisible	Boolean — is the member map tab shown
landingPageAttachments	Array of landing-page media blocks parsed from Skool's lpAttachmentsData. [] when none
landingPageAttachments[].id	Attachment ID
landingPageAttachments[].type	Skool's landing_page_attachment_type value
landingPageAttachments[].imageFileId	Image file ID, when the attachment is an image
landingPageAttachments[].imageOriginalUrl	Full-size image URL
landingPageAttachments[].imageSmallUrl	Small image URL
landingPageAttachments[].imageBigUrl	Large image URL
landingPageAttachments[].videoId	Video ID, when the attachment is a video
landingPageAttachments[].videoUrl	Video URL
landingPageAttachments[].videoThumbnailUrl	Video thumbnail URL
ownerId	Skool user ID of the community owner. The key used to test ownership in the footprint block
ownerName	Owner's Skool handle. Also the value used to build the skool.com/@handle profile request
ownerFirstName	Owner's given name
ownerLastName	Owner's family name
ownerBio	Owner's self-written profile bio. Empty strings are normalized to null
ownerLocation	Owner's self-declared location
ownerDiscTop	Owner's self-declared top DISC personality type, when set on their Skool profile
ownerActivityStatus	Skool's activity-status value for the owner
ownerMyersBriggs	Owner's self-declared Myers-Briggs type, when set on their Skool profile
ownerOnline	Boolean — was the owner online at fetch time
ownerLastOffline	Owner's last-offline value, stringified. null when absent
ownerPictureProfile	Owner's profile picture URL
ownerPictureBubble	Owner's small avatar URL
ownerInstagram	Instagram link from the owner's Skool profile
ownerYoutube	YouTube link from the owner's Skool profile
ownerFacebook	Facebook link
ownerTwitter	Twitter / X link
ownerLinkedin	LinkedIn link
ownerWebsite	Personal or business website link
ownerCreatedAt	When the owner's Skool account was created
ownerUpdatedAt	When the owner's Skool profile was last updated
createdAt	Community creation timestamp
updatedAt	Community last-updated timestamp
createdBy	Skool user ID of the account that created the community. Usually equal to ownerId, and not guaranteed to be
ownerCommunities	Array of the other communities found on the owner's public profile. [] when the footprint step is off, when no owner handle was resolved, or when the profile could not be read
ownerCommunities[].id	Community ID of the portfolio entry
ownerCommunities[].name	Slug of the portfolio entry
ownerCommunities[].displayName	Display name of the portfolio entry
ownerCommunities[].totalMembers	Member count of the portfolio entry, cast to an integer. null when includeOwnerCommunityStats is off
ownerCommunities[].displayPrice	Formatted price string built from Skool's displayPrice blob, e.g. "97 USD/month". null for free or zero-priced entries — never a faked 0 — and null when includeOwnerCommunityStats is off
ownerCommunities[].isOwned	Best-effort ownership flag: true when the entry's createdBy equals this row's ownerId. Always true when ownedOnly is on, since non-owned entries are filtered out before the row is written
ownerCommunitiesCount	Length of ownerCommunities. null — never 0 — when the owner profile could not be read at all
ownerCommunitiesPartial	Honesty flag, not a truncation flag. See the note below

Community identity, pricing and access fields

id and name are the two keys everything else hangs off: id is what the run deduplicates on, and name is the slug the Actor turns into the /about request, so a community with no slug is written with discovery-only fields and nothing else.

Pricing is Skool-published, not derived. monthlyPrice, monthlyCurrency, annualPrice and annualCurrency come from Skool's own displayPrice blob, or from currentMBp and currentABp when displayPrice is absent. The only transformation applied is a minor-to-major unit conversion — a 9700 in the payload becomes 97 — skipped for the zero-decimal currencies where Skool already publishes major units. Which of the two price pairs is populated depends entirely on Skool's recurring_interval: a monthly community leaves annualPrice at null, and vice versa. Neither is estimated and neither is inferred from anything else on the page.

privacy, membership, plan and landingPageAccessType are raw Skool integer codes passed through untranslated. Compare them across rows rather than reading them as labels.

Seven keys on every row are constants the Actor writes but never fills from Skool: affiliatePercent, pluginAutoDmEnabled, pluginMinChatLevelEnabled and surveyEnabled are always 0, surveyQuestions and customLinks are always [], and surveyUpdatedAt is always null. They exist so the row shape matches the base Skool record. Do not read meaning into them.

Size, content and layout metrics

totalMembers is the field most runs sort on, and it is Skool's own published count — read first from the discovery payload and then refreshed from /about, so a row whose enrichment failed still carries the discovery value. totalOnlineMembers is a snapshot at fetch time and moves between runs by design.

numCourses, numModules, totalPosts and totalRules describe how much a community actually contains, and the four *Visible booleans describe which features its owner has switched on. Together they separate an active paid community from a landing page with a price on it, which member count alone cannot do.

Creator identity and the ownerCommunities footprint

Twenty-one owner* fields describe a specific, named person: their handle, name, bio, location, avatars, social links, account timestamps, online state, and — where they have filled them in on Skool — their self-declared DISC and Myers-Briggs types. These are the rows' most sensitive fields; read the legal section before storing them.

The footprint block is the Actor's reason to exist. When includeOwnerCommunities is on, the owner's public profile at skool.com/@{ownerName} is loaded and Skool's groupsMemberOf[] array is mapped into ownerCommunities.

Three things about it are deliberately honest rather than flattering:

• ownerCommunitiesPartial is true whenever a profile was read. It is not a "was this truncated" signal that sometimes goes false. Skool's public profile list can omit a creator's flagship community and does not label ownership, so the flag is a permanent caveat: treat ownerCommunities as a strong sample of a creator's footprint, not a certified-complete portfolio.
• isOwned is a best-effort match, set when a listed community's createdBy equals this row's ownerId. Skool does not publish an ownership label. With ownedOnly on, a creator whose ID never matches yields ownerCommunitiesCount: 0 rather than a wrong answer.
• ownerCommunitiesCount is null, not 0, when the profile could not be read. Combined with the flag, that gives you a clean three-state read: partial: false and count: null means no owner handle was ever resolved, or the footprint step was off; partial: true and count: null means the profile was attempted and failed; partial: true with a number means it worked.

🤖 Add-on: Need additional community-graph data?

The same expand-from-a-seed job exists on other platforms in the Scraper-Engine catalogue. Facebook Group Discovery Scraper takes a Facebook group and returns the related and suggested groups Facebook itself links from it, with admin and moderator profiles. Facebook Groups Search Scraper is the keyword-first counterpart for when you have no seed at all. For creator-side rather than community-side expansion, Instagram Related Profiles Scraper walks Instagram's suggested-profile graph and YouTube Channel Finder discovers channels by keyword.

Why not build this yourself?

Skool publishes no public API. There is no documented endpoint for communities, for pricing, or for a creator's other groups, so there is no official route to compare against — the realistic alternative is writing the scraper yourself, and this Actor's source is a fair map of what that costs.

The data is in a Next.js hydration payload, not the HTML. Every field comes out of the __NEXT_DATA__ script block, and several of the fields you actually want are JSON strings nested inside that JSON: the owner record, the tab-visibility map, the landing-page attachments and the price blob are each a stringified object that has to be parsed a second time before you can read a single value. Prices arrive in minor units with a currency code you have to check against the zero-decimal list before dividing, or every JPY community in your dataset is off by a factor of a hundred.

One community costs at least two page loads, and the second one is where the useful fields live. Discovery gives you the ID, slug, name, member count, price and logo. Owner identity, privacy, plan, admin and post counts, course counts, tab flags and the landing-page copy all exist only on /about. The creator footprint costs a third page — the owner profile — and only pays off if you cache it, because a creator who runs four of the communities in your result set would otherwise be fetched four times.

Pagination is not where you would look for it. The discovery listing pages through an internal _next/data/{buildId}/discovery.json endpoint, and the build ID changes every time Skool deploys, so it has to be read out of the current page rather than hardcoded.

Blocks arrive as a page that simply lacks the payload. There is no status code to check — the request succeeds and __NEXT_DATA__ is missing, which parses to an empty result unless you treat it as a refusal and retry on a different route. Running the Actor here means the parse chains, the price normalization, the build-ID discovery, the profile cache and the proxy ladder are not yours to maintain, and your field names stay put when Skool's internals move.

How to use Skool Group Scraper & Creator's Other Communities

The Actor runs on Apify. Start it from the Apify Console or call it through the Apify API with your Apify token — there is no separate signup, no API key of its own, and no Skool credential at any point.

1. Open Skool Group Scraper & Creator's Other Communities on Apify and click Try for free
2. Put one or more Skool discovery links into Discovery links (urls), one per line. This is the only required parameter, and the Console prefills it with https://www.skool.com/discovery
3. Set Community cap per link (maxItems) to how deep you want to crawl each discovery link. The form defaults to 10
4. Leave Map each owner's other communities (includeOwnerCommunities) on to get the ownerCommunities[] portfolio, and decide whether Owned communities only (ownedOnly) should filter out communities the creator merely joined
5. Click Start, then export the dataset as JSON, CSV or Excel

Rows stream into the dataset as each community finishes enrichment, so results are readable while the run is still going.

How to scale to bulk community extraction

urls is an array, so one run covers as many discovery links as you put in it. They are processed one at a time, and maxItems applies per link, not per run — five discovery links at maxItems: 200 is a ceiling of a thousand communities in one run.

Deduplication is global across the run and keyed on the community id, so the same community appearing under two of your discovery links is written once and charged once. Owner profiles are cached per run and keyed on the owner handle, so a creator who owns six communities in your result set costs one profile fetch, not six. Communities are enriched three at a time.

What can you do with Skool community and creator data?

• 🧭 A market researcher sizing the paid-community space pulls a broad discovery crawl and cross-tabs monthlyPrice against totalMembers and numCourses to see what price points actually sustain a large membership, rather than guessing from the handful of communities everyone quotes.
• 🤝 A partnerships lead filters for rows where ownerCommunitiesCount is greater than one, then reads ownerCommunities[].displayName and ownerCommunities[].totalMembers to find creators who already operate a portfolio — the operators worth a single conversation that reaches several audiences.
• 📈 A competitive analyst schedules the same discovery links weekly and diffs totalMembers, totalPosts and monthlyPrice per id to see which communities are growing and which have quietly repriced, using updatedAt to confirm the community itself changed.
• 📣 An outreach specialist builds a contact list from ownerName, ownerWebsite and supportEmail, filtered on privacy and totalAdmins to skip one-person communities, and approaches the creator directly instead of joining the community to post into it.
• 🤖 An AI engineer building a community-discovery agent indexes displayName, description and landingPageDescription into a vector store keyed on id, storing ownerId and each ownerCommunities[].id as graph edges, so an agent can answer "who else does this creator run, and what do those cost" against a live graph rather than a stale export.

Each of these is callable from an agent framework over the Apify API, since the Actor is a standard HTTP-triggered run.

How does Skool Group Scraper & Creator's Other Communities handle rate limits and blocking?

Discovery runs behind a three-tier fallback ladder. Unless you switch proxyConfiguration on, the first attempt is a direct connection with no proxy. If it fails, the run moves to Apify datacentre proxy; if datacentre is unavailable on your plan, or fails too, the run moves to Apify residential and stays there for the remainder of the run. Residential gets up to three attempts per discovery link, each with a fresh proxy session ID and roughly a second's pause between them. Each discovery navigation is also preceded by a randomized one-to-two-second pause.

A block on Skool does not look like an error code. The page returns, and its __NEXT_DATA__ script block is simply missing — the Actor treats that as a refusal and advances the ladder rather than writing an empty row. Navigation timeouts are 90 seconds for a discovery page and 45 seconds for an /about page or an owner profile, with 30- and 15-second waits respectively for the payload script to attach.

There is no CAPTCHA solving. The Actor has no solver integration and does not attempt one; a challenge is handled exactly like any other refusal.

Failures degrade rather than abort. A discovery link that exhausts the ladder is logged as Could not finish this discovery page and skipped, with no rows written and nothing charged for it — the run continues to your next link. An /about page gets two attempts and then gives up silently, leaving that community's row populated with discovery fields only. An owner profile gets two attempts and then gives up, leaving ownerCommunitiesPartial: true and ownerCommunitiesCount: null.

⬇️ Input

Six parameters, one of them required. Values below are read directly from the Actor's input schema.

Parameter	Required	Type	Description	Example Value
urls	Yes	array	Skool discovery URLs to scan, one per line. The only required parameter. Prefilled in the Console with https://www.skool.com/discovery	["https://www.skool.com/discovery", "https://www.skool.com/discovery?q=marketing"]
maxItems	No	integer	Upper bound of communities pulled from each discovery link. Minimum 1, maximum 50000, schema default 10	50
includeOwnerCommunities	No	boolean	On, each row gets an ownerCommunities[] portfolio built from the owner's public profile. Off, base community fields only. Default true	true
ownedOnly	No	boolean	On, keep only portfolio entries the creator appears to own, matched on creator ID. Off, list every community on their profile. Default true	true
includeOwnerCommunityStats	No	boolean	On, each portfolio entry carries totalMembers and displayPrice. Off, those two keys are null. Default true	true
proxyConfiguration	No	object	Set useApifyProxy: true to route through Apify Proxy from the first request, bypassing the fallback ladder. Prefilled with {"useApifyProxy": false}	{"useApifyProxy": true, "apifyProxyGroups": ["RESIDENTIAL"]}

Five behaviours the field titles do not fully convey:

A run with no urls writes nothing and charges nothing. The Actor logs Add at least one discovery URL to get started. and exits immediately. There is no hidden default discovery page in the code — the https://www.skool.com/discovery you see in the Console is a schema prefill, which populates the form but is not a code default. Calling the Actor over the API with {} therefore produces the zero-row exit, while pressing Start in the Console without editing the form crawls the main discovery page.

maxItems has two different defaults depending on how you start the run. The schema default is 10, so that is what the Console form sends. The code's own fallback when the field is absent, null, or 0 is 100 — so an API call that omits maxItems crawls ten times deeper than a Console run that leaves it alone. Set it explicitly if the number of rows matters to your bill.

The maximum: 50000 is enforced by the form, not by the code, and it is not a promise. Pagination stops early whenever Skool returns a non-OK response, an empty page, or a page containing nothing new. maxItems is a ceiling on how deep the crawl may go, not a guarantee of how many rows you get.

includeOwnerCommunities: false does not change the row shape. ownerCommunities, ownerCommunitiesCount and ownerCommunitiesPartial are still written on every row, at [], null and false. What it saves is one page load per unique owner handle. Note the ambiguity this creates: []/null/false also means "the owner handle could not be resolved", so use the run's input to tell the two apart.

urls quietly accepts more shapes than the stringList editor suggests. Entries may be plain strings or objects of the form {"url": "..."} or {"URL": "..."}, and a value without a scheme has https:// prepended, so www.skool.com/discovery works. There are no other input aliases — startUrls is not read.

Example input

{
  "urls": [
    "https://www.skool.com/discovery",
    "https://www.skool.com/discovery?q=ai%20automation"
  ],
  "maxItems": 50,
  "includeOwnerCommunities": true,
  "ownedOnly": true,
  "includeOwnerCommunityStats": true,
  "proxyConfiguration": {
    "useApifyProxy": false
  }
}

⬆️ Output

Typed, normalized JSON with the same 66 top-level keys on every row of every run. Missing values arrive as null rather than as absent keys — no field is ever omitted, so a consumer can address any path without existence checks. Rows are pushed as each community finishes enrichment, so the dataset fills during the run. Export as JSON, CSV or Excel, or read the dataset through the Apify API. The default dataset view surfaces twelve columns; every key in the table above is present in the raw row.

Every row in the dataset is a community row. The Actor writes no error rows, no diagnostic rows, no summary rows and no accounting rows — there is no errorReason, no status, no isError, no rowType and no type discriminator to filter on, so there is no exclusion expression to apply. Failures appear in the run log, never in the dataset.

That makes the billing rule short, and worth stating exactly. Every row pushed carries the charged event row_result, and a row is pushed once a community has been enriched, whether or not enrichment succeeded:

• A discovery link that fails entirely writes no rows and incurs no charge.
• A community whose /about page fails is still written and still charged, carrying its discovery fields and null for the rest.
• A failed creator lookup is still charged. The owner profile fetch is not a separate billable event and not a separate row — it is an extra page load folded into the same row_result. When it fails you pay the same as when it succeeds, and the failure is visible as ownerCommunitiesPartial: true with ownerCommunitiesCount: null.
• A creator who owns several communities in your results produces one charged row per community, not one per creator. Their profile is fetched once and cached, but the portfolio block is copied onto each of their community rows. If you want one record per creator, group by ownerId after the run.

Example output

One community row, with the creator footprint populated:

{
  "id": "e44528d24bfe4d65b0a412441feaa489",
  "name": "ai-automation-lab",
  "displayName": "AI Automation Lab",
  "description": "Build and sell automations. Weekly builds, teardowns and templates.",
  "landingPageDescription": "A working community for people shipping automations, not watching courses about them.\n\nInside:\n- Weekly live builds\n- Template library\n- Teardown of a real client workflow every Friday\n\n$97/month. Cancel anytime. Questions: hello@aiautomationlab.co",
  "supportEmail": "hello@aiautomationlab.co",
  "monthlyPrice": 97,
  "monthlyCurrency": "usd",
  "annualPrice": null,
  "annualCurrency": null,
  "color": "#2D6CDF",
  "initials": "AA",
  "privacy": 1,
  "membership": 2,
  "plan": null,
  "landingPageAccessType": 1,
  "affiliatePercent": 0,
  "pluginAutoDmEnabled": 0,
  "pluginMinChatLevelEnabled": 0,
  "surveyEnabled": 0,
  "surveyQuestions": [],
  "surveyUpdatedAt": null,
  "logoUrl": "https://assets.skool.com/f/e44528d24bfe4d65b0a412441feaa489/8f1c2a4d",
  "logoBigUrl": "https://assets.skool.com/f/e44528d24bfe4d65b0a412441feaa489/8f1c2a4d-lg",
  "coverSmallUrl": "https://assets.skool.com/f/e44528d24bfe4d65b0a412441feaa489/71bd90ee-md.jpg",
  "faviconUrl": "https://assets.skool.com/f/e44528d24bfe4d65b0a412441feaa489/c40ab112",
  "customLinks": [],
  "totalMembers": 8412,
  "totalOnlineMembers": 137,
  "totalAdmins": 4,
  "totalPosts": 19430,
  "totalRules": 5,
  "numCourses": 6,
  "numModules": 48,
  "audioChatVisible": false,
  "calendarVisible": true,
  "classroomVisible": true,
  "mapVisible": false,
  "landingPageAttachments": [
    {
      "id": "a1f0c9d2e7b3419f",
      "type": 2,
      "imageFileId": null,
      "imageOriginalUrl": null,
      "imageSmallUrl": null,
      "imageBigUrl": null,
      "videoId": "kQ4t2VjR8xE",
      "videoUrl": "https://www.youtube.com/watch?v=kQ4t2VjR8xE",
      "videoThumbnailUrl": "https://i.ytimg.com/vi/kQ4t2VjR8xE/maxresdefault.jpg"
    }
  ],
  "ownerId": "59e737d659f24e69a3810c6191054efd",
  "ownerName": "priyanair",
  "ownerFirstName": "Priya",
  "ownerLastName": "Nair",
  "ownerBio": "Automation consultant. I build the boring systems that make agencies profitable.",
  "ownerLocation": "Lisbon, Portugal",
  "ownerDiscTop": "D",
  "ownerActivityStatus": 1,
  "ownerMyersBriggs": "ENTJ",
  "ownerOnline": true,
  "ownerLastOffline": "1753372800",
  "ownerPictureProfile": "https://assets.skool.com/f/59e737d659f24e69a3810c6191054efd/2b7e91ca",
  "ownerPictureBubble": "https://assets.skool.com/f/59e737d659f24e69a3810c6191054efd/2b7e91ca-sm",
  "ownerInstagram": null,
  "ownerYoutube": "https://www.youtube.com/@priyabuilds",
  "ownerFacebook": null,
  "ownerTwitter": "https://x.com/priyabuilds",
  "ownerLinkedin": "https://www.linkedin.com/in/priyanair",
  "ownerWebsite": "https://aiautomationlab.co",
  "ownerCreatedAt": "2021-08-19T10:22:41.114820Z",
  "ownerUpdatedAt": "2026-07-21T06:03:57.902113Z",
  "createdAt": "2023-02-11T14:07:52.660431Z",
  "updatedAt": "2026-07-24T18:41:09.338177Z",
  "createdBy": "59e737d659f24e69a3810c6191054efd",
  "ownerCommunities": [
    {
      "id": "e44528d24bfe4d65b0a412441feaa489",
      "name": "ai-automation-lab",
      "displayName": "AI Automation Lab",
      "totalMembers": 8412,
      "displayPrice": "97 USD/month",
      "isOwned": true
    },
    {
      "id": "3c9f27b514ad4e8ea2b6d071c9f4e5aa",
      "name": "agency-ops-blueprint",
      "displayName": "Agency Ops Blueprint",
      "totalMembers": 1274,
      "displayPrice": "1997 USD/year",
      "isOwned": true
    },
    {
      "id": "7ab41d0e63f5401c8bd9a2e5f6c31b74",
      "name": "no-code-founders",
      "displayName": "No-Code Founders",
      "totalMembers": 20583,
      "displayPrice": null,
      "isOwned": true
    }
  ],
  "ownerCommunitiesCount": 3,
  "ownerCommunitiesPartial": true
}

How does it work?

The Actor drives a headless Chromium browser through Playwright. For each discovery link it opens the page with no cookies and no stored session, waits for Skool's __NEXT_DATA__ script block, and reads the community list straight out of that payload. If more communities are needed than the first page holds, it pages through Skool's internal discovery JSON endpoint using the build ID it just read from the live page, deduplicating on community ID as it goes.

Each community is then enriched from its public /about page, three communities at a time, which is where owner identity, privacy, plan, counts, tab flags and landing-page copy come from. When the creator-footprint step is on, the owner's public profile at skool.com/@handle is loaded once per handle and cached for the rest of the run, and the communities listed on it are mapped into ownerCommunities[].

Connection handling is automatic: a direct attempt first, then Apify datacentre proxy, then Apify residential, which the run sticks to once it gets there. Only publicly visible data is collected — nothing behind Skool's membership wall is reachable without a login, and the Actor never has one. Because every field is read from Skool's structured hydration payload rather than from rendered markup, a visual redesign of Skool's pages does not change your field names or types.

Integrations

Skool Group Scraper & Creator's Other Communities is an Apify Actor, so it works with anything that can call the Apify API or consume a dataset — code, no-code platforms, Apify schedules and webhooks.

Calling the Actor from Python

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

run = client.actor("<YOUR_USERNAME>/skool-group-scraper-creators-other-communities").call(run_input={
    "urls": ["https://www.skool.com/discovery"],
    "maxItems": 50,
    "includeOwnerCommunities": True,
    "ownedOnly": True,
})

portfolios = {}
for row in client.dataset(run["defaultDatasetId"]).iterate_items():
    if (row.get("ownerCommunitiesCount") or 0) > 1:
        portfolios[row["ownerId"]] = row["ownerCommunities"]

print(len(portfolios), "creators running more than one community")

Works in Go, Ruby, Node.js, cURL — any language that can make an HTTP request. Group on ownerId to collapse a multi-community creator into one record, since the same portfolio block is repeated on each of their community rows.

Schedules and webhooks

Community metrics move, so this Actor is a natural fit for Apify's scheduler: run the same discovery links weekly and diff totalMembers, totalPosts and monthlyPrice per id to build a growth and repricing history. Attach a webhook to the run-succeeded event to push the finished dataset into your own store.

No-code tools (n8n, Make, LangChain)

In n8n, use the Apify node — or an HTTP Request node pointed at the Actor's run endpoint with your Apify token — and pass the same JSON input shown above; a Split Out node on ownerCommunities turns one community row into one item per portfolio entry, which is the shape you want for a creator-level sheet. In Make, the Apify module supports run-and-wait, so a monthly community sweep can map displayName, totalMembers, monthlyPrice and ownerName straight into Google Sheets or Airtable. In LangChain, wrap the run call as a tool and hand the rows to the agent as context — the JSON needs no parsing step.

Is it legal to scrape Skool communities and their creators?

Collecting publicly visible data is broadly treated as permissible where no authentication is bypassed, and this Actor reads only public Skool pages with no login, cookie or session — anything behind a community's membership wall is not accessible to it at all. Most of the output is business and community metadata: community names, slugs, descriptions, member and post counts, course counts, privacy codes and published prices describe a commercial offering, not a person. For those fields the relevant regime is Skool's terms of service and, in the EU and UK, database rights in the compiled listing — not data-protection law. The usual conditions apply: do not present a bulk copy of Skool's discovery listing as a competing directory, and do not overload the source.

The owner* fields are different, and they are personal data. A Skool community owner is almost always an identifiable individual running a paid business, and the Actor returns a lot about them: ownerId, ownerName, ownerFirstName, ownerLastName, ownerBio, ownerLocation, ownerPictureProfile, ownerPictureBubble, ownerOnline, ownerLastOffline, ownerActivityStatus, ownerCreatedAt, ownerUpdatedAt, createdBy, the six social links ownerInstagram, ownerYoutube, ownerFacebook, ownerTwitter, ownerLinkedin and ownerWebsite, plus supportEmail, which is frequently a personal address. Two of them go further: ownerDiscTop and ownerMyersBriggs are self-declared personality attributes tied to a named person.

Under the GDPR, the UK GDPR and the CCPA/CPRA, storing and using those fields needs a lawful basis of your own — the data being public does not supply one. Legitimate interests is the basis most commonly relied on for market research and partner discovery, and it carries a documented balancing test, transparency obligations in the EEA and UK, and the ability to honour access, objection and erasure requests. Data minimisation applies directly, and it is easy to satisfy here: community sizing, pricing analysis and portfolio mapping all run on id, displayName, totalMembers, monthlyPrice, numCourses and ownerCommunities, with ownerId as an opaque join key and no person named anywhere. Drop the identity, personality, avatar, social and email fields at ingest unless your purpose genuinely requires them, and if you keep them, set a retention period and keep them separable.

Consult legal counsel if your use case involves bulk storage of personal data, cross-border transfer, or outreach aimed at the creators named in these fields. This is factual framing, not legal advice.

❓ Frequently asked questions

What Skool community fields does this Actor return?

The five most used are displayName, totalMembers, monthlyPrice, ownerName and ownerCommunities. Every row carries 66 top-level keys, expanding to 81 field paths through the nested ownerCommunities and landingPageAttachments arrays — the full list is in the data fields table above. The default dataset view shows twelve of them as columns; the rest are in the raw JSON.

Does it require a Skool account, login or cookie?

No. There is no credential field in the input schema, the browser context is created with no stored session, and no cookies are sent at any point. It reads only what a logged-out visitor sees on Skool's discovery pages, community /about pages and public creator profiles. The one credential you need is your Apify token, and only if you call the Actor through the API rather than the Console.

How many Skool communities can I extract in one run?

maxItems sets the ceiling per discovery link — minimum 1, maximum 50000 in the form, schema default 10, with a code fallback of 100 when the field is omitted entirely. It is a cap, not a target: pagination stops as soon as Skool returns a non-OK response, an empty page, or a page with nothing new on it, so the real limit is how deep Skool's discovery feed goes. Across a run the ceiling is your number of links multiplied by maxItems, minus any communities that appear under more than one link, since deduplication is global and keyed on id.

What happens if a community is private or deleted, or the creator has no other communities?

All three are ordinary outcomes that produce fewer populated fields, never an error row.

A community that has been deleted or renamed fails at the /about step. Two attempts are made and then the Actor gives up quietly: the row is still written and still charged, carrying the fields discovery already gave it — id, name, displayName, description, pricing, totalMembers, branding and timestamps — with every /about-only field left null. Because ownerName is one of those nulls, the creator-footprint step is skipped for that row, leaving ownerCommunities: [], ownerCommunitiesCount: null and ownerCommunitiesPartial: false.

A private community is not really a case here: Skool's discovery listing only surfaces communities that have a public landing page, and the privacy code on the row tells you which posture a community has taken. What is never reachable is what sits inside one.

A creator with no other communities returns a small ownerCommunitiesCount — 1 when Skool lists the community you already have on their profile, and 0 when it does not, or when ownedOnly is on and Skool's createdBy never matched their ownerId. Both are successful results, which is exactly why ownerCommunitiesPartial exists: a low count is a fact about what Skool published on that profile, not a certified count of what the creator runs. The one case to treat as a failure is ownerCommunitiesPartial: true with ownerCommunitiesCount: null, which means the profile was fetched and could not be read.

Does mapping a creator's other communities cost extra?

It costs an extra page load, not an extra charged row. The owner profile at skool.com/@handle is a third request on top of the discovery page and the community's /about page, and it is folded into the same row_result event as the community row — there is no separate creator event, and no separate creator row. Profiles are cached per run and keyed on the owner handle, so a creator who owns five of the communities in your results is fetched once. Turning includeOwnerCommunities off saves that one fetch per unique handle but changes nothing about the number of rows or the billing.

Can I scan multiple Skool discovery pages at once?

Yes. urls is an array and one run walks every entry, one link at a time, with maxItems applied per link. Communities are deduplicated globally on id, so overlapping discovery links do not produce duplicate rows or duplicate charges. Remember that only the first page of each link honours a ?q= filter — pagination beyond that comes from Skool's unfiltered global discovery feed.

Does it work with Claude, ChatGPT and other AI agent tools?

Yes. It is callable as a standard HTTP-triggered run through the Apify API, so LangChain, CrewAI, n8n or a hand-written tool definition can invoke it and receive typed JSON with no parsing step.

How does this compare to other Skool scrapers on the Apify Store?

Checked on the Apify Store on 25 July 2026, the closest listings solve adjacent problems.

memo23/skool-members-scraper documents member-level extraction from a group's members page, discovery-URL and keyword input, a monitoring mode that tracks newly discovered groups by group ID between runs, and optional contact extraction from members' linked websites. Its own getting-started steps require cookie-based authentication — its listing states that you log in with exported cookies and need to be a member of the group you want to scrape. Mapping a creator's other communities is not documented on its listing.

gordian/skool-group-scraper documents group URLs, slugs and discovery URLs as input, and returns pricing, membership stats, owner details, course counts, custom links and landing-page attachments. Its listing states no Skool account is needed, and that support email addresses are available only on paid Apify plans. Mapping a creator's other communities is not documented there either. Its published output example shows populated affiliatePercent and pluginMinChatLevelEnabled values; in this Actor those two keys are constants, so that is an observable point against it. The third listing surfaced by the same search, lemur/tiktok-shop-creators, is a TikTok Shop creator Actor and not a Skool scraper at all.

Two observable differences on this Actor's side: it returns the creator's other communities as a structured ownerCommunities[] block on the same row, and it returns supportEmail in that row with no plan gate. One against it: it takes discovery URLs only, so it cannot target a single named community the way both of those listings can.

Does it return data in a format LLMs can use directly?

Yes. Every row is typed, normalized JSON with the same 66 keys on every run, and missing values arrive as null rather than as absent keys, so no existence checks are needed. No HTML parsing, no selectors. Pass a row straight into an LLM context window, index it into a vector store, or hand it to an agent tool. ownerId and ownerCommunities[].id give you ready-made graph edges if you are building a creator graph rather than a flat index.

What happens when Skool changes its layout or anti-bot system?

The scraper is maintained, and because it reads Skool's embedded __NEXT_DATA__ payload rather than rendered markup, a visual redesign generally does not affect the output. The parts most exposed to change are the key paths inside that payload and the internal discovery JSON endpoint — which is why the build ID is read from the live page on every run instead of being hardcoded, and why the creator footprint reads renderData.groupsMemberOf with a fallback to renderData.user.profileData.groupsMemberOf. Your field names and types stay the same on your end.

Which fields work best for AI training data and RAG indexing?

For RAG indexing: landingPageDescription is by far the highest-information text on a row and chunks cleanly, with description, displayName and ownerBio as shorter supporting text, and id plus name as the natural metadata keys for citation. For training data and quantitative work: totalMembers, totalPosts, totalAdmins, numCourses, numModules, monthlyPrice, annualPrice and ownerCommunitiesCount are the most structurally consistent fields across records, all returned as typed primitives. Treat privacy, membership, plan and landingPageAccessType as opaque Skool codes rather than labels, and skip the seven constant fields entirely — they carry no signal. If your index does not need to identify people, drop the owner* identity, personality, avatar and social fields and supportEmail at ingest.

🔗 Related scrapers

Pick by what you start with: this Actor when you want Skool communities and the creators behind them, the Facebook pair when the community graph you care about is on Facebook.

Scraper Name	What it extracts
Facebook Group Discovery Scraper	Related and suggested groups expanded from a seed Facebook group, plus public admins
Facebook Groups Search Scraper	Facebook groups by keyword — ID, name, URL, privacy, member count, post frequency
Instagram Related Profiles Scraper	Instagram's suggested-profile graph expanded from a seed profile
YouTube Channel Finder	YouTube channels discovered by keyword or URL
YouTube Shorts Scraper With Creator Lead Enrichment	Shorts plus the creator's public contact details
Tiktok Video Scraper (Creator Profile & Contact)	TikTok videos joined to the creator's profile and contact fields

💬 Your feedback

Found a bug, or need a field that Skool publishes on the /about page but this Actor does not return yet — community rules text, or the admin list? Open an issue on the Actor's Issues tab. Reports that include the exact input JSON and the discovery URL you ran are the fastest to reproduce and fix.