Extension access (Outlook, OneDrive, SQL, Atlassian)

Beyond chat and document generation, an API key can act through Strata's extensions — reading and sending Outlook mail, working with OneDrive files, running SQL against a saved connection, reading or writing Atlassian Jira issues and Jira Service Management requests, and reading or writing Confluence pages. Your integration never calls a mailbox or database API directly: it sends a natural-language prompt to POST /v1/chat, and Strata's AI uses the same extension tools the web app uses, scoped to a single identity.

This is opt-in and tightly bounded. A key gains extension power only when an admin grants an extension scope and binds the key to an actor (a person or a connection bot) that has already connected that extension. A plain chat key has zero extension access.

Examples use <API_BASE_URL> in place of the host — substitute https://app.strata.kronisys.com or your organization's deployment.

Extension scopes

Extension scopes are granted alongside chat — they augment the chat surface rather than adding new endpoints. There is no GET /v1/outlook; the AI reaches each extension while answering a prompt.

Ten extension scopes ship today. They are independent of one another: confluence.read never implies confluence.write, and a Jira scope never implies a Confluence one (or the reverse), even though both products ride a single Atlassian connection.

Note

A key needs chat plus the relevant extension scope. outlook.read on its own does nothing — the AI uses it to reach the mailbox while answering a POST /v1/chat prompt.

Actors and connection bots

Every extension-scoped key is bound to one actor — the identity whose mailbox, drive, or database the key uses, and the identity recorded in the audit log. The actor can be:

• A real user — the key reads and sends as that person, from their connected mailbox. Good for "act as me" automations; it stops working if that person leaves or disconnects the extension, and it exposes that person's full inbox to the key.
• A connection bot — a dedicated, org-owned service identity with its own mailbox and drive. This is the recommended actor for shared, production integrations: it survives staff turnover, exposes only the data the integration needs (not a real person's inbox), and reads cleanly in the audit log.

A connection bot lives in your own Microsoft 365 tenant — Microsoft 365 data is tenant-isolated, so the bot must be a mailbox your organization owns (a low-cost shared mailbox seat is enough). One organization can run several named bots — for example a Support inbox bot and a Billing bot — and point different keys at different bots.

Admins create and connect bots from Admin → API Keys → Bots: name a bot, then connect its Outlook and/or OneDrive with a one-time admin sign-in. See API keys → Connection bots.

Atlassian actors

Atlassian is not a Microsoft service and has no connection bot. Jira and Confluence ride one Atlassian connection, so a single connection mode — chosen by an admin under Settings → Extensions → Atlassian → Manage — decides the identity for both products at once:

• Each person signs in. The key's bound user must have connected their own Atlassian account. The key sees exactly what that person sees in Jira and Confluence — their own Atlassian permissions bound every result — and its Atlassian tools go quiet if they disconnect or their grant is revoked.
• One organization account. The organization's Atlassian service account is the identity, and the bound user needs no personal connection. This is the mode built for unattended callers; restrict the service account inside Atlassian to the projects and spaces Strata should reach.

In both modes the organization's pinned Atlassian site — and its optional Jira project allow-list and Confluence space allow-list — bound what the key can reach. See Atlassian extensions.

Confluence

confluence.read lets a key's AI search Confluence with CQL, read a single page as plain text, and list the spaces the actor can see. confluence.write adds creating a page and commenting on one — there is no tool that edits an existing page, so a key can add to Confluence but never rewrite what is already there.

Confluence resolves on the same three layers as Jira and entirely separately from it: the organization's Confluence writes toggle, the actor's role, and the actor's own Confluence writes setting. A key holding confluence.write whose actor resolves to no writes is offered the read tools only. Denying Confluence writes leaves Jira writes untouched, and an org-level Apply to everyone, with no exceptions lock exists per product.

The optional space allow-list is a list of space keys and — unlike Jira project keys — it is case-sensitive. An empty list means every space the connected account can see; a page outside the list is refused rather than silently omitted.

Strata never indexes Confluence into the Knowledge Base. Pages are read live at question time, so a key sees what the actor could see in Confluence at that moment and nothing is embedded or cached as searchable content.

Connect first, then mint

Strata enforces connect-first: the actor must have connected an extension before a key can be minted (or re-scoped) with that scope. Trying to mint an outlook.read key against an actor with no connected mailbox is rejected at creation with a clear message:

The selected actor has not connected: Outlook. An extension-scoped key requires the bound user (or bot) to connect each extension first.

This ordering prevents a silent failure mode — without it, a key carrying an extension scope but no connected actor would simply have no tools and quietly do nothing.

Atlassian satisfies the check either way, for both Jira and Confluence: the bound actor connected their own Atlassian account, or the organization runs Atlassian through a service account that the key rides.

What a call looks like

The developer sends an ordinary chat prompt — no tool name, no mailbox ID, no session token. Strata resolves everything from the key's bound actor:

curl -X POST <API_BASE_URL>/v1/chat \
  -H "Authorization: Bearer sk_strata_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Summarize my 5 most recent unread emails and flag anything urgent."
  }'

