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:Creating a key
Open API Keys in the dashboard, create a key, and give it a name that says where it’s used (for exampleprod-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.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, 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.code is useless without your API key.

