Production baseline
Keep keys server-side
Store
NINJACHAT_API_KEY in your deployment platform or secret manager. Never ship it to a browser or mobile client.Set timeouts and retries
Use the SDK defaults or configure bounded retries. The SDK honors
Retry-After and safely replays billed requests with idempotency keys.Design a fallback
Use
ninja/auto or an ordered models list so one provider incident does not become your incident.Bound spend
Set
routing.max_cost_usd, project limits, and balance alerts before traffic grows.Recommended client
The SDK is the shortest production-safe path because it includes typed errors, streaming helpers, retry handling, and idempotency behavior.A resilient request
Use an ordered model set when you need predictable model families, or replacemodels with model: "ninja/auto" when NinjaChat should choose.
Before customer traffic
- Pin an SDK version and review release notes before upgrades.
- Send a stable end-user identifier in
userfor your own abuse and support workflows; do not put secrets or personal data in it. - Bound concurrency with a worker pool instead of unbounded fan-out.
- Cancel abandoned streams and long-running client requests.
- Store the returned
request_idbeside your application trace or job record. - Monitor usage, balance, latency, errors, and resolved providers.
- Use signed webhooks for completed or failed video jobs and spend alerts.
- Test
401,402,429, timeout, and provider-failure paths before launch.
Release gate
Next: wire the observability loop and run the quickstart once from your deployment environment.