Providers
Connect provider access once, then let routes decide which model handles each request.
Providers are the model vendors or compatible gateways LatentKit can call for your workspace. Developers do not send provider names in request bodies; operators connect provider access and routes choose eligible models at runtime.
Two access models
| Access model | Who owns credentials | When to use it |
|---|---|---|
| Platform Access | LatentKit-managed credentials billed through workspace credits | Fast onboarding, demos, and teams that want one billing path |
| BYOK | Your workspace stores its own provider key | Production control, direct vendor billing, or providers not covered by Platform Access |
The application integration is the same for both models:
POST https://ai.latentkit.com/v1/chat
Authorization: Bearer <LATENTKIT_API_KEY>
Content-Type: application/jsonThe API key route determines whether the request uses Platform Access or BYOK.
What operators configure
- Open Connections in the console.
- Connect a provider through Platform Access or BYOK.
- Enable the models and capabilities the workspace should use.
- Add those models to a route.
- Publish the route and assign it to an API key.
What developers need to know
- Do not add provider keys to application code unless your own backend needs them for another service.
- Do not send
provider,model,route, orpolicyto LatentKit. - If a request returns
all_providers_exhausted, check whether the assigned route has an eligible connected model for that endpoint. - Vision, image, audio, video, tools, and deep response profiles may require different models than plain chat.
Debugging provider issues
Use the console before changing application code:
- AI Router: run a test request with the selected key.
- Connections: verify provider key health and enabled models.
- Routes: confirm the published route contains an eligible model for the endpoint.
- Usage / request logs: inspect which route attempt succeeded or failed.