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

# API Keys & Client ID

> The two credentials you use with BundleUp: a secret API key for your backend, and a public client ID for the browser.

BundleUp gives each workspace two kinds of credential. They do different jobs and belong in different places.

| | API key | Client ID |
| - | - | - |
| **Secret?** | Yes | No, it’s safe in a URL |
| **Used by** | Your backend | The user’s browser |
| **Used for** | Every API call: Proxy, Unified API, MCP, Platform API, and the code exchange | Starting the authorization flow |
| **How many** | As many as you like per workspace | One per workspace |
| **Where to find it** | Dashboard → **API Keys** | Dashboard → **Auth** |

```mermaid theme={null}
flowchart LR
    subgraph Browser
        FE[Your frontend]
    end
    subgraph Server[Your servers]
        BE[Your backend]
    end
    FE -->|"client_id (public)"| AUTH["auth.bundleup.io/authorize"]
    BE -->|"API key (secret)"| CODE["auth.bundleup.io/connection"]
    BE -->|"API key (secret)"| PROXY["proxy. / unify. / mcp. / api.bundleup.io"]
```

The client ID travels through the browser to start the authorization flow. The API key only ever goes from your backend to BundleUp.

## API keys

An API key authorizes requests for **every connection in its workspace**. Treat it like a database password.

Send it as a bearer token:

```http theme={null}
Authorization: Bearer YOUR_API_KEY
```

### Creating a key

Open **API Keys** in the dashboard, create a key, and give it a name that says where it’s used (for example `prod-backend` or `sync-worker`). Copy it into your secrets manager or environment variables.

The full key is shown **only once**, when you create it. BundleUp stores only a hash of each key, so it can’t show you the key again later. If you lose one, rotate it or create a new one.

### Using more than one key

Create a key per service or deployment. Each request log shows which key made the call, and you can rotate or delete one key without touching the others.

### Rotating a key

Rotate a key from **API Keys** in the dashboard. Rotation issues a new secret for that key, shown once, and **the old secret stops working immediately**.

To rotate without downtime, create a second key first, deploy it, then delete or rotate the old one. Rotating in place is the right move when a key may have leaked and you want it dead now.

<Warning>
  Never put an API key in frontend code, a mobile app, or anything shipped to users. Anyone with the key can call every connected account in the workspace.
</Warning>

### Where keys can and can’t go

* **Your backend, workers and serverless functions:** yes.
* **Environment variables or a secrets manager:** yes.
* **Source control:** no.
* **Browser, mobile app, desktop app:** no.
* **AI model providers:** only when you use [model-hosted MCP](/docs/guides/mcp/clients#model-hosted-mcp), and only if you accept that the provider’s servers will see it.

## Client ID

The client ID identifies your workspace when a user starts connecting an account. It’s not a secret: it appears in the authorization URL the user’s browser visits.

```text theme={null}
https://auth.bundleup.io/authorize?client_id=YOUR_CLIENT_ID&integration_id=github&redirect_uri=...
```

The client ID on its own can’t do anything harmful. It can only start an authorization flow that redirects to a URI you’ve registered, and the resulting `code` is useless without your API key.

## Connection ID

Not a credential, but often confused with one. A connection ID picks **which account** a request acts on. It only works together with an API key from the same workspace. See [Connections](/docs/concepts/connections).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.