Overview
The AppSumo Product Catalog Scraper is an AppSumo scraper: a standalone desktop bot that opens the AppSumo search page, expands the results grid until every deal card is rendered, and pulls roughly thirty catalog fields per listing into the appsumo_listings dataset. It never leaves the search page - there are no per-product page visits in this configuration - which is why a full-catalog run finishes in minutes instead of hours. Everything it reads is exactly what a logged-out shopper sees on appsumo.com: deal names, taglines, categories, current and original prices, star ratings, review counts, countdown badges, AppSumo Select flags and card images.
This listing is not affiliated with or endorsed by AppSumo. One honesty note on the selectors: they target AppSumo’s current public markup and will need updating when AppSumo redesigns its cards - when that happens, a run ends with empty fields or zero rows rather than invented ones.
What does the AppSumo Product Catalog Scraper do?
The run is one expansion phase followed by one extraction. The bot lands on the AppSumo search URL, composed from a single optional settings variable, search_query. Leave that variable empty and the search returns the full catalog - 334-plus active products at the time this configuration was written. Type a keyword such as seo or video hosting and the same run collects only the matching slice of AppSumo’s deals.
Expansion happens in two passes because the deal grid lazy-loads in two ways. First the run presses Escape once to dismiss cookie or promo overlays that would otherwise sit on top of the load-more control. Then it scrolls the page twice with a 2500 ms pause to wake lazy rendering, and enters a click loop: as long as a load-more control is visible - the configuration carries four label variants (Show More Results, Load More, Show more results, View More) to survive minor copy changes - the bot clicks it and waits three seconds for the next batch of cards. When no load-more control remains, a single extraction pass walks every card. The item selector anchors on AppSumo’s deal price container inside each card and climbs to the enclosing card element, so the dataset stays bound to real listing cards rather than arbitrary grid children. product_url and product_name are declared required fields, and rows are deduplicated by product_url, so a card rendered twice during expansion lands exactly once.
Because everything runs on your own machine, your research footprint stays yours: which categories you size, which competitors you benchmark, which price bands you study never passes through a third-party service’s dashboard or logs.
Who uses an AppSumo scraper?
The SaaS founder pricing an AppSumo launch asks “what discount depth do comparable tools open at?” and needs price_current next to price_original across a whole category. The affiliate and newsletter operator asks “which AppSumo deals expire this week, and which are rated well enough to recommend?” and needs deal_days_remaining, rating and review_count in one dated table. The market researcher asks “how dense is AppSumo’s productivity category, and how fast do new launches accumulate reviews?” and re-runs monthly to measure review velocity. The vendor-side competitive analyst asks “do rival products carry the AppSumo Select badge, and at what billing period?” and needs is_appsumo_select and price_period per row.
How does an AppSumo catalog scrape run, step by step?
Every command in the run links to its reference page. First, press sends the Escape key to the page root, clearing any consent or promo overlay. Second, infinite_scroll runs a capped pass - two scrolls maximum, 2500 ms apart - which is enough to trigger the lazy-rendered grid without chasing the footer endlessly. Third, a while loop checks for a visible load-more button across four label variants, and each iteration clicks it and waits 3000 ms for the next batch to render. Fourth, extract_data pulls the appsumo_listings dataset once, after expansion is complete - card-level extraction, one pass, deduplicated by product_url. This release sets no fixed export filename, so rows land in the launcher’s local results store and you export them from the results view; nothing is uploaded anywhere except the configuration fetch and download telemetry listed on this page.
What does the output look like?
The table mirrors the published sample row (fourteen of the roughly thirty fields - the dataset carries the rest). Sample values are illustrative placeholders that show the shape of a real row:
| product_name | product_slug | tagline | category_name | price_current | price_original | price_currency_symbol | price_period | rating | review_count | deal_badge_type | deal_days_remaining | listing_position | product_url |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FlowDesk Pro | flowdesk-pro | Visual workflow planner for solo consultants | Productivity | 59 | 240 | $ | lifetime | 4.5 | 312 | deal_ending | 4 | 1 | https://appsumo.com/products/flowdesk-pro |
product_name is the deal title and a required field - an empty name means the card never rendered properly, and the row is logged rather than trusted.
product_url and product_slug identify the listing; product_url is the deduplication key (the appsumo.com/products/ link, with any anchor fragment stripped), and the slug is regex-extracted from it, giving you a short stable join key when you diff two dated snapshots.
tagline is the clamped card description - the one-line pitch AppSumo shows shoppers.
category_name, category_url, category_slug, category_group_slug and category_parent_slug capture AppSumo’s category taxonomy at three levels - the group and parent slugs are parsed straight out of the appsumo.com path structure - and categories is a nested list of every category link on the card with its name, URL and depth level.
price_current and price_original are the deal price and the struck-through reference price, both cast to numbers with a null fallback; an empty original means the card shows no discount. price_currency_symbol, price_period and price_raw keep the symbol, the billing period (lifetime, year, month) and the untouched display text for auditing.
rating, rating_label, review_count, review_count_text and review_url are the aggregate social-proof signals pulled from the star image and the reviews anchor - numeric casts fall back to null on brand-new listings, and review text is never collected.
deal_badge_text is the countdown strip verbatim; deal_badge_type normalises it to deal_ending, price_increase or plus_access_ending, empty otherwise; deal_days_remaining is the integer day count parsed out of the strip.
is_appsumo_select counts the AppSumo Select badge image and appsumo_select_badge_url keeps its source; plus_exclusive_label captures the Plus exclusive suffix on the product name when present.
product_image_url (tracking query stripped), product_image_url_resized and product_image_alt carry the card artwork.
listing_position is the 1-based card order in the results, and card_text_snapshot is the full collapsed text of the card - a fallback field that keeps a run useful even when one specific selector breaks.
Can AppSumo deal data feed competitive research?
Yes - with the boundary stated plainly. This bot gives you a dated, structured snapshot of card-level truth on AppSumo: what is listed, in which category, at what price against what reference price, with what social proof and what urgency signals. What it does not do is go deeper or enrich: no product detail pages, so no full descriptions, plan tiers, launch dates or vendor information; no review text; no validation against third-party databases. The intended analysis pattern is diffing two snapshots on product_url - price moves, review velocity, badge changes, new launches and quiet removals all fall out of that comparison. For the review stream itself, the sibling AppSumo Product Reviews Scraper is the companion configuration.
How does lifetime deal research work with AppSumo data?
Lifetime-deal economics live in a handful of these columns. price_period separates true lifetime deals from disguised subscriptions. Discount depth - price_original against price_current - shows how aggressively a category prices its AppSumo launches. deal_days_remaining and deal_badge_type turn the catalog into a prioritised expiry calendar for roundups or last-look competitive reviews. is_appsumo_select and plus_exclusive_label segment the editorially promoted slice from the open catalog, which is where pricing norms for featured placement become visible. Run the snapshot weekly, join on product_url, and the panel data builds itself.
How does it compare to hosted AppSumo scraping services?
Copy-pasting cards by hand produces a handful of rows an hour and no consistency at all. Hosted robot and actor marketplaces do offer AppSumo collectors, but the structure is the opposite of this bot: they meter by the result or by the month, the data lands in their cloud under their retention terms, and your search history - the categories you size, the competitors you watch - lives on their servers. Here the marginal cost of a bigger search is your own time and bandwidth, the datasets stay on your disk, and the workflow configuration is yours to keep, modify and re-run. The trade is real: no dashboards, no built-in scheduling, no cloud-side retry. You get an artifact and a workflow you own outright.
How do you set it up on Windows, macOS and Linux?
Download the launcher for your operating system from this page. On Windows, run the downloaded .exe directly - there is no installation step; SmartScreen may ask for confirmation on first launch, so verify the published checksum, then choose More info and Run anyway. On macOS, two launchers are published - pick the one matching your machine’s chip (Apple menu, About This Mac: Apple Silicon or Intel) - then make it executable with chmod +x, clear the Gatekeeper quarantine with xattr -d com.apple.quarantine /path/to/BOT_appsumo-product-catalog-scraper.sh and launch. On Linux, chmod +x ./BOT_appsumo-product-catalog-scraper.sh then ./BOT_appsumo-product-catalog-scraper.sh. At first run the launcher asks for the optional search_query value - empty for the full AppSumo catalog, a keyword for a slice - and starts the run. To repeat a snapshot on a cadence, schedule the launcher with your OS scheduler (Task Scheduler, cron or launchd).
What do I check when a run returns zero rows?
Work in order. Zero rows: did the AppSumo search page render in an ordinary browser, or did a consent wall, region lock or challenge greet the fresh session - the single Escape press dismisses common overlays, not all of them. A suspiciously small row count: the load-more loop exits when none of its four button labels matches, so a copy change on that control truncates the run silently - compare the row count against what appsumo.com shows interactively before trusting a snapshot. Rows present but one column empty across every row: that field’s selector most likely changed in an AppSumo redesign; check one card by hand. Empty rating or review_count on scattered rows: completely normal for new listings - the numeric casts fall back to null rather than failing the row. The contract is that failure is loud - empty values and zero rows, never fabricated data.
What are the bot’s limits?
It reads AppSumo search-result cards only: no detail-page fields, no review text, no photos beyond card images, no vendor or company data. It ships without proxy rotation or CAPTCHA solving enabled - if a challenge stops the run, the run stops; nothing bypasses it. Expansion is bounded by the load-more labels it recognises, so an AppSumo redesign can truncate coverage, which is why the row-count check above matters. One run covers one search term. It is a snapshotter, not a monitor - nothing re-runs, diffs or alerts on its own. Deduplication applies within a run on product_url; merging across runs is your step.
What is responsible AppSumo data collection?
The fields collected here are public commercial data - product names, prices, aggregate ratings - and this configuration deliberately stops short of review text and reviewer identities, which keeps personal data out of the dataset entirely. That does not remove your obligations: automated collection may conflict with AppSumo’s terms of service, so review those terms with open eyes before each run and let the acceptable-use policy govern it. Keep request volume at what a patient human could sustain - the built-in waits already pace the run that way. Date every snapshot, and if you republish derived analysis, do so in ways AppSumo permits. This bot is an independent tool, not affiliated with or endorsed by AppSumo.
