Product Hunt API The Complete Integration Guide

You’re probably here for one of three reasons. You want a launch-day dashboard that updates faster than the Product Hunt website. You need a clean way to pull post data into your own app. Or you started with the docs, got a token, made one request, and then hit the usual friction: GraphQL shape mismatches, missing fields, and rate limits that don’t feel obvious until your script starts failing.

The product hunt api is good, but it isn’t effortless. It rewards developers who keep queries tight, cache aggressively, and build around the parts of the schema that are stable. It punishes anyone who assumes the API will expose every field the public site appears to show.

Unlocking Product Hunt with the API

A common maker workflow looks like this. You launch, open Product Hunt in one tab, your analytics in another, and a notes doc in a third. Then you start manually checking rank, comments, topic placement, and competitor movement.

That works for a few hours. It doesn’t scale if you want alerts, historical comparisons, or a reusable internal dashboard.

The product hunt api gives you a better path because it turns Product Hunt from a website you watch into a dataset you can query. Product Hunt’s API history is also deep enough to matter. As of August 8, 2017, analysis of the API found 32,657 projects launched on the Home feed since November 24, 2013, which is why developers have used it to study launch timing, engagement, and ranking behavior across a large historical set, according to this Product Hunt API dataset analysis.

That matters if you’re building anything beyond a toy script.

What the API is actually useful for

The strongest uses are practical:

Launch tracking: Pull posts, votes, comments, and related entities into a dashboard you control.

Competitive monitoring: Watch new launches in your category and compare positioning.

Discovery tooling: Build niche feeds around topics, keywords, or maker activity.

Workflow automation: Trigger Slack messages, email digests, or internal alerts when a target product appears.

I’ve found the biggest shift isn’t technical. It’s strategic. Once you query Product Hunt directly, you stop reacting to the homepage and start modeling how visibility functions.

Why makers care about this data

Most launches don’t get equal attention. A small set of products gets most of the discussion, screenshots, shares, and downstream traffic. If you’re building tooling around launch prep, that’s where API access becomes a practical advantage.

The same applies if you also integrate keyword data programmatically into your research stack. Product Hunt data tells you what people are discovering. Keyword data tells you what they’re already searching for. Together, those signals are much more useful than either one alone.

Authentication and Your First API Request

The fastest way to get moving is to ignore advanced scopes and get a read-only token working first. Most integrations only need that.

Start with the right mental model

Product Hunt API V2 is a GraphQL interface. It supports three OAuth scopes: public, private, and write. In practice, public is the right default for most launch tracking, discovery, and analytics work, while private and write are for user-specific features and actions. The older ecosystem also has a known gotcha: around February 24-25th in a post-2017 change, fields such as usernames and Twitter handles were redacted, which broke integrations that assumed those fields would always be available, as noted in the official Product Hunt API repository.

If you’re building a read-only app, keep it simple.

Create an application in the Product Hunt API dashboard.

Store your client_id and client_secret on the server side.

Request a token using the client credentials flow.

Send GraphQL queries with a Bearer token.

If you want a reference point for how teams document similar flows in production, a concise example is often easier to work from than scattered snippets. A clean pattern is to keep your own API docs reference style equally minimal: auth first, first request second, edge cases later.

Get an access token

Use curl first. It removes a lot of uncertainty.


curl -X POST https://api.producthunt.com/v2/oauth/token \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "YOUR_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET",
    "grant_type": "client_credentials"
  }'

Store the returned access token securely. Don’t drop it into frontend code.

Make your first GraphQL request

A small query is the best sanity check:


curl -X POST https://api.producthunt.com/v2/api/graphql \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "query { posts(first: 1) { edges { node { id name tagline votesCount commentsCount } } } }"
  }'

A typical response shape looks like this:


{
  "data": {
    "posts": {
      "edges": [
        {
          "node": {
            "id": "POST_ID",
            "name": "Product Name",
            "tagline": "Short description",
            "votesCount": "VALUE",
            "commentsCount": "VALUE"
          }
        }
      ]
    }
  }
}

