Naxis Technologies DOCS
/
naxistechnologies.com ↗

Product guide

The built-in API cards

The two key-authenticated API cards — one to push documents in, one to ask questions — set up from the console.

Ingestion API — push documents in

The Ingestion API lets your own application push documents into the knowledge base over HTTP, instead of a connector pulling them. It's a source like any other — what it ingests is chunked, embedded, access-controlled, analysed and retained exactly the same way. This article is the complete reference.

Setup

  1. Documents → Ingestion API: name it, and choose which groups may read what it ingests (that becomes each document's default access).
  2. Open the source and copy its endpoint and key from “API endpoint & key”. Rotate issues a new key and invalidates the old at once.

Authentication

Send the key in an Authorization: Bearer header on every request. The key belongs to this one source — it can ingest, never message. A missing or wrong key returns 401.

Endpoints

Document fields

external_idYour stable id for the document (1–512 chars: letters, digits, . _ : / -, starting alphanumeric). Send the same id again to update the document in place.
titleOptional display title.
textInline content — markdown, HTML or plain text. Provide exactly one of text or content_base64.
content_base64Base64-encoded bytes for binary formats (PDF, DOCX…). 50 MB per document, 100 MB per request.
filename / content_typeOptional hints for format detection; derived from external_id and content when omitted.
aclOptional list of groups (e.g. ["grp:support"]). Named groups must already exist. Omit it to use the source's own groups.
metadataOptional free-form JSON stored with the document.

Example

curl -X POST <base>/api/v1/ingest/documents \
  -H "Authorization: Bearer <key>" \
  -H "Content-Type: application/json" \
  -d '{"external_id":"kb/refunds",
       "title":"Refund policy",
       "text":"# Refunds\nWe refund within 30 days.",
       "acl":["grp:support"]}'

Behaviour worth knowing

Machine-readable spec for Postman/codegen: /api/v1/openapi.json.

Messaging API — ask over HTTP

The Messaging API lets your own application ask the assistant over HTTP and get grounded, cited answers — the programmatic sibling of the website widget. Every answer is access-controlled and audited exactly like the web chat. This article is the complete reference.

Two kinds of key

Setup

  1. Chat channels → Messaging API: name it, and pick the guest access groups the shared key may answer from.
  2. For per-person access, open Users → Edit → Chat channels and Generate a key for each person; copy it from there.
  3. Send the key in an Authorization: Bearer header. A messaging key can never ingest.

Endpoints

Message fields

textThe question, in any language.
end_userOptional caller id (1–128 chars). With the shared channel key it keeps each end user's conversation memory separate; with a personal key it is ignored — the key already is the person.
conversation_idPass the id from a previous answer to continue that conversation.

The answer

Responses carry the answer text, abstained (true when the honest answer was “not in the knowledge base”), conversation_id, and citations — the numbered sources behind the text. Personal-key conversations are the same ones the person sees in the web chat.

Example

curl -X POST <base>/api/v1/messages \
  -H "Authorization: Bearer <key>" \
  -H "Content-Type: application/json" \
  -d '{"text":"What is the refund window?",
       "end_user":"u-4471"}'

Behaviour worth knowing

Machine-readable spec for Postman/codegen: /api/v1/openapi.json.