Advanced API Usage
Once the basics work, this page covers what production use actually needs: streaming, common parameters, vision input, SDKs, and retry strategy. Replace MODEL_ID in the examples with a real ID copied from the model plaza; minimal request examples live in API Endpoints.
Streaming
Conversational apps almost always want streaming (typewriter effect). Add "stream": true to the request body and the response arrives chunk by chunk over SSE (Server-Sent Events):
Notes:
- Each chunk starts with
data:; the stream ends withdata: [DONE]; - SDKs handle chunking for you (see below); if parsing yourself, split by line and skip blanks;
- With reasoning models, time-to-first-token stays long even with streaming — the thinking phase produces no visible output, so set generous client timeouts;
- The Anthropic format supports
"stream": truetoo, with a different event structure — use the Anthropic SDK.
Common parameters
Parameters follow the upstream vendor's docs for each protocol; the most used ones:
The gateway forwards request bodies as-is per protocol. Anything the upstream model supports works without gateway-side configuration; unsupported parameters are rejected by the upstream.
Vision input (images)
Vision-capable models accept images in messages. OpenAI Chat format:
- Images can be public URLs or inline
data:image/jpeg;base64,...data; - Images count as input tokens — large images cost noticeably more, compress first;
- Whether a model supports vision follows the capability labels in the model plaza.
SDKs
Official SDKs only need base_url and api_key changed:
Keep keys in environment variables (OPENAI_API_KEY / ANTHROPIC_API_KEY) — SDKs read them automatically. Never hard-code keys into committed code; see the security requirements in the Acceptable Use Policy.
Timeouts and retries
For production robustness:
- Generous timeouts: reasoning models respond on the scale of minutes; set client timeouts ≥ 300 s;
- Exponential backoff: retry
429and5xxwith 1s → 2s → 4s intervals, 3–5 attempts max; other4xxerrors are request problems where retrying is pointless; - Don't blast concurrency: dense retries without backoff get automatically deprioritised, see Rate Limits & Concurrency;
- Log request IDs: the request ID in response headers is the one handle for debugging and support tickets.
Related
- API Endpoints — addresses and minimal examples per protocol
- Choosing a Model — pick by task
- Rate Limits & Concurrency — limit layers and raising them
- Error Codes — handling by status code