Avoid copying the response shape exactly into app code. GraphQL responses often change depending on the specific fields you request, and most bugs early on come from assuming a flatter payload than you queried.

Understanding the GraphQL Schema and Core Objects

Once authentication works, the next mistake is querying blind. Developers who struggle with the product hunt api usually don’t have an auth problem. They have a schema problem.

Product Hunt API 2.0 is a GraphQL-based interface available only at https://api.producthunt.com/v2/api/graphql, and it uses OAuth 2.0 with token acquisition through /v2/oauth/token, as described in the Product Hunt API 2.0 docs.

Think in objects, not endpoints

REST habits get in the way here. You’re not choosing from a list of fixed endpoints. You’re composing a graph of related objects.

The core objects of common interest are:

Object	What it represents	Commonly useful fields
Post	A launched product entry	`id`, `name`, `tagline`, `votesCount`, `commentsCount`
User	A member, maker, or participant	profile and relationship fields exposed by the current schema
Topic	A category or subject grouping	name and related posts
Collection	Curated sets of products	title, contents, metadata
Media	Visual assets tied to a post	image or video related fields

If you only remember one thing, remember this: Post is the center of most useful applications. Everything else usually hangs off it.

How to inspect the schema without guessing

Use the GraphQL explorer and introspection tools before writing a lot of code. Product Hunt’s schema is easier to understand interactively than by reading snippets out of context.

A good workflow looks like this:

Start with posts and ask for the smallest useful field set.

Add nested objects slowly so you can see where complexity rises.

Check nullability before assuming a field will always exist.

Rename carefully in app code because GraphQL field names are part of your contract.

Here’s a minimal query that keeps the model clear:


query {
  posts(first: 5) {
    edges {
      node {
        id
        name
        tagline
        votesCount
        commentsCount
      }
    }
  }
}

The fields that usually matter first

In practice, most launch dashboards want some variation of these:

Identity fields: id, name, tagline

Engagement fields: votesCount, commentsCount

Classification fields: topics or related category data where available

Presentation fields: thumbnail or media assets for cards and feeds

What doesn’t work well is requesting everything because it feels future-proof. It’s the opposite. Large nested queries make debugging harder, consume more complexity, and increase the chance that one nullable field breaks your assumptions.

A Deep Dive into Post and Launch Endpoints

Most useful product hunt api work starts with posts. If you can fetch, filter, and inspect posts cleanly, you can build dashboards, alerts, and launch monitoring without much else.

Fetch recent launches

A basic pattern is to request a small page of posts and the fields needed for your UI:


query {
  posts(first: 10) {
    edges {
      cursor
      node {
        id
        name
        tagline
        votesCount
        commentsCount
      }
    }
    pageInfo {
      hasNextPage
      endCursor
    }
  }
}

A sample response shape:


{
  "data": {
    "posts": {
      "edges": [
        {
          "cursor": "CURSOR_VALUE",
          "node": {
            "id": "POST_ID",
            "name": "Product Name",
            "tagline": "Short description",
            "votesCount": "VALUE",
            "commentsCount": "VALUE"
          }
        }
      ],
      "pageInfo": {
        "hasNextPage": true,
        "endCursor": "NEXT_CURSOR"
      }
    }
  }
}

That’s enough for a homepage-style feed, a Slack digest, or a “watch today’s launches” script.

Fetch a single post in detail

For a product detail page or richer launch tracker, query one post and ask for comments or related nested data only when needed.


query GetPost($id: ID!) {
  post(id: $id) {
    id
    name
    tagline
    votesCount
    commentsCount
  }
}

Use variables instead of string interpolation. It’s cleaner and safer in production.

Good filters versus bad filters

What works well:

ordering by engagement for leaderboard-style views

narrowing by time windows

filtering around topics when your app is category-specific

keyword-driven search for watchlists

What usually works poorly:

building huge all-purpose queries that try to power every screen

pulling comments, media, and related entities in the same request when only one panel needs them

polling too frequently instead of caching snapshots

A better launch monitor often uses two query shapes, not one. One lightweight query updates rank-like feed data. Another heavier query runs less often for detail views.

A practical pattern for daily launch dashboards

