Introduction
Overview
Wicarax turns material you already have into an assistant that answers questions about it. You supply the content and decide where the assistant appears. Everything between those two points is handled for you.
What you do, and what the platform does
The split matters, because it explains why there is no prompt to write and no model to pick. You are responsible for the content and the placement. The platform is responsible for turning a question into a grounded answer.
| You | Wicarax |
|---|---|
| Create an agent and explicitly create a key or installation | Hosts the configured agent and serves its authorized requests |
| Add the material it may use | Reads, indexes and searches that material |
| Choose where it appears | Serves the widget, the API and the SDK |
| Decide which domains may use it | Refuses every origin you did not allow |
| Pick a plan | Meters usage and enforces the plan limits |
How an answer is produced
A single request is answered in one pass and returned complete. There is no partial delivery to handle and no follow-up call to make.
- 1A visitor asks a question through the widget, your own interface, or the API.
- 2The material attached to that agent is searched for the passages most likely to contain the answer.
- 3A reply is composed from what was found, in the language the visitor used.
- 4If the material does not cover the question, the assistant says so instead of inventing an answer.
That last step is the behaviour to test before you go live. Ask something your content genuinely does not cover and confirm you get a decline rather than a confident guess. The Playground exists for exactly this.
Three ways to reach your visitors
All three call the same endpoint and return the same answers. The only difference is how much of the interface you own.
| Surface | You write | Best for |
|---|---|---|
| Embed widget | One <script> tag | A website that needs a chat bubble today, with no build step |
| Official SDK | Your own components | A product where the chat has to look and behave like the rest of the app |
| REST API | HTTP requests | Backends, automations, and any language or tool of your choice |
The API is OpenAI Chat Completions shape-compatible, with an explicitly enforced supported-parameter subset. A client that speaks that shape can point at Wicarax by changing a base URL and a key, and any parameter this API does not implement is refused with a 400 naming the field rather than silently ignored. See Chat Completions for the exact accepted set.
What the assistant will not do
Being explicit about the boundaries saves you from testing for behaviour that was never intended.
- It does not answer from general world knowledge. Its material is the material you added.
- It does not stream. A response arrives complete, in a single body.
- It does not disclose where an answer came from. Document names, file names and passage identifiers stay internal and never appear in a reply or in an API response.
- It does not let a caller change its instructions. Configuration lives in the dashboard, so a request cannot override how the assistant behaves.
What to read next
Key Concepts
The vocabulary these docs use, including the difference between a quota and a rate limit.
Agents
Create one, control its status, and understand what its keys allow.
Sources
The three ways to add material, and which kind suits which content.
Embed Widget
One script tag, a hosted interface, and nothing to build.
Where each thing is configured
| Task | Where |
|---|---|
| Create agents, edit appearance, copy the embed snippet | Agents(sign in required) |
| Group material, scope it to specific agents | Knowledge Base(sign in required) |
| Test answers privately before launch | Playground(sign in required) |
| Create, rotate and revoke keys, manage installation origins | API Keys(sign in required) |
| Review questions your agents could not answer | Knowledge Gaps(sign in required) |
| Track consumption against your plan | Usage and Analytics(sign in required) |
Wicarax Zenith and grounding
Wicarax Zenith is the public model identity. Its API id is wicarax-zenith. An agent has no user-facing model picker; the owner configures name, tone, appearance, knowledge scope, and availability.
Answers use the agent's available material. Tone changes phrasing, not which facts the agent may claim. If a question is unsupported, improve the sources and test again in the Playground.
Decide the delivery surface before you write any content. The widget and your own interface need exactly the same material, so nothing is wasted, but knowing which one you are heading for changes how much effort belongs in appearance settings versus in your own components.
Wicarax is not a general-purpose chatbot and does not attempt to be. It will not answer from world knowledge, browse the web, or take actions in your systems. What it does is answer questions about material you have supplied, and decline when that material falls short.