← All posts

How to Scrape Product Hunt: Launches, Upvotes, and Maker Data

GUIDES · JUL 19, 2026 · 6 MIN READ

Product Hunt is one of the cleanest startup-intelligence signals on the open web. Every day it surfaces what founders are shipping, how much traction a launch gets in its first 24 hours, and who is behind it. For a founder scouting a category, a VC building a deal-flow radar, or a product team watching competitors, that daily feed of launches, upvotes, comments, and maker profiles is genuinely useful data. The good news, and what makes Product Hunt different from most sites in this series: there is an official API, and it is the right first move.

Before the mechanics, the framing. This is about collecting public launch data for analysis and trend tracking, using the channel Product Hunt provides for it. It is not about faking upvotes, mass-messaging makers, or republishing someone's launch copy as your own. Get that straight and the rest is a pleasant engineering problem rather than an adversarial one.

Start With the Official GraphQL API

Unlike most scraping targets, Product Hunt hands you a supported way in. It runs a public GraphQL API at api.producthunt.com/v2/api/graphql, and for the majority of startup-intelligence work it is all you need.

You register an application in your Product Hunt account settings, get a client ID and secret, and exchange them for a bearer token. Then you query exactly the shape of data you want in a single request:

{
  posts(order: RANKING, first: 20) {
    edges {
      node {
        name
        tagline
        votesCount
        commentsCount
        createdAt
        website
        makers { name username }
      }
    }
  }
}

That one query returns the day's ranked launches with vote counts, comments, timestamps, and maker handles. No HTML parsing, no rendering, no fingerprint games. GraphQL lets you ask for the exact fields you need and nothing else, which keeps payloads small and your extraction logic trivial.

The API has real advantages worth leaning on:

  • Structured data by design. You get typed fields, not a DOM you have to reverse-engineer.
  • Cursor pagination. Walk through historical launches cleanly with after cursors instead of guessing page URLs.
  • Stable contract. The API changes far less often than page markup does, so your collector does not break every time the site ships a redesign.

The tradeoff is rate limiting. Product Hunt meters the API on a complexity-and-token budget that refills over time, so a large historical backfill needs pacing and backoff. If you hit the ceiling you will see throttling responses; treat them the way you would any 429 and slow down rather than hammering. For the general decision of when a first-party API beats scraping, API vs scraping lays out the same logic that applies here.

When Fetch Is the Right Fallback

If the official API is so good, why scrape at all. A few real situations push you toward fetching pages directly.

  • Fields the API does not expose. Some page-level context, layout, badges, or rendered launch-day framing is not in the GraphQL schema.
  • You want the page as a human sees it. For a lightweight monitor that snapshots the daily leaderboard, grabbing the rendered page and reading it is simpler than maintaining API auth.
  • The token budget is in your way. For a broad, shallow sweep across many pages, page fetches can sidestep the API's complexity accounting.
  • You are already fetching everything else through one pipeline. If your stack pulls fifty other sources by URL, adding Product Hunt as one more URL keeps the code uniform.

Product Hunt is a modern JavaScript app, so the fallback is not a plain HTTP GET. The leaderboard and launch details render client-side, which means a bare request often returns a shell with no launch data in it. You need a client that runs the JavaScript and reads the rendered DOM. The mechanics are in scraping JavaScript-rendered websites. Product Hunt is not nearly as defended as a review site or a marketplace, so you rarely need heavy stealth infrastructure, but you do need real rendering.

The Schema Worth Extracting

Whether you pull from the API or a rendered page, decide up front what a clean launch record looks like. A tight schema makes the data trivial to analyze and keeps you focused on signal rather than hoarding everything.

Field Why it matters Source
Launch name and tagline The what API or page
Upvote count Traction proxy, weight by launch age API
Comment count Engagement depth API
Launch date and time Trend and cohort analysis API
Category and topics Segmentation API
Website URL Enrichment key for other sources API
Maker names and handles Founder tracking API
Launch-day rank Competitive standing API or page

Upvotes are the headline number, but raw counts mislead. A launch three hours old with 200 upvotes is on a very different trajectory than one closing out its day at the same total. Normalize by launch age before you compare. For the general pattern of turning a page or a payload into structured fields, see what is data extraction.

On maker data: names and handles are public professional identities, which is lower-risk than most personal data, but the same discipline applies. Collect what you need for founder tracking and stop there. Do not build a contact database to spam, and think about your lawful basis before you store personal fields. Is web scraping legal covers where public data sits and where "public" stops meaning "do whatever you want."

The Trend-Tracking Use Case

A one-off pull is mildly interesting. The value compounds when you collect on a cadence and diff over time. That is where Product Hunt turns into an intelligence source rather than a curiosity.

  • Daily leaderboard snapshots. Capture the top launches each day and you build a longitudinal record of what a category is shipping and how the market responds.
  • Category momentum. Track how many AI-agent tools, say, launch per week and how their vote distributions move. That is a leading indicator VCs pay for.
  • Founder radar. Watch specific makers so you catch their next launch on day one instead of a quarter late.
  • Traction benchmarks. Knowing the median upvote count for a category gives you a yardstick for judging any single launch.

The collect-on-a-schedule-and-diff discipline is the same one behind monitoring competitor pricing changes; point it at launches instead of prices and the cadence, caching, and change detection transfer directly. Cache aggressively, because yesterday's launches do not change, and only fetch what is new.

Letting One Pipeline Handle Both Paths

The clean architecture is: use the GraphQL API for structured launch and maker data, and keep a fetch fallback for the fields and pages the API does not cover. The friction is maintaining two code paths, plus rendering infrastructure for the fallback that has to keep working as the site evolves.

link.sc is one API that runs the fetch side for you. You pass a Product Hunt URL and get back clean markdown, JSON, or raw HTML, with the JavaScript rendering and escalation handled internally, cheapest-first, so a simple page does not trigger a full browser render.

import requests

resp = requests.post(
    "https://api.link.sc/v1/fetch",
    headers={"x-api-key": "lsc_YOUR_KEY"},
    json={"url": "https://www.producthunt.com/", "format": "markdown"},
)
print(resp.json()["content"])

Pair the official GraphQL API for structured data with link.sc for the page-level fallback and you get complete coverage from two clean interfaces instead of a rendering stack you have to babysit. It is open core and self-hostable if you would rather run it yourself, and the developer guide walks through the first request.

Turn the daily launch feed into a startup-intelligence signal: grab a free API key with 500 credits a month and let the fetch fallback run itself.