Call the hosted console from code.

The cloud console is not just a dashboard: it exposes an SDK-compatible /v1 API, so the same code that talks to a self-hosted engine talks to console.nautris.com with nothing changed but the base URL and the token.

Hosted vs. self-hosted

Self-hosting the engine gives you the full API inside your own network. The hosted console is the low-friction alternative: no deployment, sign in, create a token, send documents. Behind it, the console owns users, tokens, quotas, and retention, and proxies to a managed engine with each user's data isolated in its own sub-tenant. Engine internals never leak: every id you see is a console id. Born-digital documents extract on the always-on engine; scanned and OCR-heavy documents are routed to managed GPU workers automatically, so you get OCR without provisioning a GPU yourself.

Access tokens

Sign in to the console and create an access token (Tokens view), or automate it with your session: POST /api/tokens accepts form or JSON {"name": ...} and returns the token once. Tokens are shown once, stored hashed, and revocable. Send them as X-API-Key (the SDK default) or Authorization: Bearer:

curl https://console.nautris.com/v1/usage -H "X-API-Key: dec_..."

The official SDKs work against the console for the document workflow, with only the base URL and token changed. Supported methods: parse, batch submit, job status, tree, chunks, the exports, search, and usage. Engine-only methods (health, stats, license, sources, webhooks admin, dead letters, audit, semantics) raise plain HTTP errors here; they exist on a self-hosted engine only:

# Python
from nautris.client import NautrisClient

client = NautrisClient("https://console.nautris.com", api_key="dec_...")
result = client.parse("contract.pdf")
hits = client.search("what is the termination clause?")

Endpoints

The surface mirrors the engine's endpoint shapes. Everything is scoped to the token's owner; you can never see another tenant's documents:

Batch submit

Inject a set of documents in one call; each file becomes its own document with its own id, webhook, and retention clock, all tracked under one job:

# submit
curl -X POST https://console.nautris.com/v1/jobs \
  -H "X-API-Key: dec_..." \
  -F "files=@contract.pdf" -F "files=@invoice.pdf" -F "files=@report.docx"
# -> 201 { "id": "job_...", "status": "queued", "documents": [] }

# poll until terminal (succeeded | partial | failed)
curl https://console.nautris.com/v1/jobs/job_... -H "X-API-Key: dec_..."
# -> { "status": "partial", "documents": [
#      { "document_id": "doc_...", "source_file": "contract.pdf", "status": "succeeded", ... },
#      { "document_id": "doc_...", "source_file": "invoice.pdf",  "status": "failed", "error": "..." } ] }

Note on ids: listings and search may hand you a per-file alias job id; resolving any of them returns the same batch view (the body's id is the batch id), and a hit's (job_id, document_id) pair always resolves together.

Per-file results appear in documents as the engine finishes them; fetch each document's tree, chunks, or exports with the ids from the poll. A batch is capped (10 files by default) and each file counts toward the concurrent-documents quota, so a batch cannot sidestep the limits below. Prefer webhooks over tight polling.

Webhooks

Register a webhook URL in the console (Webhooks view) and every document fires document.finished exactly once when it reaches a terminal state, batch or single:

POST your-url
X-Nautris-Event: document.finished
X-Nautris-Signature: sha256=<hex>   # HMAC-SHA256 of the body with your webhook secret

{ "document_id": "doc_...", "job_id": "job_...", "filename": "contract.pdf",
  "status": "succeeded", "pages": 12, "chunks": 34 }

Verify the signature with the secret shown when you created the webhook, then fetch the results by id. The receiver URL must be publicly reachable: registration rejects private and loopback addresses with a 422, so a webhook cannot target localhost during development; poll instead (a 3-5 s interval is plenty, backing off while a job is queued).

Quotas and errors

The free tier enforces monthly pages (200 by default), a per-file size cap (20 MB), a concurrent-documents limit, and a retention window (7 days); the batch cap is 10 files per submit. Your current position is always visible at GET /v1/usage and in the console dashboard. The API tells you which limit you hit:

Not on the hosted surface today: source connectors and delta-sync, and the PII review/approval workflow (review happens in the console UI, not via token). Both remain available when you self-host the engine, whose full API is in the API explorer.