> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rocketpunch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OAuth 2.0 for the Rocketpunch API: Integration Guide

> Use OAuth 2.0 to request user consent and access Rocketpunch profile data on behalf of your users. Register a redirect URI to get started.

The Rocketpunch API supports two authentication models: App Key authentication for server-side access to public platform data, and OAuth 2.0 for accessing data on behalf of a specific Rocketpunch user. Choose the right model based on what your application needs to do — most integrations start with App Key auth and add OAuth only when user-specific features are required.

## When to Use OAuth

Both authentication methods use the same underlying API, but they serve different purposes. Pick the one that matches your use case.

| Use Case                                      | Method    |
| --------------------------------------------- | --------- |
| Search job listings on your platform          | App Key   |
| Display company profiles in your app          | App Key   |
| Browse public networking events               | App Key   |
| Access a signed-in user's Rocketpunch profile | OAuth 2.0 |
| Read a user's saved jobs or preferences       | OAuth 2.0 |
| Act on behalf of a user within Rocketpunch    | OAuth 2.0 |

**App Key authentication** is the right choice when your server makes calls to public Rocketpunch data — jobs, companies, and events — without needing to identify or act as a specific user. You include your `X-RP-API-Key` header on every request, and the response reflects publicly available platform data.

**OAuth 2.0** is the right choice when your application needs a Rocketpunch user to grant you permission to read or interact with their personal data. The user logs in to Rocketpunch, reviews what your app is requesting, and approves access. You receive a token scoped to that user, which you then use for subsequent API calls.

<Note>
  If you only need public data — job listings, company profiles, or events — you do not need OAuth. Set up [App Key authentication](/api/authentication) instead and skip the OAuth flow entirely.
</Note>

## OAuth 2.0 Authorization Code Flow

Rocketpunch implements the **OAuth 2.0 Authorization Code Flow**, the industry-standard approach for web and server-side applications. Here is a high-level overview of the steps:

1. **Redirect** — Your app redirects the user to Rocketpunch's authorization endpoint, including your `client_id`, requested scopes, and a `redirect_uri` where Rocketpunch will send the user back after consent.
2. **Consent** — The user sees Rocketpunch's login and permission screen. If they approve, Rocketpunch redirects them to your `redirect_uri` with a short-lived `code` parameter.
3. **Token exchange** — Your server sends a POST request to Rocketpunch's token endpoint, exchanging the `code` for an `access_token` (and optionally a `refresh_token`).
4. **API calls** — Your app includes the `access_token` in the `Authorization: Bearer` header for any user-specific API requests.

See the [Auth Flow guide](/api/oauth/flow) for the complete implementation with code examples.

## Setting Up OAuth

Before you can implement the flow, you need to register your application on the Rocketpunch developer portal.

<Steps>
  <Step title="Create your app">
    Go to [developers.rocketpunch.com/apps/new](https://developers.rocketpunch.com/apps/new) and fill in your application name and description. These details are shown to users on the consent screen.
  </Step>

  <Step title="Add your redirect URI">
    Enter the callback URL where Rocketpunch will redirect users after they grant (or deny) consent. This must exactly match the `redirect_uri` you use in your authorization requests — including protocol, domain, and path.

    ```
    https://yourapp.com/auth/rocketpunch/callback
    ```
  </Step>

  <Step title="Copy your credentials">
    After saving your app, the portal displays your **Client ID** and **Client Secret**. Store the Client Secret securely — treat it like a password. You will need both values when implementing the token exchange step.
  </Step>
</Steps>

<Warning>
  Your Client Secret must never appear in client-side code, mobile app binaries, or public repositories. Token exchange must always happen on your server.
</Warning>

## Scopes

Scopes define exactly what user data your application can access. When you redirect a user to the authorization endpoint, you include a `scope` parameter listing the permissions you need. The user sees these permissions on the consent screen before approving.

Request only the scopes your app genuinely needs — asking for unnecessary permissions reduces user trust and lowers approval rates. Available scopes are listed in the [Auth Flow guide](/api/oauth/flow).

## Next Steps

Now that you understand when and why to use OAuth, implement the full authorization flow in your application.

<Card title="Implement the Auth Flow" icon="arrow-right" href="/api/oauth/flow">
  Step-by-step guide to building the authorization code flow, including redirect URLs, token exchange, and making authenticated API calls.
</Card>