StrataDocs

API overview

The Strata HTTP API is a server-to-server interface for running prompts, generating documents, and managing conversations from your own backend. Every request authenticates with an API key — no cookies, no browser sessions.

Base URL and versioning

All endpoints live under /v1/ on your Strata host.

https://app.strata.kronisys.com/v1/...

If your organization runs a dedicated Strata deployment, swap the host for your tenant's URL. The /v1/ prefix is permanent — breaking changes ship as /v2/ rather than silent edits to /v1/.

Throughout this documentation, examples use <API_BASE_URL> in place of the host — substitute https://app.strata.kronisys.com (or your tenant's URL) wherever you see it.

Note

The interactive OpenAPI 3.1 spec is available at <API_BASE_URL>/v1/openapi.json without authentication. Point Swagger UI, Postman, or your code generator at it.

Warning

The API is not available during a free trial. An organization still on its self-serve trial cannot mint an API key (POST /api/admin/api-keys returns 403 with code TRIAL_NO_API_KEYS and the message "API keys are not available during your trial. Add a payment plan to enable programmatic access."), and any existing key stops working while the org is on a trial (403 trial_no_api_access). Add a payment plan first — the check follows your organization's current state, not its state when the key was minted.

First call in 60 seconds

  1. Sign in to Strata and open Admin → API Keys.
  2. Click Create key, pick a name, select the chat scope, choose its allowed models and limits, and copy the secret. It starts with sk_strata_live_ (or sk_strata_test_ on a non-production deployment) and is shown exactly once.
  3. Verify the key is live:
curl -H "Authorization: Bearer sk_strata_live_..." \
  <API_BASE_URL>/v1/health
  1. Send your first prompt:
curl -X POST <API_BASE_URL>/v1/chat \
  -H "Authorization: Bearer sk_strata_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Summarize the highest-revenue customer segment this quarter."
  }'

The response includes the assistant's reply, the conversation ID for follow-ups, and rate-limit headers so you can pace your traffic.

The request body takes either message (a single user string) or messages (an array of {role, content} turns) — not both. model is optional: omit it to use the key's first allowed model, or set it to any model your key and organization permit (see Models).

Scopes

Each key carries one or more scopes. A request that hits an endpoint outside its key's scopes returns 403 forbidden. Grant the narrowest set that gets the job done.

ScopeEnables
chatPOST /v1/chat, POST /v1/query, and the /v1/conversations/* family
filesPOST /v1/files (upload) and GET /v1/files/:id (download)
excelPOST /v1/excel — styled XLSX generation
pdfPOST /v1/pdf — PDF report generation
pptxPOST /v1/pptx — PowerPoint deck generation
docxPOST /v1/docx — Word document generation

Two endpoints carry no scope requirement and work with any valid key: GET /v1/health (the key's own state and budget) and GET /v1/usage (see below). GET /v1/openapi.json needs no key at all.

Keys can also be granted extension scopes — ten of them: outlook.read, outlook.send, onedrive.read, onedrive.write, sql.read, sql.write, jira.read, jira.write, confluence.read, confluence.write — which let a key read/send mail, work with OneDrive, run SQL, or search and write Jira and Confluence while answering a POST /v1/chat prompt. These act as a bound identity (a user or a connection bot) and require that identity to have connected the extension first; for Jira and Confluence, which share one Atlassian connection, an organization running the shared service account satisfies that on the actor's behalf. jira.write and confluence.write each carry a second gate — the organization must also allow writes for that product, or the key is left read-only there. See Extension access and Atlassian extensions.

Tip

Create separate keys per service or environment. Revoking a leaked staging key shouldn't take production offline.

Models

Strata runs a Model Catalog that Kronisys curates centrally — a broad set of models across OpenAI, Anthropic, xAI, DeepSeek, Mistral AI, Cohere, and Microsoft, all served through Microsoft Azure AI Foundry. Each organization enables the subset it wants, and an admin further narrows the list each API key may use when the key is minted.

The model field on POST /v1/chat and POST /v1/query is optional. Omit it and Strata uses the key's first allowed model; set it to request a specific one. The set you can pass is the intersection of the key's allowed models and the organization's currently-enabled catalog. If you request a model the organization has since disabled, the call returns 403 forbidden with a model_not_allowed error rather than silently substituting another model.

To see exactly which models a key can use, call GET /v1/health — the response's key.allowed_models lists them. For the human-readable catalog (capabilities, context windows, pricing), an admin can open Org Settings → Manage AI models in the web app.

Note

Model IDs are short slugs such as gpt-5.4 or claude-sonnet. Don't hard-code a fixed list in your integration — read key.allowed_models from /v1/health so your client stays correct as the organization's catalog changes.

Request and response anatomy

Every authenticated request needs Authorization: Bearer <key>. JSON endpoints also need Content-Type: application/json. On a non-streaming POST /v1/chat, you can add Idempotency-Key: <uuid> — Strata replays the original response for 24 hours when the same key reappears, so a network-retry doesn't create a duplicate conversation. A request still in flight under that key returns 409.

Responses carry telemetry headers you should log and respect:

  • X-Strata-Api-Key-Id — the key that served the request
  • X-Strata-Rate-Limit and X-Strata-Rate-Used — per-hour window counters
  • X-Strata-Budget-Used and X-Strata-Budget-Limit — tokens consumed this billing cycle and the key's monthly token budget (when a budget is set)
  • X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After — standard rate-limit fields

Errors follow RFC 7807 (application/problem+json). Each body carries a stable type URI, a human-readable title, the status, and — where useful — extra problem-specific fields:

{
  "type": "https://api.strata.kronisys.com/errors/insufficient_scope",
  "title": "This API key was not granted the \"excel\" scope. The admin who minted the key must update its allowed scopes.",
  "status": 403,
  "required_scope": "excel",
  "granted_scopes": ["chat"]
}

Billing readback

GET /v1/usage returns what your organization has accrued this billing period, in dollars and counts — never tokens. It needs a valid key but no scope, and it reports the whole organization (an API key is an organization credential, not a personal one). Pass ?period=YYYY-MM to read an earlier period; omit it for the current one.

The body carries billing_period, a credits object (total, usd, price_per_credit_usd, and a by_type breakdown of credits and event counts), a response_processing object (fee_usd, messages), and a weighted flag. weighted: false means size-weighted metering is not switched on for your environment yet, so the counts are flat per-event and the dollar figures are indicative rather than billable. See Usage for what each credit type measures.

What this API is NOT

  • Not a browser SDK. Keys are server-only secrets. Don't ship sk_strata_live_ tokens to a web or mobile client; proxy through your backend.
  • Not a replacement for the chat UI. The web app handles sign-in, dashboards, voice mode, and the artifact panel. The API exposes the prompt, query, document-generation, and billing-readback surfaces only.
  • Not a database driver. POST /v1/query runs against a connection an admin has already saved in Strata; you can't pass raw connection strings.
  • Not free of limits. Every key has a per-hour rate cap and may carry a monthly token budget. Both return clear 429 responses — handle them.

Related