Playground
Test real workspace requests in the console before wiring production code.
The public docs site does not run live API requests because real calls require a workspace API key, billing context, and route assignment. Use the logged-in console playgrounds for real execution.
Which console tool to use
| Tool | Best for |
|---|---|
| AI Router | First request, selected API key, route health, copyable snippets |
| Developers | Workspace-aware examples across languages and endpoints |
| Playground | Manual request testing against the same runtime path as production traffic |
| Usage / logs | Debugging request ids, failures, latency, and spend |
Recommended first test
- Open console.latentkit.com.
- Go to AI Router.
- Select the API key your application will use.
- Confirm a published route is assigned.
- Run a plain chat test before trying streaming, tools, image generation, or embeddings.
- Copy the matching snippet into your backend.
Why start in the console?
The console validates the integration prerequisites that code examples cannot see:
- The key is active and unrevoked.
- The key has a published route.
- The route has eligible models for the endpoint capability.
- Provider access is connected and healthy.
- Credits, plan limits, or BYOK credentials can execute the request.
If a console test fails, fix route/provider/billing state first. If the console test succeeds but your app fails, compare headers, environment variables, and request body shape.
Production checklist
- Store
LATENTKIT_API_KEYin server-side secrets. - Log
X-LK-Request-IDfor failed responses. - Keep browser clients calling your backend, not LatentKit directly.
- Avoid sending provider/model selection in request bodies.