Product Hunt API Alternative: Daily Launch Data at Scale

Product Hunt does ship a real, modern GraphQL API — and for a lot of jobs it’s still the wrong fit. The friction shows up the moment you want daily launch data at any meaningful cadence. You have to register an OAuth application, mint a token, and then live inside a complexity-based rate budget: every query costs points based on how deeply it’s nested and how many fields it pulls, and a day’s worth of posts with their makers, topics, and vote counts adds up fast. Pull the full leaderboard for every day across a quarter and you’ll spend more time backing off the rate limiter than collecting data. Meanwhile, the exact same launch data renders on Product Hunt’s public homepage and leaderboard, unauthenticated. This guide covers the Product Hunt API alternative built on that public feed.

Why the official GraphQL API gets in the way

The API is well-designed; it’s just optimized for app integrations, not bulk extraction:

• OAuth setup overhead. You register an application and manage a token before your first query. Fine for a product, annoying for a one-off pull.
• Complexity budget. Rate limiting is points-per-query, not requests-per-hour. A richly nested query (post → makers → topics → comments) burns the budget quickly, and you throttle long before you’ve covered much history.
• Throttling on backfill. Walking the leaderboard day by day across months is exactly the access pattern the complexity budget punishes hardest.
• Field gating. Some fields and depths are constrained, and the cost of asking for everything you want per post is high.

For a single dashboard widget the API is perfect. For “give me every launch this quarter with votes, makers, and links,” it fights you.

What the public leaderboard exposes

Product Hunt’s site is a Next.js app, and the launch data hydrates into the page as JSON. The two surfaces that matter:

The daily leaderboard:

https://www.producthunt.com/leaderboard/daily/{YYYY}/{M}/{D}

This page renders the ranked products for any given day — which is exactly the unit of data most people want. The embedded page state (__NEXT_DATA__ and the app’s data payloads) carries, per product: name, tagline, the slug/URL, current vote count, comment count, the topics it’s filed under, the thumbnail, the makers and hunter, and the outbound product link.

The homepage / today feed (https://www.producthunt.com/) gives the same shape for the current day’s live launches, useful for near-real-time monitoring.

There are also weekly and monthly leaderboards on the same URL pattern (/leaderboard/weekly/..., /leaderboard/monthly/...) if you want aggregated views.

Because it’s all server-rendered and hydrated for anonymous visitors, none of it needs an OAuth token — it’s the data Product Hunt shows the public.

How pagination and dates work

The nice property of the daily leaderboard is that the date is the pagination key. You don’t chase opaque cursors; you iterate dates:

.../leaderboard/daily/2026/6/4
.../leaderboard/daily/2026/6/3
.../leaderboard/daily/2026/6/2

Each day is one page of ranked products (typically the full slate of that day’s launches). To backfill a quarter, you walk the calendar — trivially deterministic and resumable, versus the API’s complexity-gated cursor walk.

▶ Try the Product Hunt Daily Launches Scraper on Apify — daily ranked launches with votes, makers, and links from the public leaderboard, no OAuth app required. No auth required.

Rate limits and how to live with them

The public pages don’t expose a points budget, but Product Hunt (behind a CDN) will throttle a single IP fetching hundreds of days a minute. Sensible practice:

1. Throttle to a request every couple of seconds per IP. A full year is only ~365 page loads — there’s no need to rush.
2. Cache by date. A past day’s leaderboard is immutable history; fetch it once and never again.
3. Refresh only today (and maybe yesterday). Vote counts move during the live day, then settle. Re-pull only the active window.
4. Rotate IPs for big historical backfills, but for ongoing daily monitoring one IP is plenty.

A clean output schema

One row per product launch:

{
  "launch_date": "2026-06-04",
  "rank": 1,
  "name": "Acme AI Notetaker",
  "tagline": "Meeting notes that actually summarize themselves",
  "url": "https://www.producthunt.com/posts/acme-ai-notetaker",
  "website": "https://acme.ai",
  "votes": 612,
  "comments": 48,
  "topics": ["Artificial Intelligence", "Productivity", "SaaS"],
  "thumbnail": "https://ph-files.imgix.net/...",
  "makers": [
    { "name": "Jane Doe", "username": "janedoe", "profile": "https://www.producthunt.com/@janedoe" }
  ],
  "hunter": { "name": "John Smith", "username": "jsmith" },
  "scraped_at": "2026-06-05T12:00:00Z"
}

Use launch_date + url (or the post slug) as the natural key — a product can technically relaunch, so date-qualifying it keeps history clean.

Use cases

• Lead generation for makers — every day’s launches are a fresh list of founders shipping something; the makers’ usernames and product websites feed B2B outreach for dev tools, infra, and SaaS vendors.
• Competitive launch monitoring — watch your category’s topics daily and alert when a competitor or adjacent tool launches.
• Trend analysis — aggregate topics and vote distributions over months to see which categories are heating up on PH.
• Investor / scout sourcing — track top-ranked daily launches to surface early-stage products before they’re widely known.
• Content and newsletters — a clean daily feed of ranked launches powers “top products this week” roundups.

Build it yourself vs. a managed actor

Grabbing one day’s leaderboard is straightforward — parse the hydrated JSON, done. The work piles up at scale: the Next.js data payload changes structure when PH ships front-end updates, vote counts need a defined refresh policy so live and settled days don’t conflict, and walking a long historical range while staying polite to the CDN takes orchestration. A managed Product Hunt API alternative handles the calendar walk, the refresh logic, and the payload-shape drift so you just consume rows.

Common pitfalls

• Treating live votes as final. During the launch day, votes climb; only the settled count (next day onward) is stable. Define when you “freeze” a row.
• Payload-shape brittleness. The hydrated JSON is undocumented and reorganized periodically. Parse defensively.
• Timezone confusion. PH days run on a specific timezone (Pacific). A launch you’d call “today” may sit on yesterday’s leaderboard depending on your clock.
• Duplicate products. Relaunches and similarly named products exist; key on slug + date, not name.
• Over-fetching history. Past days are immutable — re-scraping them wastes requests and risks throttling for no new data.

Wrapping up

Product Hunt’s GraphQL API is genuinely good but built for integrations: OAuth setup plus a complexity budget that throttles exactly the daily-leaderboard backfill most people actually want. The public leaderboard renders the same launch data unauthenticated, with the date itself as a clean, resumable pagination key — which makes it a strong Product Hunt API alternative for daily launch data at scale. If you’d rather not track the hydrated-payload changes or manage the refresh policy, a managed actor returns it normalized.

▶ Open the Product Hunt Daily Launches Scraper on Apify — ranked daily launches with votes, makers, topics, and links straight from the public leaderboard. Pay per launch.