Bring Your Own Key (BYOK)

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

Go to BYOK in the dashboard
Pick a provider and click Add key
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):

{
  "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)

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:

{
  "cost": {
    "total": 0,
    "byok": true,
    "breakdown": { ... }
  }
}

Routing

How providers are selected and how fallback chains work

Zero Data Retention

Key-level data retention controls

List Providers

Enumerate the provider slugs you can store keys for

Error Handling

Understand provider errors and fallback behavior

API Documentation

Responses

Chat Completions (Beta)

Messages (Beta)

Models

Utilities

Features

Reference

Bring Your Own Key (BYOK)

Overview

Configure in Dashboard

Supported Providers

Azure

Google Vertex AI

AWS Bedrock

How BYOK Affects Routing

Billing and Usage

Routing

Zero Data Retention

List Providers

Error Handling

​Overview

​Configure in Dashboard

​Supported Providers

​Azure

​Google Vertex AI

​AWS Bedrock

​How BYOK Affects Routing

​Billing and Usage

​Related Documentation

Routing

Zero Data Retention

List Providers

Error Handling

Overview

Configure in Dashboard

Supported Providers

Azure

Google Vertex AI

AWS Bedrock

How BYOK Affects Routing

Billing and Usage

Related Documentation