---
title: "API Access Credentials · COUNT Partner API"
description: "How partner clientId and clientSecret credentials work, how to request them, and how to register redirect URIs. The secret signs requests and is never sent."
canonical: "https://developers.getcount.com/getting-started/credentials"
source: "https://developers.getcount.com/getting-started/credentials"
---
Getting Started

# API access credentials

Every partner app has a clientId and a clientSecret. The clientId identifies your app on each request; the clientSecret signs requests and is never sent over the wire.

## Requesting credentials

Partner credentials are issued per app. There are two ways to get a `clientId` and `clientSecret`:

### Option 1 — Create an app in COUNT Partners

Sign in to COUNT and open [COUNT Partners](https://app.getcount.com/count-partners). Under **Your apps**, create a new OAuth app to generate your `clientId` and `clientSecret` instantly. This is the fastest way to start building.

### Option 2 — Request a secret via the access request form

If you'd prefer the COUNT team to provision your credentials, submit the [COUNT API Access Request Form](https://docs.google.com/forms/d/e/1FAIpQLSe7AxXMSObX94XmEpF-Oxdbmsd6Gm0k9-0iccjVvA4s04pkMg/viewform) with your company details and use case. We'll issue your `clientSecret` and follow up with next steps.

Configure your redirect URL in COUNT Partners

However you get your credentials, you must add your redirect URL in [COUNT Partners](https://app.getcount.com/count-partners) before the OAuth flow will work. The authorization request is rejected if its `redirectUri` doesn't exactly match a configured URL.

Keep your secret safe

Treat the `clientSecret` like a password. Store it in a secret manager or environment variable — never commit it or expose it in client-side code.

## Redirect URIs

Configure the exact redirect URL your app uses in [COUNT Partners](https://app.getcount.com/count-partners). The OAuth flow starts by sending the user to the authorization endpoint:

Start authorization (workspace)

```bash
GET /auth2/authorize-intiate
  ?clientId=<your clientId>
  &redirectUri=<your registered redirect URI>
  &state=<opaque value you generate>
```

| Flow | Initiate route |
| --- | --- |
| Workspace partner OAuth | GET /auth2/authorize-intiate |
| Firm / practice OAuth | GET /auth2/firm/authorize-initiate |

Legacy spelling on workspace route

The workspace initiate path uses `authorize-intiate` (missing the second `i`). This is the canonical live route — use it exactly as shown. Firm OAuth uses the correctly spelled `authorize-initiate` under `/auth2/firm/`.

No query params on the redirect URI

The registered redirect URI must not contain query parameters. Use the `state` parameter to carry any context you need back through the flow.

## Required headers

Once you have credentials, every data request includes:

- `x-client-id` — your app's clientId.
- `x-timestamp` — Unix seconds used in the signature.
- `x-signature` — HMAC-SHA256 of the request base string.
- `Authorization: Bearer …` — the workspace access token.

See [Authentication & signing](https://developers.getcount.com/getting-started/authentication) for how to build the signature.