Last week, I released the [Open WebUI Python Client](https://github.com/whogben/owui_client), a library that gives developers 1:1 control over their Open WebUI instance. It solved the problem of programmatic access, but it created a new one: confusion.
The Open WebUI API is powerful, but many of its parameters are "black boxes"—generic dictionaries like `meta` or `chat` that accept specific keys but don't document what those keys are. If you don't send exactly the right structure, the request fails, often with a generic error.
I built the vehicle, but I didn't provide the map.
Today, I'm releasing the [Complete Open WebUI API Documentation](https://whogben.github.io/owui_client/). It contains a reference for every endpoint and model in the system, including deep-dives into those complex dictionary parameters.
> [!NOTE] Get the Documentation
> * **Read the Docs**: [whogben.github.io/owui_client](https://whogben.github.io/owui_client/)
> * **Get the Client**: `pip install owui-client`
> * **View Source**: [GitHub Repository](https://github.com/whogben/owui_client)
## The Problem with "Black Box" APIs
Building an agent that creates a chat session programmatically sounds simple. You import `ChatModel` and send it to the API. But `ChatModel` contains a field named `chat`, which is defined simply as a `Dict`.
What goes in that dictionary? Is it `{"id": "..."}`? `{"history": [...]}`? Without documentation, you have to reverse-engineer the frontend code or guess until something works.
This friction kills developer momentum. You shouldn't have to read the source code of the tool you're trying to automate.
## The Solution: AI-Generated Documentation
To solve this, I used the same "Vibe Coding" approach that built the client. I tasked KiloCode (my AI coding workflow) with a new mission: document everything.
Using the **Spectre** model, I orchestrated a team of sub-agents to investigate the Open WebUI codebase. I didn't just ask them to "write docs"—that leads to hallucination. I gave them a [strict process](https://github.com/whogben/owui_client/blob/main/AGENTS.md#documentation):
1. **Investigate One Field at a Time**: The agent locates a specific model attribute (like `ChatModel.chat`).
2. **Trace Usage**: It searches the frontend and backend code to see how that attribute is used.
3. **Identify Keys**: It lists every valid key that the dictionary accepts.
4. **Write the Docstring**: It compiles its findings into a clear description.
The result is documentation that tells you exactly what to send.
## Process Statistics
This wasn't a quick prompt. It was a massive, automated research project.
* **Time**: 8 hours of continuous processing.
* **Scale**: 1,378 individual agent requests.
* **Volume**: 61.3 million input tokens, 233 thousand output tokens.
* **Cost**: Equivalent to ~$125 at Gemini 3 pricing (though Spectre is currently free).
I had to restart the orchestrator four times as it hit context limits, but the result is the most complete map of the Open WebUI API that exists today.
## A Note on Accuracy
I built this documentation using AI, and while I implemented strict checks to prevent hallucinations, it is still an autogenerated resource.
Think of it as a high-quality map drawn by an explorer who moved fast. It will get you where you need to go 99% of the time, but you should verify the terrain before you deploy critical infrastructure. If you find an error, [please report it](https://github.com/whogben/owui_client/issues).
## What's Next?
This documentation is step two. Step one was the client. Step two is the map.
Step three is **Headless Administration**. My goal is to build agents that live inside Open WebUI and manage it—creating tools, modifying system prompts, and handling user administration without human intervention.
For now, I hope this documentation helps you build your own tools and workflows.