> ## Documentation Index
> Fetch the complete documentation index at: https://concentrate.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Bring Your Own Key (BYOK)
> Store your own provider API keys and have Concentrate route requests through them — with no rate limits, no credit spend, and automatic fallback to managed credentials.
## Overview
By default, Concentrate owns the upstream provider credentials — you point at a model and never touch a provider key. With BYOK, you can optionally store your own provider API keys (OpenAI, Anthropic, AWS Bedrock, Google Vertex, Azure, and more), and requests routed to those providers run on your keys instead.
When a request is served on one of your keys:
* **No Concentrate rate limits** — only your provider's own limits apply
* **No credit spend** — the provider bills you directly, so nothing is debited from your Concentrate balance
* **Full observability** — usage is still tracked per request and rolled up in the dashboard, flagged as BYOK
BYOK is configured in the dashboard, not per request. Store a key once and every request that routes to that provider uses it automatically — no request-body or header changes.
## Configure in Dashboard
1. Go to **BYOK** in the dashboard
2. Pick a provider and click **Add key**
3. Enter the credential and a name label, then save
Keys are owned by the active scope: add a key while viewing your personal account and it applies to your personal API keys; add it while viewing an organization and it applies org-wide. Org BYOK keys can only be managed by organization owners.
Credentials are write-only. They are encrypted at rest, and after saving only a redacted preview (public prefix + last four characters) is ever shown again. Editing a key's name does not require re-entering the secret.
## Supported Providers
Every serving provider on Concentrate accepts a BYOK key. Most take a single API key string — paste the key you generated in the provider's console and you're done. Three providers need richer credentials:
### Azure
Azure keys are scoped to a resource, so along with the API key you provide:
| Field | Description |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **API key** | The key from your Azure resource's **Keys and Endpoint** page |
| **Resource name** | The name of your Azure resource — the `my-resource` part of `https://my-resource.openai.azure.com`. Just the name, not the full URL |
| **Resource type** | `openai` for an Azure OpenAI resource, or `ai_foundry` for an Azure AI Foundry resource |
Requests are sent to the endpoint derived from the resource name, so the resource must have access to the models you want to use. Per-deployment credentials (a full deployment `endpoint_url` + model ID) are not yet supported.
### Google Vertex AI
Vertex authenticates with a GCP service account rather than an API key. Paste the **service account JSON file exactly as downloaded** from Google Cloud (IAM & Admin → Service Accounts → Keys → Create new key → JSON):
```json theme={null}
{
"type": "service_account",
"project_id": "your-project-id",
"private_key_id": "...",
"private_key": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n",
"client_email": "your-service-account@your-project.iam.gserviceaccount.com",
"client_id": "...",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "..."
}
```
The service account needs permission to call Vertex AI in the project (the **Vertex AI User** role). You can optionally add a `"region"` field to the JSON (e.g. `"us-central1"` or `"global"`) to pin which Vertex region requests are sent to.
### AWS Bedrock
Bedrock accepts either of two credential types:
* **Bedrock API key** — a bearer token generated in the Bedrock console, plus an optional region. Bedrock API keys only work in the AWS region they were created in; requests default to `us-east-1`, so set the region if your key was created elsewhere.
* **AWS credentials** — an IAM access key pair plus an explicit region. Each request is SigV4-signed with them:
| Field | Description |
| --------------------- | ---------------------------------------------------- |
| **Access key ID** | The IAM access key ID (e.g. `AKIA...`) |
| **Secret access key** | The matching IAM secret |
| **Region** | The AWS region to call Bedrock in (e.g. `us-east-1`) |
The IAM identity needs the `bedrock:InvokeModel` and `bedrock:InvokeModelWithResponseStream` permissions — plus model access enabled in the Bedrock console, in the chosen region.
## How BYOK Affects Routing
Routing checks which providers you hold keys for on every request:
* **Provider preference** — among otherwise-equal candidate providers for a model, providers you hold a BYOK key for are tried first.
* **Per-key attempts** — for a BYOK provider, routing attempts the request on each of your stored keys for that provider before anything else.
* **Automatic fallback** — if every one of your keys fails (invalid key, provider error, exhausted quota on your account), the request falls back to Concentrate's own managed credentials for that provider, then to the next provider in the fallback chain. A bad BYOK key never fails the request on its own.
```
Request → provider resolved
→ your BYOK key(s) for that provider, in order
→ Concentrate's managed key for that provider
→ next provider in the fallback chain
```
Attempts on your keys skip the rate limit and balance check; the managed-key fallback goes through both as normal.
## Billing and Usage
BYOK-served requests are not debited from your Concentrate credit balance — token costs are settled directly between you and the provider. Usage is still recorded:
* The per-key usage breakdown in the billing dashboard attributes BYOK traffic to the specific stored key that served it
* Request logs and token counts are captured exactly as for managed-key requests
Every response reports whether it was served on your key via the `byok` field of the `cost` object:
```json theme={null}
{
"cost": {
"total": 0,
"byok": true,
"breakdown": { ... }
}
}
```
## Related Documentation
How providers are selected and how fallback chains work
Key-level data retention controls
Enumerate the provider slugs you can store keys for
Understand provider errors and fallback behavior