OpenAI-Compatible API
The OpenAI Chat Completions format has become the lingua franca of AI development. Countless SDKs, frameworks, agent runtimes, and no-code tools speak it natively. ChatBotKit's OpenAI-compatible API meets that ecosystem where it is: point any OpenAI client at ChatBotKit and it just works, with only a base URL and an API key to change.
But compatibility is only half the story. The more interesting idea is what sits behind that familiar interface.
Drop-In Compatibility
If your code, library, or tool already talks to OpenAI, adopting ChatBotKit is a configuration change rather than a rewrite. Set the base URL to ChatBotKit's compatible endpoint, authenticate with a ChatBotKit secret key, and keep your existing request and response handling exactly as it is.
Standard and streaming responses, tool and function calling, and the usual sampling parameters all behave the way OpenAI clients expect. Parameters we don't map are accepted and ignored, so existing code keeps running unchanged.
Systems as Models
Here's the part that changes how you think about it. In a normal OpenAI request the model field names a single model. In ChatBotKit, the model field is a selector-and it can point at an entire system.
This is the same move Perplexity makes when its "model" quietly includes built-in web search. From the client's point of view it is just a model; behind the scenes it is a model plus a capability. ChatBotKit generalizes that idea: you can package a backstory, knowledge bases, skillsets, tools, web search, and even a coordinated team of agents, then expose all of it behind a single identifier that looks and behaves like a model.
To the calling application nothing special is happening-it sends messages and receives completions. But that one "model" might be:
- Grounded in your data through connected datasets, so answers cite your knowledge instead of guessing
- Equipped with tools and skillsets, so it can take actions, call services, and run routines
- Backed by built-in search, so it stays current without you wiring anything up
- Orchestrated across multiple agents, so specialized sub-agents handle the parts they're best at
You design the system once in ChatBotKit. Every OpenAI-compatible client then consumes it as if it were a single, unusually capable model.
Selecting a Model or Agent
The model field accepts a simple, explicit selector so there's never any ambiguity about what you're talking to:
model/name=<model>- talk to a specific model directly, for plain, stateless completionsbot/id=<id>- use one of your configured agents, with its full system of backstory, datasets, skillsets, and tools
Any system prompt you include is layered on top of the selected target. With model/name= it becomes the instruction set; with bot/id= it extends the agent's existing configuration rather than replacing it, so per-request guidance composes cleanly with the system you've already built.
Why This Matters
The value is reach without rework. The OpenAI format is everywhere, which means anything that already speaks it-an agent framework, an IDE assistant, an internal tool, a third-party product-can adopt ChatBotKit instantly. And because a "model" can be an entire system, you get to ship sophisticated, grounded, tool-using agents to those clients without asking them to learn anything new.
Compatibility is the on-ramp. Packaging systems as models is the destination: the simplicity of a single model call, with the depth of a full ChatBotKit agent behind it.