Authentication

Every request to /v1/* needs an API key. BUZZ accepts three header forms, so the official Anthropic, OpenAI, and Google GenAI SDKs all work without code changes — point the SDK at https://buzzai.cc and your existing auth setup keeps running.

Three accepted header forms

Pick whichever lines up with the SDK you already use. All four headers resolve to the same key lookup — there is no behavioral difference once authenticated.

Which header should I use?

Match the header to the SDK you are calling, so you do not need to monkey-patch its request layer.

Anthropic SDK

The official anthropic Python and @anthropic-ai/sdk Node packages send x-api-key by default. Just point them at BUZZ:

from anthropic import Anthropic

client = Anthropic(
    base_url="https://buzzai.cc",
    api_key="",
)

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  baseURL: "https://buzzai.cc",
  apiKey: process.env.BUZZ_API_KEY,
});

OpenAI SDK (against /v1/chat/completions)

The OpenAI SDK sends Authorization: Bearer ... by default. Use it against the OpenAI-compatible /v1/chat/completions path:

from openai import OpenAI

client = OpenAI(
    base_url="https://buzzai.cc/v1",
    api_key="",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": "ping"}],
)

Google GenAI SDK

The official google-genai SDK sends x-goog-api-key. BUZZ recognizes that header on its Gemini-compatible paths, so you can point the SDK at BUZZ and reuse a BUZZ key for Gemini-compatible models exposed by the gateway.

curl / custom HTTP client

For raw HTTP calls, Authorization: Bearer is the path of least resistance — it matches the rest of the BUZZ REST surface, including non-relay endpoints like billing.

curl -X POST https://buzzai.cc/v1/messages \
  -H "Authorization: Bearer $BUZZ_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{ "model": "claude-haiku-4-5-20251001", "max_tokens": 32, "messages": [{"role":"user","content":"ping"}] }'

SDK header cheatsheet

API key management

Keys are managed from the Tokens page in the dashboard. You can also drive the same operations programmatically via /api/token/* using a session or access token (separate from the sk- relay key).

Fields you can set per key

Status values

Lifecycle: create, retrieve, rotate, delete

Create

The dashboard form (or POST /api/token/) creates a key. The full key is generated server-side; the create response does not echo it. To retrieve the full key after creation, use the dashboard copy button or call POST /api/token/<id>/key. List endpoints only show a masked form like OnyH**********esAm.

Retrieve

Treat the full key as a one-time secret. Copy it once, store it in your secret manager or environment, and never paste it back into the dashboard or chat.

Rotate

To rotate, create a new key, deploy it everywhere your apps use the old one, then delete the old key. There is no in-place key regeneration; you delete and create.

Delete

Soft-delete is supported: DELETE /api/token/<id>. For batch removal, post an array of IDs to POST /api/token/batch with body {"ids":[1,2,3]}.

Security best practices

• Use environment variables, not hard-coded literals. Read the key from BUZZ_API_KEY (or whatever name your project uses) at startup. Never paste a key into source control, dashboards, screenshots, or chat tools.
• Add the key to .gitignore-tracked files only. Common safe locations: .env, secret managers (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault), CI/CD secret stores. Make sure .env is gitignored.
• Scope per project, not per organization. Create a separate key per service or environment (dev / staging / prod). It limits blast radius if one leaks and makes rotation cheap.
• Set an IP allow-list when you can. If your workload runs from known egress IPs (production servers, CI runners, NAT gateways), populate allow_ips. This converts a leaked key from "anyone with HTTP" to "anyone on those IPs".
• Use model_limits for high-risk keys. Restricting a key to claude-haiku-4-5-20251001 caps the per-call cost even if abused.
• Set an expiration. Keys for short-lived prototypes, demos, or contractor handoffs should have a hard expired_time. -1 is convenient but easy to forget.
• Rotate on a schedule. Long-lived production keys should rotate at least every 90 days, or immediately on any suspected exposure (CI log leak, accidentally pushed commit, departed team member).
• Watch usage for anomalies. Use GET /api/usage/token/ with the key itself as auth to read remaining quota and recent spend. Alert on unexpected spikes.
• If a key leaks, delete it first, investigate second. Soft-delete via the dashboard is immediate. Then create a replacement, redeploy, and only then audit logs to understand what happened.

Authentication errors

BUZZ-side errors use the envelope:

{
  "error": {
    "type": "buzz_error",
    "message": "Invalid token... (request id: 202605260713594...)"
  }
}

Anthropic-passthrough errors retain the official shape with request_id at the top level.

See also

• Quickstart — five-minute first call.
• POST /v1/messages — full request/response reference.
• GET /api/token/ — programmatic key management.
• Error handling — retry policies and the BUZZ-specific 503 case.