Authentication overview

The Product Hunt API provides programmatic access to its platform's data, including product listings, comments, and user profiles. To interact with the API, applications must authenticate to establish their identity and obtain authorization to access specific resources. Product Hunt employs the OAuth 2.0 authorization framework as its primary method for securing API access. This standard protocol allows third-party applications to obtain limited access to a user's Product Hunt account without exposing the user's password to the application. OAuth 2.0 facilitates secure delegated access, where a user grants permission for an application to act on their behalf.

The API itself is built on GraphQL, offering developers flexible data querying capabilities. Authentication is a prerequisite for making any calls to the GraphQL endpoint, ensuring that requests are authorized and rate limits can be properly applied. Understanding the OAuth 2.0 flow is essential for integrating with the Product Hunt API effectively.

Supported authentication methods

Product Hunt exclusively supports OAuth 2.0 for API authentication. OAuth 2.0 is an industry-standard protocol for authorization that separates the roles of the resource owner (the user), the client (your application), and the authorization server (Product Hunt). This separation enhances security by ensuring that your application never directly handles user credentials.

The typical OAuth 2.0 flow for web applications or applications with a backend involves several steps:

  1. Authorization Request: Your application redirects the user's browser to Product Hunt's authorization server, requesting specific permissions (scopes).
  2. User Consent: The user is prompted to log in to Product Hunt (if not already logged in) and grant or deny the requested permissions to your application.
  3. Authorization Grant: If the user grants permission, Product Hunt redirects the user's browser back to a pre-registered redirect URI on your application, including an authorization code.
  4. Access Token Request: Your application exchanges this authorization code for an access token by making a server-to-server request to Product Hunt's token endpoint. This request includes your application's client ID and client secret.
  5. Resource Access: Your application uses the obtained access token to make authenticated requests to the Product Hunt GraphQL API.

For more details on the general OAuth 2.0 specification, refer to the OAuth 2.0 community site.

Authentication Methods Table

Method When to Use Security Level
OAuth 2.0 (Authorization Code Grant) Server-side web applications, mobile apps, or any client capable of securely storing a client secret and making server-side requests. High: Client secret is kept confidential, access tokens are short-lived.
OAuth 2.0 (Implicit Grant) Single-page applications (SPAs) where a client secret cannot be securely stored. Access tokens are returned directly to the browser. Moderate: Less secure than Authorization Code Grant due to token exposure in browser history/logs, not recommended if Authorization Code with PKCE is an option.

Product Hunt's API documentation primarily focuses on the Authorization Code Grant flow, which is suitable for most robust integrations, as detailed in the Product Hunt API documentation.

Getting your credentials

To begin authenticating with the Product Hunt API, you need to register your application to obtain a Client ID and Client Secret. These credentials uniquely identify your application to Product Hunt's authorization server. The registration process typically involves:

  1. Accessing Developer Settings: Log in to your Product Hunt account and navigate to your developer or API settings, usually found under your profile or a dedicated developer portal.
  2. Registering a New Application: Provide essential details about your application, such as its name, description, and importantly, the redirect URIs. Redirect URIs are the URLs where Product Hunt will send the user back after they authorize your application. These must be exact matches to what you register.
  3. Receiving Credentials: Upon successful registration, Product Hunt will issue a Client ID (a public identifier for your application) and a Client Secret (a confidential key that should be kept secure).

The Client ID is used in the initial authorization request to identify your application to the user. The Client Secret is used in server-to-server communications to exchange an authorization code for an access token, proving your application's identity securely. Product Hunt provides specific instructions for managing your applications and credentials within their help documentation.

It is crucial to store your Client Secret securely and never expose it in client-side code (e.g., JavaScript in a browser). If your Client Secret is compromised, revoke it immediately through your Product Hunt developer settings and generate a new one.

Authenticated request example

Once you have obtained an access token using the OAuth 2.0 flow, you can use it to make authenticated requests to the Product Hunt GraphQL API. The access token is typically included in the Authorization header of your HTTP requests, using the Bearer scheme.

Here's a conceptual example using curl to make an authenticated GraphQL query. This example assumes you have an ACCESS_TOKEN variable holding your valid token.

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

In this example:

  • -X POST specifies the HTTP method.
  • https://api.producthunt.com/v2/api/graphql is the GraphQL API endpoint.
  • -H "Authorization: Bearer YOUR_ACCESS_TOKEN" is the crucial header containing your access token. Replace YOUR_ACCESS_TOKEN with the actual token you received.
  • -d '{ "query": "..." }' contains the GraphQL query payload. This example fetches the ID and name of the first post.

For more detailed examples and available GraphQL queries and mutations, refer to the Product Hunt API reference documentation. When integrating with SDKs like Ruby, Node.js, or Python, the SDKs will typically abstract away the direct HTTP request details, allowing you to pass the access token to the client library for automatic inclusion in requests.

Security best practices

Implementing strong security practices is critical when working with any API, especially one that handles user data. For Product Hunt API integrations, consider the following:

  • Secure Client Secret Storage: Your Client Secret is a sensitive credential. Never hardcode it directly into your application's source code, especially for client-side applications. For server-side applications, store it in environment variables or a secure configuration management system, not directly in version control.
  • Protect Access Tokens: Access tokens grant temporary access to user data. Treat them as sensitive as passwords. Avoid storing them in local storage or cookies in client-side applications if possible. If client-side storage is necessary, use secure HTTP-only cookies or encrypted local storage. Always transmit tokens over HTTPS.
  • Use HTTPS Everywhere: Ensure all communication with the Product Hunt API and your application's endpoints (especially redirect URIs) uses HTTPS. This encrypts data in transit, preventing eavesdropping and tampering. The IETF RFC 7230 on HTTP/1.1 messaging mandates secure transport for sensitive data.
  • Validate Redirect URIs: Always register specific, fully qualified redirect URIs with Product Hunt. Never use wildcard URIs. This prevents malicious actors from redirecting authorization codes to their own servers.
  • Implement State Parameter: When initiating the OAuth 2.0 flow, include a unique, unguessable state parameter in your authorization request. This parameter should be persisted by your application and verified upon receiving the authorization code. The state parameter helps mitigate Cross-Site Request Forgery (CSRF) attacks.
  • Handle Token Expiration and Refresh: Access tokens have a limited lifespan. Design your application to gracefully handle token expiration. Implement logic to use refresh tokens (if provided by Product Hunt) to obtain new access tokens without requiring the user to re-authenticate.
  • Least Privilege Principle: Request only the minimum necessary scopes (permissions) from the user. For example, if your application only needs to read public product data, do not request permissions to post comments or access private user information.
  • Error Handling and Logging: Implement robust error handling for API requests and authentication failures. Log relevant information for debugging, but be careful not to log sensitive data like access tokens or client secrets.
  • Regular Security Audits: Periodically review your application's security practices and code for vulnerabilities. Stay informed about common web security threats and best practices.