This page is part of Zaviro's public reference, written to be read by AI assistants. Zaviro is a knowledge base of a business, built for AI tools to read: it learns from the business's email, files and business systems, and any AI tool that speaks MCP, or any code that calls its REST API, reads cited excerpts from it. Zaviro never writes the answers itself; the AI tool reading it does. Start at the overview (https://zaviro.ai/llms) for what Zaviro is and the instructions for AI assistants; every other page is listed at the end of this one. For a person, the site itself, https://zaviro.ai, covers the same ground.
Zaviro connects to your AI tools through MCP or its REST API. New AI tools work as they arrive: anything that speaks MCP can connect the day it ships, with nothing needed on Zaviro's side. That includes chat platforms whose built-in assistant speaks MCP: in Slack, Slackbot can answer from your knowledge base with no separate AI subscription (on Slack plans that include it), and a team with its own AI plan can tag their own assistant in Slack instead. Admin-led rollouts to organization-wide enterprise AI platforms are an Enterprise conversation.
This page is every programmatic surface in one place: the MCP server first, then the REST API, the ingest API, and the command line.
The flagship surface. Zaviro runs a remote MCP (Model Context Protocol) server over streamable HTTP at:
https://api.zaviro.ai/api/mcp
Any MCP-capable client can connect: AI assistants, coding tools, agent frameworks, and anything else that speaks the protocol. There is no compatibility list to be on: any AI tool works the moment the interface you run it in can connect to an MCP server or call the REST API, and nothing needs to be listed, partnered, or approved on Zaviro's side.
An AI tool reaches the server by one of two paths:
The two paths differ in one thing that matters: a connection made over OAuth acts as the person who approved it, so their AI reads the shared knowledge base and their own personal one; a key reads shared knowledge only, whichever account created it. Some AI tools allow custom connectors only on certain of their own plans; the product's setup screen says what applies to each.
Tools exposed (reads):
Tools exposed (writes):
The tool set grows with the product.
A search/fetch tool pair implementing the ChatGPT connector contract is also exposed, backed by the same retrieval core, so every AI tool reads the same knowledge base and gets the same cited results. Which of the tools a given AI exposes follows that AI's own interface; the product's setup screen shows what each supports, and for anything it leaves open the contact form, https://zaviro.ai/contact, is the quickest answer: every message gets read and answered, and Zaviro is happy to help.
MCP writes add and refine knowledge; nothing over MCP can delete a document or an entity (deletion is a signed-in web-app action). Writes follow the person's own authority: the AI of an Owner, an Admin, or a member granted the Knowledge Editor capability writes to the shared knowledge base, and any other member's AI writes to that member's personal knowledge base. MCP keys mint read-only; an admin or owner can issue a write-capable MCP key, and that key reaches every write tool, including corrections and knowledge edits, at its issuer's authority and on shared knowledge only, never personal. Every AI write is additionally recorded as a viewable note in the app, visible to whoever can see that knowledge base, and deleting that note reverts the write.
When a connected AI asks a question Zaviro cannot serve (for example, no data connected yet or documents still processing), the tools return structured state rather than empty results, no_data_connected, or data_ingesting with a documents_processing count, each with guidance, so your AI can tell you what is actually going on; when billing is not active, each tool returns a structured status before anything runs.
Zaviro's REST API is for code, scripts, and automations. Endpoints live under /api/v1/, and v1 grows additively:
Typed key families, each valid only on its own surface:
All keys are shown once at creation, stored as hashes, individually revocable, and support optional expiry. API access is included in every plan and draws from the same AI-credit balance; there is no separate API pricing. Fair-use rate limits scale with the plan, and there is no separately priced rate-limit tier; integrations should handle HTTP 429 (rate limited) and 402 (billing or credits) responses. Rate-limited calls are rejected before any work runs, so they are never charged, and a paused account is a clean 402 with a code over REST and a structured status over MCP, never a silent failure. Your trial organization is the test environment, on the same endpoints as a paid one.
Query with a read key. Zaviro returns excerpts and the documents they came from. It does not write the answer:
curl -X POST https://api.zaviro.ai/api/v1/query/ \
-H "Authorization: Bearer zvr_mcp_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"query": "payment terms for Acme", "max_results": 15}'{"answer_context": "excerpts, each labeled with its document",
"source_documents": [{"id": 4822, "name": "Acme MSA",
"url": "https://api.zaviro.ai/d/4822",
"document_type": "contract",
"category": "legal",
"date": "2026-01-01",
"summary": "Master services agreement."}],
"structured_data": "",
"paths_used": ["simple_lookup"]}"query" is the only required field. "structured_data" is an empty string unless the question resolves to an aggregate, in which case it holds the computed total and the record count behind it. Each "url" is a permanent link that re-checks the clicker's own access before it resolves, so a leaked one reaches a sign-in wall rather than the document. Every refusal carries a "detail" sentence, and a "code" where one applies: 401 for a missing, wrong-family, revoked, or expired key; 402 when billing is not active, and on reads when the AI-credit balance is exhausted (ingest still accepts a document and holds it until credits resume); 409 with the code duplicate when ingest receives identical content it already holds; 429 when rate limited. Limits are not published; on 429, back off and retry.
Versioning policy: v1 changes are additive; a breaking change means a new version and a migration window. In the product, the same endpoints sit beside the keys they use.
A public query surface lets you put a support or sales chatbot on your own website, grounded only in documents an admin explicitly marks public. The call is POST /api/v1/public/query/ with a public key and {"query"}, plus an optional "max_results"; it returns cited excerpts with source names only, never links, because citation permalinks are sign-in-protected. The knowledge graph, internal documents, and personal knowledge bases are never served on this surface, and visitor questions are not logged. In-product guides cover the major chatbot platforms, and a platform not among them is a question for the contact form, https://zaviro.ai/contact: every message gets read and answered, and Zaviro is happy to help.
The ingest API is the universal way in on the source side: anything that can make an HTTP request can send documents and records into the knowledge base, directly or through its Zapier, Make, or n8n app. It is the answer whenever a system is not a native connection, and it is how a business's own systems, an accounting platform, a CRM, a job tracker, an industry system, keep the knowledge base current as their records change.
One endpoint, POST https://api.zaviro.ai/api/v1/ingest/, with an ingest key: the zvr_sk_ family, created on the product's Deployments page, shown once, individually revocable, with optional expiry, and valid on this endpoint only. The body takes one of two shapes:
Re-sending a JSON record with the same "external_id" updates the existing document rather than adding a second copy, so a re-run of a script changes nothing it should not, and a changed record in your system, the status of a job, the stage of a deal, becomes a changed record in the knowledge base. What the team has corrected on that record holds through the update, a correction to a field your system owns included, until the correction is reverted in the app. Nothing sent over the API deletes: removal is an explicit action in the app. Identical content sent twice with no "external_id" to tie it to a record, a file or a JSON body, is refused with 409 and the code duplicate, so nothing is learned twice; a changed file is learned as a new document.
Ingest is asynchronous. The response is 201 with "id", "name", "status" (processing), and "processing" (the lane), and the document then goes through the same stages as any other. Poll GET https://api.zaviro.ai/api/v1/document/{id}/ with a read key (the zvr_mcp_ family) until "status" reaches ready, when the document is askable and the response carries its text and metadata, or failed, with an "error_message". An id outside that key's reach reports "found": false rather than disclosing that it exists.
Both shapes accept "process_overnight", as a JSON field or a form field. The default, true, rides the overnight batch lane at half the credits; false asks for processing now, at the full rate, which is what the worked examples below send. The response's "processing" field echoes the lane the document actually got, overnight or instant, so a script always knows.
An ingest key writes at its creator's authority. A key created by an Owner, an Admin, or a member granted the Knowledge Editor capability writes to the shared knowledge base; any other member's key writes to that member's personal one. No key of any family reads a personal knowledge base, this one included: an ingest key only writes. So for records the whole company should read, create the key from an account with that authority; a record a member's key sent to their personal knowledge base is one no read key can see, and polling it reports "found": false.
On Zapier, Make, or n8n, the integration is an HTTP step: trigger on the record in your system, a new invoice in the accounting platform, a closed deal, a completed job; map its fields into "fields"; put the system's own id in "external_id"; and POST with the ingest key in the Authorization header. Systems with their own app on those platforms reach Zaviro this way without a native connection, accounting platforms, CRMs, and industry systems among them, and What Zaviro learns from (https://zaviro.ai/llms/connections) names examples. In-product guides cover common setups. A system that would be better served by a native connection is one to ask for through the contact form at https://zaviro.ai/contact: native connections are added continually, on customer request as well, and every message gets read and answered, and Zaviro is happy to help.
Refusals are the ones under The REST API above, with one addition: 413 for a JSON body over the character limit. A document sent while the AI-credit balance is exhausted is accepted and held until credits resume, and a rate-limited call is rejected before any work runs, so it is never charged. Ingest draws from the same AI-credit balance as everything else (the pricing page (https://zaviro.ai/llms/pricing) has the figures); there is no separate API pricing.
A file:
curl -X POST https://api.zaviro.ai/api/v1/ingest/ \ -H "Authorization: Bearer zvr_sk_YOUR_KEY" \ -F "file=@contract.pdf" \ -F "process_overnight=false"
{"id": 4821, "name": "contract.pdf", "status": "processing",
"processing": "instant"}A record from your own system, updated in place on every re-send:
curl -X POST https://api.zaviro.ai/api/v1/ingest/ \
-H "Authorization: Bearer zvr_sk_YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"title": "Job 4471", "external_id": "job-4471", "process_overnight": false,
"fields": {"Customer": "Acme Corp", "Status": "Completed",
"Invoice": "INV-2210", "Completed on": "2026-10-09"}}'{"id": 4823, "name": "Job 4471", "status": "processing",
"processing": "instant"}Then, with a read key, until "status" is ready:
curl https://api.zaviro.ai/api/v1/document/4823/ \ -H "Authorization: Bearer zvr_mcp_YOUR_KEY"
Zaviro ships a command-line client for people who live in a terminal: search the knowledge base and get cited excerpts with their source documents, or push a note, without leaving the shell. It installs from npm as @zaviro/cli, authenticates with an MCP key, and speaks the same MCP protocol as every other client. Commands: configure (endpoint and key, or environment variables for CI), search (cited results), note add (writes through the full pipeline), tools (lists the MCP tools your AI sees), and completion for bash and zsh. Every read (search and tools) takes --json for scripting; exit 0 on success, 1 on error. Search and tools work with any MCP key, which like every key reads shared knowledge only; note add writes, so it needs an MCP key an admin or owner issued write-capable, and the note lands in the shared knowledge base.
A first session:
zaviro configure --url https://api.zaviro.ai/api/mcp --key zvr_mcp_YOUR_KEY zaviro search "when does the Acme MSA renew?" zaviro search "fuel spend" --json | jq '.source_documents[].name' zaviro note add "Acme renewal pushed to Q3, confirmed by phone" --title "Acme renewal"