Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Verifieddanny/BurnGuard/llms.txt

Use this file to discover all available pages before exploring further.

BurnGuard uses path-prefix routing to decide which upstream AI provider to forward each request to. The first segment of the request path — /anthropic, /openai, and so on — must match a key in the providers map inside burnguard.yaml. BurnGuard strips that prefix, appends the rest of the path to the provider’s base_url, and forwards the request with all original headers intact. This means changing a single base URL in your application code is all that is needed to route traffic through BurnGuard.

​
How URL transformation works

Request to BurnGuardForwarded upstream
http://localhost:8080/anthropic/v1/messageshttps://api.anthropic.com/v1/messages
http://localhost:8080/openai/v1/chat/completionshttps://api.openai.com/v1/chat/completions
BurnGuard matches the leading path segment against the keys in your providers map, removes that segment, and concatenates what remains onto base_url. No additional path configuration is required.

​
Provider configuration in YAML

burnguard.yaml
providers:
  anthropic:
    base_url: https://api.anthropic.com
  openai:
    base_url: https://api.openai.com
Each key under providers is both the YAML identifier and the path prefix used in your application’s base URL. The value is a single base_url field pointing to the provider’s public API root.

​
Supported providers

ProviderKey in YAMLDefault base_urlPath prefix
Anthropic (Claude)anthropichttps://api.anthropic.com/anthropic/...
OpenAI (GPT)openaihttps://api.openai.com/openai/...
Google GeminiComing soon—/google/...
Google Gemini (google) appears in the example burnguard.yaml and is supported as a generic proxy target, but token parsing for Gemini responses is not yet implemented. The burnguard init wizard has Gemini commented out. If you add the google key manually, requests will be forwarded to generativelanguage.googleapis.com but token counts and costs will not be tracked. Use only anthropic and openai until Gemini support ships.

​
API key forwarding

BurnGuard forwards every request header to the upstream provider without modification. You do not configure API keys inside burnguard.yaml — your application passes them exactly as it always has:
  • Anthropic expects x-api-key: sk-ant-... in the request headers.
  • OpenAI expects Authorization: Bearer sk-... in the request headers.
BurnGuard passes both headers through transparently, so your existing authentication code needs no changes.

​
Application code examples

Update your application’s base URL to point at the BurnGuard proxy. Everything else — API keys, request bodies, streaming — stays the same. 
import anthropic

# Before: client = anthropic.Anthropic()
client = anthropic.Anthropic(
    base_url="http://localhost:8080/anthropic",
)

message = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude!"}],
)
print(message.content)

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

// Before: const client = new Anthropic();
const client = new Anthropic({
  baseURL: "http://localhost:8080/anthropic",
});

const message = await client.messages.create({
  model: "claude-opus-4-5",
  max_tokens: 1024,
  messages: [{ role: "user", content: "Hello, Claude!" }],
});
console.log(message.content);
The provider key in burnguard.yaml must match the path prefix in your base URL exactly. If your YAML has anthropic but your application sends requests to /claude/..., BurnGuard will not recognise the prefix and will return an error. Misspelled or unregistered prefixes are rejected before the request reaches the upstream provider.

Build docs developers (and LLMs) love

Get started for freeTalk to us