Server-side, Strata loads the actor's connected Outlook session, offers the mail tools to the model, and the model calls them to answer — reading only that one actor's mailbox. A key without outlook.read never sees those tools, so it cannot reach mail at all.

Guardrails

Extension access ships with hard limits the API cannot override:

• Send becomes a draft for external recipients. On unattended API runs, send_email to a recipient outside your organization is saved as a draft for a person to review — it is not sent automatically. Internal replies and sends proceed.
• No file sharing. onedrive.write can save and upload, but creating share links or changing file permissions is not exposed through the API.
• SQL is capped. sql.read is read-only; sql.write allows row changes (INSERT/UPDATE/DELETE) but never DDL (schema changes), never administrative statements, and unbounded deletes are blocked. There is no sql.admin scope.
• Jira writes are off unless they are permitted for the key's actor. jira.write is necessary but not sufficient. The write tools are only offered when the organization's writes toggle is on and neither the actor's role nor their own Jira writes override is set to Denied — resolved at request time, so a key can never out-scope its own actor. Otherwise the create and comment tools are never offered at all, whatever the key carries. In chat a member approves each write before it happens; an unattended API run has nobody to ask, so where writes are permitted a key's writes proceed — grant jira.write only to keys that genuinely need it. (Scheduled agents share that posture and resolve it for the agent's owner.) Everything Strata writes carries a trailing line naming Strata and the surface it came from, so an API write reads as one. See Who may write.
• Confluence writes resolve the same way, separately. confluence.write is likewise necessary but not sufficient — the organization's Confluence writes toggle must be on and neither the actor's role nor their own Confluence writes override may be Denied. Strata creates pages and adds comments; nothing edits an existing page.
• Service Management comments are always internal notes. A comment Strata posts on a Jira Service Management request is never visible to the customer who raised it, and commenting on service requests is gated by its own organization toggle, off by default.
• The Atlassian site is pinned. Only an admin can set the organization's Atlassian site, and it is re-checked on every single request — a key cannot reach another site the actor happens to have access to. The optional Jira project allow-list narrows search, counts, single-issue reads, and Service Management queues further; the Confluence space allow-list does the same for pages and spaces, matching space keys case-sensitively.
• Every Atlassian write is audited. A jira.issue_created, jira.comment_added, confluence.page_created, or confluence.comment_added row lands in the Strata audit log with the acting member and the surface. Reads are not audited. Strata never indexes Jira or Confluence into the Knowledge Base — issues and pages are read live at question time.
• Atlassian traffic shares one budget. Jira and Confluence draw on the same hourly Atlassian request cap — 2,000 requests per hour by default per organization, under a platform-wide ceiling of 10,000 — so a busy Confluence key can exhaust the budget a Jira key depends on.
• Tenant isolation. A connection bot's tokens are pinned to your organization's Microsoft tenant; a token from any other tenant is rejected. Keys never reach another organization's data.
• Fail-closed. If the actor's connection is missing or its policy was revoked, the related tools simply aren't offered — the key behaves like a plain chat key for that capability rather than failing obscurely.

Organization policy still applies

Extension access is also gated by your organization's settings. If an admin disables the Outlook, OneDrive, SQL, Jira, or Confluence extension org-wide — or for the actor's role — the matching tools drop out at request time even if the key still carries the scope. Jira and Confluence are separate availability switches on the Atlassian extension page (Settings → Extensions → Atlassian → Manage), so an organization can allow one and deny the other. The live organization policy is always authoritative.

Billing

Extension calls run through the chat surface, so they draw on the key's hourly rate limit and monthly token budget like any other POST /v1/chat call, and count toward the organization's shared pool unless the key opts out. See Rate limits and budgets.

Related

• API keys — create keys and set up connection bots (admin)
• Authentication — scopes, actors, and per-key fields
• Chat and conversations — the endpoint extension tools run through
• Atlassian extensions — connection modes, writes, and the pinned site
• Integrations — connecting Outlook, OneDrive, SharePoint, SQL, Jira, and Confluence in the app