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

# Bring Your Own Keys

> Use your own API keys from OpenAI, Anthropic, Google, Mistral, xAI, and Meta with Verlon AI

## Overview

By default, requests through Verlon use Verlon's platform keys. With BYOK (Bring Your Own Keys), you can provide your own provider API keys. Requests are then billed directly to your provider account.

<Note>
  BYOK is *your keys, our catalog* — your provider account serving the public
  models Verlon already knows about. To register a model of your own that the
  catalog has never heard of — a fine-tune, or your own inference server — see
  [Bring Your Own Models](/platform/owned-models).
</Note>

**Why use BYOK?**

* **Bypass platform rate limits** — Use your own quota
* **Direct billing** — Charges appear on your provider account
* **Compliance** — Some organizations require direct provider relationships
* **Control** — Maintain your own API key lifecycle

## Supported Providers

| Provider      | Key Format    | Validation Method             |
| ------------- | ------------- | ----------------------------- |
| **OpenAI**    | `sk-proj-...` | Lists models (free operation) |
| **Anthropic** | `sk-ant-...`  | Minimal message request       |
| **Google**    | `AIza...`     | Minimal content generation    |
| **Mistral**   | API key       | Lists models (free operation) |
| **xAI**       | `xai-...`     | Lists models (free operation) |
| **Meta**      | API key       | Lists models (free operation) |

## Adding a Provider Key

### From the Dashboard

1. Go to **Dashboard → Provider Keys**
2. Find the provider you want to configure and click **Add key**
3. Give the key a label (e.g. `default`, `rotation-2026q3`) and paste the credential
4. The key is validated against the provider before it saves — a bad key never lands

Your key is encrypted immediately using AES-256-GCM and stored securely. Only a masked prefix is visible in the dashboard (e.g., `sk-proj-...abc123`).

### Key Management

* **Multiple keys per provider** — Each key has a unique label; exactly one is the **default**
* **Default key** — Serves all your traffic for that provider unless a gate pins a specific key
* **Gate pinning** — A gate's Model & routing settings can pin it to a specific key; pinned gates keep their key through default rotations
* **Enable/Disable** — Toggle a key without deleting it
* **Test** — Re-validate any stored key against the provider at any time
* **Per-key usage** — Rolling request/error counts per key, from per-request attribution
* **Activity trail** — Every add, rename, default change, toggle, and delete is recorded and shown on the page
* **Delete** — Soft-deleted (recoverable for 90 days, then permanently removed). The default key can't be deleted while sibling keys exist — hand the default over first

### Zero-Downtime Rotation

To rotate a credential without dropping a request:

1. **Add** the new key under a fresh label
2. **Make it the default** — unpinned traffic switches on the next request
3. **Watch the old key's usage drain** to zero in the per-key usage column
4. **Delete** the old key here and **revoke** it in your provider's console

Gates pinned to the old key keep working until you unpin them; a pin whose key is deleted or disabled falls back to the default automatically, so rotation can never break a gate.

## How Keys Are Used

When you make a request through Verlon:

1. If the gate is **pinned** to one of your keys (and that key is active and matches the serving provider) → the pinned key is used
2. Otherwise, if you have an active **default** BYOK key for the target provider → it is used
3. Otherwise → Verlon's platform key is used as a fallback

This happens transparently. Your application code doesn't change regardless of whether BYOK is configured.

## Security

### Encryption

All provider keys are encrypted using **AES-256-GCM** — the same standard used by AWS KMS, Google Cloud KMS, and 1Password.

* **Fresh IV** generated for every encryption operation
* **Auth tag** detects any tampering with stored data
* **Master key** stored separately from the database as an environment variable

### What Verlon Stores

| Data          | Storage                                         |
| ------------- | ----------------------------------------------- |
| Full API key  | Encrypted (AES-256-GCM)                         |
| Key prefix    | Plaintext (for display, e.g., `sk-proj-...abc`) |
| Provider name | Plaintext                                       |
| Active status | Plaintext                                       |

### Trust Model

Verlon's BYOK uses platform-controlled encryption, which is the industry standard for API proxies. Your keys are encrypted at rest but decrypted server-side when making provider API calls on your behalf — the same model used by Stripe, Vercel, and similar platforms.

## Cost Tracking

When BYOK is active, the actual provider charges appear on your provider account. Verlon still tracks estimated costs in the dashboard for analytics and spending limit enforcement, but these are calculated from token counts and published pricing — your actual provider bill may vary slightly.

## Fallback Behavior

If your BYOK key becomes invalid (expired, revoked, rate-limited):

* Verlon detects the authentication error
* The key is marked as invalid in the dashboard
* Requests fall back to Verlon's platform key (if available)
* You're notified to update your key