Skool Group Scraper With Owner Contact Leads
Pricing
Pay per usage
Skool Group Scraper With Owner Contact Leads
🎓 Skool Group Scraper extracts public data from Skool communities—members, posts, topics, reactions & links—into clean CSV/JSON. 🔎 Perfect for community research, outreach, competitive analysis & content strategy. ⚡ Fast, reliable, API-ready.
Pricing
Pay per usage
Rating
0.0
(0)
Developer
Scrapier
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
7 days ago
Last modified
Categories
Share
Skool Group Scraper — Owner Emails, Phones, and Monetization Data
Skool Group Scraper With Owner Contact Leads turns any Skool discovery page into a table of contactable community owners. Point it at a discovery URL and every community that appears there comes back as one row — profile, pricing, member count — enriched with the owner's social links, monetization badge, last-online time, and a best-effort parsed email and phone number. Every response is structured JSON, ready to load into a CRM, score with an LLM, or feed a cold-outreach pipeline. As Skool's creator economy keeps expanding, that owner list is the fastest way to find who actually runs a community, not just who posts in it.
What is Skool Group Scraper With Owner Contact Leads?
It is an Apify Actor that queries Skool's public discovery directory and turns every community it finds into a full community-plus-owner record. Unlike a member scraper, it does not enumerate a community's rank-and-file members — it resolves exactly one lead per community: the owner. That owner record is where this Actor differs from every other Skool scraper on the Store — it appends a dedicated owner contact-lead block (email, phone, socials, monetization badge, last-online, and a hasOwnerContact flag) on top of the standard community profile. No Skool account, login, or cookies are required; the Actor reads only what a logged-out visitor can see.
Real capability, one bullet per input control:
- 📇 Discovery harvesting — feed one or more Skool discovery URLs (
urls) and every community listed there becomes a row - 📊 Per-link lead cap —
maxItemscaps how many owners are pulled from each discovery link (1–50,000) - 📧 Best-effort contact parsing —
extractOwnerContactscans the owner's bio, website, and community description for an email and phone number - 🏅 Monetization + last-seen signal —
includeOwnerStatusattaches the owner's Skool monetization badge and a readable last-online timestamp - ✅ Contactable-only filtering —
requireOwnerContactdrops any community whose owner has no reachable channel, and those dropped rows are never saved or charged - 🔒 Optional proxy control —
proxyConfigurationlets you force Apify Proxy from the first request instead of the Actor's automatic connection fallback
What data can you get with Skool Group Scraper With Owner Contact Leads?
Every row blends five field groups: the community's public profile, its pricing and membership terms, its activity counters, the owner's profile, and — the differentiator — the owner's contact-lead block.
| Result type | Extracted fields | Primary use case |
|---|---|---|
| Community profile | id, name, displayName, description, color, initials, logoUrl, logoBigUrl, coverSmallUrl, faviconUrl, customLinks | Identify and de-duplicate communities |
| Pricing & membership | monthlyPrice, monthlyCurrency, annualPrice, annualCurrency, membership, plan, landingPageAccessType, privacy | Qualify leads by price point and access model |
| Community activity | totalMembers, totalOnlineMembers, totalAdmins, totalPosts, totalRules, numCourses, numModules, audioChatVisible, calendarVisible, classroomVisible, mapVisible | Size and engagement scoring |
| Owner profile | ownerId, ownerName, ownerFirstName, ownerLastName, ownerBio, ownerLocation, ownerDiscTop, ownerActivityStatus, ownerMyersBriggs, ownerOnline, ownerLastOffline, ownerPictureProfile, ownerPictureBubble, ownerCreatedAt, ownerUpdatedAt | Personalize outreach |
| Owner contact leads | ownerEmail, ownerPhone, ownerSocials (instagram, youtube, facebook, twitter, linkedin, website), ownerMrrStatus, ownerLastOnline, hasOwnerContact | Build a cold-outreach or CRM lead list |
| Landing page & support | landingPageDescription, landingPageAttachments, supportEmail | Read the sales pitch a prospect sees before joining |
🧲 Owner contact leads
This is the block that makes the Actor a lead generator instead of a directory dump. ownerSocials is always attempted and normalizes the six flat social fields Skool exposes on an owner profile into one nested object. ownerMrrStatus and ownerLastOnline come straight from Skool's own owner metadata — the badge (e.g. liftoff, clover, crown) and a human-readable ISO 8601 timestamp converted from the raw nanosecond ownerLastOffline value. ownerEmail and ownerPhone are a best-effort regex parse over the owner's bio, personal website field, and community description — Skool's own API never returns an owner email, so these two fields are derived text extractions, not authoritative account data, and coverage is low (under 60%, since most Skool creators publish neither). hasOwnerContact is true the moment any one of email, phone, or a social link resolves to a value, which is what requireOwnerContact filters on:
Community and pricing profile
The base profile fields cover what a community charges and how big it is: monthlyPrice/annualPrice (parsed from Skool's raw price blob and normalized out of minor currency units), membership and plan (access model), and the activity counters (totalMembers, totalPosts, numCourses, and so on). Use this block to rank owner leads by community size or monetization tier before you ever look at contact fields — a crown-badge owner running a 5,000-member paid community is a very different lead than a free community with 12 members.
Why not build this yourself?
Skool does not publish a public API for its discovery directory or group listings. The only interfaces are the authenticated web app and the internal Next.js data routes (/_next/data/<buildId>/discovery.json) the site itself uses to paginate — undocumented, versioned by a build ID that changes on every Skool deploy, and reachable only after the page has rendered its __NEXT_DATA__ payload. Building this in-house means reverse-engineering that payload, tracking the build ID, and maintaining a connection-fallback ladder (direct → datacenter proxy → residential proxy, with up to three retries and a fresh session ID on each) to survive anti-bot escalation — all before writing a single line of owner-contact parsing.
Skool is also a single-page app with continuous background network traffic, so a naive scraper that waits for the page to go network-idle will time out on almost every run. This Actor waits specifically for the script#__NEXT_DATA__ element to attach to the DOM instead, which is present as soon as the server-rendered payload lands — a detail that only shows up once you've watched a generic headless-browser scraper fail against this exact site. This Actor keeps that maintenance internal and exposes a stable input/output contract instead.
What is the difference between a Skool member scraper and an owner-lead scraper?
A member scraper enumerates every person inside a community you already belong to; an owner-lead scraper enumerates the one person who runs each community you find in search. As observed on the memo23/skool-members-scraper listing (checked 2026-07-26), member-level scraping "require[s] users... to log in using cookie-based authentication, and you need to be a member or part of the group that you want to scrape" — you export session cookies from a logged-in browser and hand them to the Actor. Skool Group Scraper With Owner Contact Leads takes the opposite approach: it never touches a member list and never requires a Skool session. It reads only the public discovery route and each community's public /about page, and returns exactly one enriched row per community — the owner. If you need every member's profile inside groups you belong to, a member scraper is the right tool; if you need a list of who to contact about a community, this Actor returns that directly without a login step.
How to scrape Skool with Skool Group Scraper With Owner Contact Leads?
- Open the Actor's page in Apify Console and start a new run (or use the Apify API /
apify_client). - Paste one or more Skool discovery URLs into
urls— one per line (e.g.https://www.skool.com/discovery). - Set
maxItemsfor the lead cap per link, and toggleextractOwnerContact,includeOwnerStatus, andrequireOwnerContactfor the exact lead shape you want. - Start the run.
- Open the Output tab to browse results, or export as JSON, CSV, or Excel.
Example input:
How to run multiple discovery links in one job
urls accepts a full list of discovery links — different search queries, different Skool categories — and the Actor works through them in order, up to maxItems communities per link. Communities are de-duplicated by their Skool group id across the whole run, so a community that surfaces under two overlapping discovery links is only enriched, saved, and charged once. Within a single discovery link, owner-page enrichment (the /about fetch for each community) runs with an internal concurrency of 3 — this is fixed in the Actor's code, not a configurable input, so total run time scales roughly linearly with the number of communities across all your urls.
⬇️ Input
| Parameter | Required | Type | Default / constraints | Description |
|---|---|---|---|---|
urls | Yes | array (string list) | prefill: ["https://www.skool.com/discovery"] | One Skool discovery URL per line. Every community found here is enriched into an owner lead. |
maxItems | No | integer | default 10; min 1; max 50000 | Maximum owners to pull from each discovery link. Start small to sample, raise it for a full harvest. |
extractOwnerContact | No | boolean | default true | Scan the owner's bio, website, and community description for an email address and a phone number. Coverage is low (under 60%) — most Skool creators publish neither. Off leaves both null. |
includeOwnerStatus | No | boolean | default true | Attach the owner's Skool monetization badge (ownerMrrStatus, e.g. liftoff/clover/crown) and a readable last-online timestamp (ownerLastOnline). |
requireOwnerContact | No | boolean | default false | Keep only communities whose owner has at least one reachable channel (email, phone, or a social link). Filtered-out rows are neither saved nor charged. |
proxyConfiguration | No | object (proxy editor) | prefill: { "useApifyProxy": false } | Enable to route through Apify Proxy from the first request. Off runs the Actor's automatic direct → datacenter → residential fallback. |
No Skool login, cookie, or API key is required for any parameter — none of the inputs above are credentials.
Common pitfall: urls must point to a Skool discovery route (e.g. https://www.skool.com/discovery or a filtered discovery URL like ?q=marketing), not a single group's page or a /-/members URL — extraction depends on the discovery route's embedded group list, and a non-discovery URL will fail to enrich. Also remember that requireOwnerContact silently reduces your row count below maxItems: filtered communities are dropped before they are saved, so they never appear in the dataset and are never billed.
⬆️ Output
Each row is typed, normalized JSON with a consistent schema across runs, pushed to the Actor's default Apify dataset under the row_result pay-per-event charge. Communities filtered out by requireOwnerContact are excluded from the dataset entirely and are not charged. From the dataset, export to JSON, CSV, or Excel directly from Apify Console or the API. The dataset's default view surfaces 11 columns for quick scanning (displayName, name, ownerName, ownerEmail, ownerPhone, ownerInstagram, ownerMrrStatus, ownerLastOnline, hasOwnerContact, totalMembers, ownerLocation) — every row actually carries all fields documented in the table above and below.
Scraped results
The third row above shows what a community looks like when its /about page fails to enrich after both attempts (network error, block, or an unusually slow render): enrich_one_record retries the /about fetch once, and if both attempts fail, the row is still saved — with the community's discovery-page fields intact but every owner field left at its initial null, and hasOwnerContact correctly resolving to false. It is not dropped, so a requireOwnerContact: true run would exclude it, but a default run keeps it in the dataset as a genuinely unenriched — not fabricated — record.
⚠️ Fields that never populate: affiliatePercent, pluginAutoDmEnabled, pluginMinChatLevelEnabled, surveyEnabled, surveyQuestions, surveyUpdatedAt, and customLinks are written by the Actor's own code as constants (0, 0, 0, 0, [], null, []) and are never overwritten from Skool's page data — treat them as reserved/always-empty rather than a live signal, unlike every other field in the table above.
How can I use the data extracted with Skool Group Scraper With Owner Contact Leads?
- 📈 Growth and partnership marketers: filter to
hasOwnerContact: trueand a targetownerMrrStatustier, then run cold outreach to community owners about tools, affiliate deals, or sponsorships. - 🤖 AI engineers and LLM developers: feed the JSON straight into an agent as grounding context — a lead-qualification agent can reason over
ownerBio,totalMembers, andownerMrrStatuswithout any additional scraping step. - 📊 Market researchers: track niche saturation and monetization tiers across a category by aggregating
monthlyPrice,totalMembers, andownerMrrStatusacross a discovery search. - 🎯 Sales and BD teams: qualify leads before outreach by community size (
totalMembers) and monetization badge (ownerMrrStatus) instead of cold-emailing every owner found.
How do you monitor owner contact leads over time?
Monitoring here means re-running the same discovery URL(s) on a schedule and diffing the new dataset against the previous one. Between runs, three things typically change: new communities enter the discovery feed for your search terms, an owner who previously had no contact channel now has one (hasOwnerContact flips from false to true), or an owner crosses into a new monetization tier (ownerMrrStatus changes, e.g. liftoff → clover). The fields worth diffing between two runs are id (to detect new communities), hasOwnerContact, ownerMrrStatus, ownerLastOnline, and totalMembers.
A practical loop: schedule a recurring run of your discovery URL(s) with Apify Schedules → export each run's dataset by id → compare the new run's rows against the previous run's export → flag any row where id is new, or where hasOwnerContact or ownerMrrStatus changed. This Actor does not persist run state internally or maintain its own cross-run deduplication store, so the diff itself has to happen outside the Actor — in your own script, spreadsheet, or pipeline that stores the previous export.
Integrate Skool Group Scraper With Owner Contact Leads and automate your workflow
Skool Group Scraper With Owner Contact Leads works with any language or tool that can send an HTTP request through the Apify API.
REST API with Python
Scheduled monitoring and delivery
Set up an Apify Schedule to re-run the same discovery URLs on a cron interval, then pull each run's results with the API or an Apify webhook that fires on ACTOR.RUN.SUCCEEDED. There is no built-in incremental or "new leads only" mode in this Actor — every scheduled run returns the full set of communities up to maxItems, so deduplication against prior runs happens in your own downstream pipeline, as described above.
Is it legal to scrape Skool group and owner data?
Yes — scraping publicly accessible, logged-out web pages is generally legal. Skool Group Scraper With Owner Contact Leads reads only what any visitor can see without signing in: the discovery directory and each community's public /about page. In hiQ Labs, Inc. v. LinkedIn Corp., 938 F.3d 985 (9th Cir. 2019), the Ninth Circuit held that scraping data a website makes available to the public, without bypassing a login, does not violate the U.S. Computer Fraud and Abuse Act. Because owner names, bios, locations, and best-effort-parsed emails and phone numbers are personal data of identifiable individuals, GDPR (for EU residents) and CCPA (for California residents) framing applies to how you store, process, and reuse this data — public availability does not exempt you from those obligations. Consult your legal team before bulk-storing or reselling this data for commercial use.
❓ Frequently asked questions
Does Skool Group Scraper With Owner Contact Leads require a Skool login or cookies?
No. The Actor runs fully logged out — it never asks for a Skool session, cookie, or API key, and none of its input parameters are credentials.
What Skool URLs can I put into urls?
Discovery URLs only — for example https://www.skool.com/discovery or a filtered discovery URL such as https://www.skool.com/discovery?q=marketing. Individual group pages or /-/members URLs are not supported, because extraction depends on the discovery route's embedded __NEXT_DATA__ group list.
How many communities does it return per discovery link?
Up to maxItems (default 10, minimum 1, maximum 50000). The Actor paginates Skool's internal discovery data endpoint until it either hits that cap or Skool stops returning new communities for that search.
How does Skool Group Scraper With Owner Contact Leads handle Skool's anti-bot measures?
It runs a connection-fallback ladder: direct connection first, then a datacenter proxy, then up to three residential-proxy attempts with a fresh session ID between retries, plus a randomized 1–2 second delay before each page load. Turning on proxyConfiguration skips the ladder and routes through Apify Proxy from the first request instead.
Does it extract owner contact leads (email, phone, socials)?
Yes. ownerSocials (Instagram, YouTube, Facebook, Twitter, LinkedIn, website) is always attempted from the owner's public profile. ownerEmail and ownerPhone are best-effort regex extractions over the owner's bio, website, and community description, gated by extractOwnerContact; they are null whenever the owner never published one in that text, which is the majority case.
Why might ownerEmail and ownerPhone come back null?
Because they are parsed from free text the owner chose to publish, not pulled from an authoritative field — Skool's own API never exposes an owner email. Coverage is under 60%. ownerSocials and ownerMrrStatus have far higher coverage and are usually the more reliable contact signal.
How do I keep only contactable owners?
Turn on requireOwnerContact. Any community whose owner has no email, phone, or social link is dropped before it's saved — those rows are not written to the dataset and are not charged under row_result.
How do I monitor new communities or owners over time?
Schedule a recurring run of the same discovery URL(s) with Apify Schedules, then diff each run's dataset against the previous one by id, hasOwnerContact, and ownerMrrStatus. The Actor itself does not track state between runs.
Does it work with Claude, ChatGPT, and AI agent frameworks?
Yes, as an HTTP endpoint — any agent framework that can call the Apify API can trigger a run and read back the dataset with apify_client or a plain REST call. There is no dedicated MCP server documented for this Actor.
How does Skool Group Scraper With Owner Contact Leads compare to other Skool scrapers?
As observed on their listings (checked 2026-07-26), memo23/skool-members-scraper requires cookie-based login and group membership for member-level scraping and offers an optional "Include Contacts from Website" toggle on member profiles; this Actor needs no login at all and is scoped specifically to community owners, with a dedicated contactable-only filter (requireOwnerContact) that skips billing on filtered rows. Generic owner-lead extractors on other platforms — for example avinashchby/restaurant-owner-leads (Google Maps restaurants) and webcrawlerr/dubai-property-crawler (Dubai listings) — apply the same "resolve an owner's contact from a public listing" idea to different platforms entirely, not Skool.
Can I filter or sort results by price, member count, or monetization badge in the input?
No — there is no input parameter for that. The Actor returns every community up to maxItems in the order Skool's discovery feed serves them, with the fields (monthlyPrice, totalMembers, ownerMrrStatus, and so on) attached to each row. Filtering or sorting by those values happens after export, in your own spreadsheet, database, or downstream script — the one built-in row-level filter is requireOwnerContact, and it only checks for the presence of a contact channel, not its value.
Can I use it without managing proxies or platform credentials?
Yes. No Skool account, cookie, or API key is required, and proxy handling is automatic by default — the Actor runs its own direct → datacenter → residential fallback unless you explicitly turn on proxyConfiguration to force Apify Proxy.
💬 Your feedback
Found a bug or a field that doesn't match what Skool actually shows? Let us know via the Issues tab on this Actor's page in Apify Console — that's the fastest way to report a break or request a new field, and it helps keep this Actor maintained.