For a dashboard, I’d separate work into three jobs:

Feed sync job for recent posts.

Detail enrichment job for products you care about.

Change detection job that compares snapshots and triggers alerts.

That split keeps your app responsive and makes failures easier to isolate. If the enrichment step breaks, the main feed still works.

Querying Users Topics and Collections

Posts get most of the attention, but the product hunt api becomes more useful when you connect posts to surrounding context.

Users

User queries are useful when you’re trying to understand who launched something, who’s active in a niche, or which profiles repeatedly appear around products you track.

A typical user-oriented query asks for a profile plus related post activity:


query {
  user(id: "USER_ID") {
    id
    name
  }
}

Keep expectations conservative here. Some fields developers used to rely on aren’t exposed the same way anymore, and profile-oriented integrations are where schema assumptions break fastest.

Topics

Topics are the cleanest way to organize Product Hunt data into focused slices. If you’re building a niche feed for AI, developer tools, productivity, or design, topics are usually better than broad keyword matching alone.

A topic query often looks like a parent object plus its related posts. That gives you a way to build category pages, internal competitor watchlists, or simple alerting around new launches in a specific area.

Collections

Collections are useful when you want editorial grouping instead of raw chronology. They can power a curated browser, internal inspiration boards, or saved market maps.

Here’s a simple way to think about the three secondary objects:

Object	Best use	Common mistake
User	profile context and maker activity	assuming old public profile fields still exist
Topic	filtering and niche discovery	treating keywords as a complete substitute
Collection	curated grouping	expecting them to behave like real-time feeds

For most apps, topics are the second thing to model after posts. Users and collections become valuable once you have a clearer product need.

Practical API Use Cases for Indie Makers

The best product hunt api projects aren’t giant platforms. They’re small tools that remove repeated manual work.

Build a launch-day watch panel

This is the first thing most founders should build. Pull a tight list of recent posts, store snapshots, and show vote and comment movement over time.

You only need a lightweight posts query plus persistence. The important part isn’t fancy visualization. It’s having your own timeline instead of repeatedly refreshing the site.

Create a category monitor

If your product competes in a narrow segment, build a watcher around topics and keywords. Every time a related launch appears, send yourself a digest or add it to an internal board.

This works well for solo founders because it turns Product Hunt into a low-maintenance competitive research feed. If you’re planning your own release, pairing that with a structured product launch checklist keeps the research from turning into random browsing.

Build a comments and engagement tracker

A lot of launch momentum shows up in discussion quality, not just vote totals. A useful maker tool stores comment counts over time and flags products with unusual discussion activity so you can inspect them manually.

That helps answer questions like:

Which launches are attracting conversation, not just clicks

Which competitor posts deserve a closer read

Which products are worth bookmarking for later outreach or partnership ideas

Make a private discovery feed

This is my favorite small project because it stays useful long after launch week. Query posts, topics, and media, then rank or tag results based on your own criteria.

Examples include:

a “new dev tools only” feed

a “products mentioning a workflow I care about” feed

a “competitors launched this month” review queue

The API is strong when you use it to build your own operating surface. It’s weaker if you expect it to hand you strategy by default.

Handling Rate Limits and Performance

Most developers think rate limiting is a request-count problem. With the product hunt api, that mindset breaks early.

The harder limit is often query complexity, not just how many times you hit the server. A commonly cited pain point is the GraphQL complexity-based rate limit of 6250 points per 15 minutes, and analysis referenced alongside the rate limit docs notes that full product-detail queries can cost around 150-300 points, which means you can burn through quota in under 30 requests if you aren’t careful, according to the Product Hunt rate limit headers documentation.

What works in production

If you’re seeing intermittent slowdowns or 429 responses, the fix usually isn’t “retry harder.”

Use these patterns instead:

Trim fields aggressively: If a screen only needs name, tagline, and votesCount, don’t ask for media, nested relationships, and comment trees.

Split heavy and light queries: One query shape for frequent polling, another for occasional enrichment.

Cache everything reasonable: Recent posts, topic lists, and post detail snapshots should almost never require raw repeat queries on every page load.

