API contract
LLM response formats: JSON, XML, CSV, and text
Choose response formatting through format or Accept without changing the provider route.
Developers integrating proxy responses into scripts, services, and data pipelines.
The problem
Different callers need different output shapes. A shell script may want text while an application wants JSON with request and usage metadata.
How LLM Proxy helps
LLM Proxy supports plain text by default and can return JSON, XML, or CSV through the format query parameter or Accept header.
How it works
- Send a normal authenticated text request.
- Omit format for text/plain or request application/json, application/xml, or text/csv.
- Read token usage headers when upstream usage is available.
- Use JSON when the caller needs request, response, choices, messages, and usage fields together.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Format negotiation | Callers choose output shape without changing provider selection. | The same route can serve scripts and apps. |
| JSON metadata | JSON responses include request, response, object, model, choices, messages, and usage when available. | Apps get structured context. |
| Usage headers | Token headers remain separate from body format. | Plain text callers can still read usage counts. |
Use-case examples
Shell output
A CLI caller accepts text/plain for direct terminal display.
Structured app
A backend requests application/json to store response and token metadata.
CSV export
A workflow asks for text/csv when it wants one escaped cell.
Objections and limitations
- Response formatting does not change provider behavior.
- Usage appears only when the upstream provider reports usage.
- XML and CSV are formatting conveniences, not provider-native response shapes.
FAQ
What is the main job of LLM response formats JSON XML CSV text?
LLM Proxy supports plain text by default and can return JSON, XML, or CSV through the format query parameter or Accept header.
Who should read this api contract resource?
Developers integrating proxy responses into scripts, services, and data pipelines.
Does this page claim provider performance or pricing advantages?
No. The supported claim is about LLM Proxy's documented routing, configuration, management, security, usage, and deployment contracts. Provider cost, speed, rankings, and benchmark claims are not made here.
Where should setup details come from?
Use the main README and implementation notes for current command, config, and endpoint details. This page summarizes the workflow without replacing LLM Proxy documentation.
What should I read next?
A closely related resource is Canonical /v2 chat messages API for LLM calls, which covers v2 chat messages API.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference