You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/api-server-endpoints/index.md
+63Lines changed: 63 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -151,6 +151,69 @@ Guardrails-specific fields are nested under the `guardrails` object in the reque
151
151
- A state object to continue a previous interaction. Must contain an `events` or `state` key, or be an empty dict `{}` to start a new conversation.
152
152
```
153
153
154
+
### Authentication Headers
155
+
156
+
The server supports per-request API key injection via custom HTTP headers. This allows different requests to use different API keys for the configured LLM models, without modifying the server configuration or environment variables.
157
+
158
+
#### Header Format
159
+
160
+
For each model in your guardrails configuration, you can provide a custom API key using a header in the format:
161
+
162
+
```
163
+
X-{model-name}-Authorization: your-api-key-here
164
+
```
165
+
166
+
The header name is **case-insensitive** and the model name should match the `model` field in your configuration (spaces and special characters should be preserved as-is, though the header matching is case-insensitive).
167
+
168
+
#### Examples
169
+
170
+
**Single Model Configuration**
171
+
172
+
If your configuration uses `gpt-3.5-turbo` as the main model:
173
+
174
+
```bash
175
+
curl -X POST http://localhost:8000/v1/chat/completions \
If your configuration uses multiple models (e.g., `gpt-3.5-turbo` for main generation and `gpt-4` for self-check), you can provide separate keys for each:
188
+
189
+
```bash
190
+
curl -X POST http://localhost:8000/v1/chat/completions \
- Headers are matched to models by comparing the model name (case-insensitive)
204
+
- If a header is provided for a model, it **overrides** the API key configured in the guardrails configuration or environment variables for that specific request only
205
+
- If no header is provided for a model, the default API key from the configuration is used
206
+
- API keys are automatically reset to their original values after each request completes, preventing leakage between requests
207
+
- This works for both streaming and non-streaming requests
208
+
209
+
#### Use Cases
210
+
211
+
This feature is particularly useful for:
212
+
-**Multi-tenant applications**: Different users can use their own API keys without server reconfiguration
213
+
-**Cost tracking**: Route different requests to different API accounts for billing purposes
214
+
-**A/B testing**: Test different API keys or accounts within the same deployment
215
+
-**Development**: Test with personal API keys without modifying shared configurations
216
+
154
217
### Generation Options
155
218
156
219
The `guardrails.options` field controls which rails are applied and what information is returned.
0 commit comments