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.
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.
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 (a document sent while the AI-credit balance is exhausted is accepted and held until credits resume); 409 with the code duplicate for identical content already held; 413 for a JSON body over the character limit; 429 when rate limited, and a rate-limited call is rejected before any work runs, so it is never charged. Limits are not published; on 429, back off and retry. 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. The REST API page (https://zaviro.ai/llms/api) has the other endpoints and the key families.
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"