Watch rate limit headers: Your app should inspect remaining quota and adapt before failure.

Back off with intent: Exponential backoff beats immediate retries every time.

A simple decision table

Situation	Better move	Bad move
Feed refresh	small query, frequent cache refresh	giant detail query every cycle
Detail page open	fetch enrichment on demand	preload every post in full
Rate budget dropping	slow polling and reuse cache	keep the same interval and hope
Repeated 429s	backoff and lower query cost	launch more parallel workers

Practical implementation habits

A few habits pay off immediately:

Store normalized snapshots instead of raw blobs when possible.

Separate user-facing freshness from backend collection frequency.

Log query names, field sets, and failure types.

Keep one intentionally cheap fallback query for degraded mode.

That last one matters. When your heavier requests hit complexity pressure, a minimal posts query can keep your app functioning while you defer enrichment.

SDKs and Community Tools to Accelerate Development

The product hunt api doesn’t require an SDK, but a good wrapper can save time if it doesn’t hide too much.

Node versus Python

Node.js wrappers are useful when you want typed helpers and a smoother fit with frontend-adjacent tooling. They’re a good choice for dashboards, internal admin tools, and serverless workers that already live in a JavaScript stack.

Python wrappers tend to be more comfortable for scripts, data pulls, and research-heavy workflows. If you’re prototyping a report, a monitoring job, or a notebook-based analysis, Python usually gets you there faster.

What to choose

A quick comparison:

Option	Best for	Trade-off
Raw HTTP client	full control	more boilerplate
Node SDK or wrapper	typed app development	wrapper quality varies
Python wrapper	scripts and analysis	may lag schema changes
Postman or Insomnia	testing queries manually	not ideal for production logic

The safest pattern is to start with raw requests, then add a wrapper if it reduces repetition without hiding query shape.

If you’re building for developers, it also helps to look at how similar tools are categorized and presented in launch ecosystems. Browsing a focused developer tools collection can clarify what metadata and filters matter most in a real product directory.

Troubleshooting Common API Errors and Quirks

Most failures with the product hunt api are ordinary once you know what to look for.

Token request fails

If you get an authentication error during token generation, check the basics first. The usual causes are wrong client credentials, malformed JSON, or sending the wrong grant type.

Fix it by reproducing the token call with curl before touching app code again. If curl fails, your app won’t magically fix it.

Fields come back null

This surprises people who expect the public site and API to expose the same profile data. They don’t always line up.

When fields return null, don’t patch around it with assumptions. Update your model so missing data is a first-class case, especially for user-related fields.

Pagination stops early

Cursor pagination breaks when developers reuse an old cursor, ignore pageInfo, or mix different query shapes while paginating.

Use one stable query shape per paginated job and store the cursor tied to that exact shape. If you change fields or filters, reset the pagination run.

Empty data with no obvious error

That usually means one of three things:

Your filter is too restrictive

Your token scope doesn’t match what you expect

Your query is valid GraphQL but doesn’t match the schema branch you intended

Print the full response, including GraphQL errors. Don’t just inspect data.

Product Hunt API Alternatives for Discovery Data

Sometimes the product hunt api is exactly what you need. Sometimes it isn’t.

If your goal is Product Hunt-native launch tracking, official API access is the cleanest option because it gives you structured data, predictable authentication, and a schema built for the platform’s own entities.

If your goal is broader discovery intelligence, you may need more than one source:

Other product discovery platforms if you want coverage beyond Product Hunt

Search data APIs if you care about demand patterns as much as discovery

Internal enrichment pipelines if you need to combine launch data with CRM, analytics, or editorial review

Web scraping only when there’s no supported API path and you’re willing to accept fragility

Scraping can fill gaps, but it breaks more often, demands more maintenance, and creates more legal and operational questions. The right sequence for a development project is simple: use the official API first, enrich with adjacent sources second, and scrape only as a last resort.

If you’re launching soon and want distribution beyond a single platform, Saaspa.ge is built for that exact problem. It helps founders get visibility through curated product discovery, launch placements, leaderboards, and practical launch resources that are easier to use than stitching the whole process together by hand.