API keys

Issue and manage API keys so external integrations can authenticate to the Strata API. Each key is bound to specific scopes, rate limits, and a monthly token budget.

The API Keys page lives at Admin → API Keys and requires the canManageApiKeys permission.

Warning

API keys are not available while your organization is on a self-serve trial. Creating one is refused with "API keys are not available during your trial. Add a payment plan to enable programmatic access." (403, code TRIAL_NO_API_KEYS), and the check is re-applied on every request — a key minted while you were paying stops working if the organization later re-enters a trial.

Creating an API key

1. Click New API key.
2. Enter a name (up to 120 characters, unique within your org) — use something descriptive like Marketing analytics pipeline or Salesforce integration. Strata checks availability live as you type.
3. Under Scopes, check which API surfaces this key can use: chat, files, excel, pdf, pptx, docx, or audit:read (shown as Read audit log — a read-only audit-trail export for SIEM ingestion; grant it on its own key). chat and files are pre-selected; at least one scope is required. The ten extension scopes — outlook.read, outlook.send, onedrive.read, onedrive.write, sql.read, sql.write, jira.read, jira.write, confluence.read, confluence.write — also appear here; they let a key read/send mail, use OneDrive, run SQL, or read and write Jira and Confluence as the key's actor, and require that actor to have connected the extension first (see Connection bots and Extension access).
4. Under Models, select which AI models this key can invoke. The picker lists the models your organization has enabled in the Model Catalog, with all of them checked by default. Voice, transcription, and embedding models don't appear here — they aren't reachable through the /v1 chat surface.
5. Set Requests per hour — the per-key rate limit (default 1,000; 1–1,000,000).
6. Set Tokens per month to cap spend. Defaults to 5,000,000. Clear the field for no cap (not recommended for production).
7. If your org bills from a shared pool, choose whether this key's tokens count toward the org pool budget. This option only appears when pool billing is enabled in Org Settings → Billing; otherwise the key is tracked against its own monthly budget only.
8. Optionally set an Expiration date (up to 5 years from now). When it passes, the key auto-deactivates.
9. Choose the actor the key is attributed to — an existing team member, or New service account to auto-provision an identity bound to this key. Service accounts can never sign in via SSO.
10. Click Create key. Strata displays the raw key value — copy it now. You'll never see it again.

Key

The raw key is shown only once. Copy it immediately and store it securely (e.g., in your secrets manager). If you lose it, revoke this key and mint a new one.

Note

A key's models are always re-checked against your org's live Model Catalog at request time. If you later disable a model that this key was allowed to use, calls naming that model are rejected — the key's stored selection never overrides the current catalog.

Connection bots

When a key needs to read or send mail, use OneDrive, or run SQL, it acts as an actor that has connected those extensions. You can bind a key to a real user, but for shared production integrations the cleaner choice is a connection bot — a dedicated, org-owned identity with its own mailbox and drive. A bot survives staff turnover, exposes only the data the integration needs, and reads clearly in the audit log.

Open the bots manager from the Bots button in the API Keys toolbar.

1. Click New bot, give it a name (unique within your org — Strata checks availability live as you type), and Create bot.
2. On the bot's row, click Connect Outlook and/or Connect OneDrive. A Microsoft sign-in window opens — sign in as the mailbox/account this bot should act as (a mailbox in your own Microsoft 365 tenant). The window confirms once the bot is connected.
3. Mint an extension-scoped key (steps above) and pick this bot as the actor. The actor dropdown lists your bots alongside people, with each bot's connected extensions shown.

One organization can run several named bots — for example a Support inbox bot and a Billing bot — and point different keys at different bots. Removing a bot disconnects its mailbox/drive; Strata blocks the removal if any live key is still bound to it, so revoke or rebind those keys first.

Note

A connection bot must be a mailbox in your own Microsoft 365 tenant — Microsoft 365 data is tenant-isolated, so Strata can't act on a mailbox your organization doesn't own. A low-cost shared-mailbox seat is enough.

The Atlassian actor

Jira and Confluence aren't Microsoft services, so they have no connection bot — there's no mailbox to sign in as. Which identity an Atlassian-scoped key acts as depends on the connection mode your organization picked under Settings → Extensions → Atlassian → Manage, which covers both products through the single Atlassian connection. In each person signs in mode, the key's bound actor must have connected their own Atlassian account, and the key sees exactly what that person sees in Jira and Confluence. In one organization account mode, the org's Atlassian service account is the identity, so it satisfies the connect-first check for every actor — including an auto-provisioned service account that never signs in. See Atlassian extensions.

jira.write on a key is necessary but not sufficient: Jira writes must also resolve on for the key's actor, or the write tools are never handed to the key. That means your organization's writes toggle on, and neither the actor's role nor their own Jira writes override set to Denied — see Who may write. And an API-key run has nobody to prompt, so the approval step a member sees in chat is skipped and the write goes through. Both the role capability and the per-member override live alongside the extension allow-lists that decide whether the actor can carry Jira at all, under Admin → Roles and Admin → Users → (manage user) → Extensions & Data. Every write is recorded in the audit log as jira.issue_created or jira.comment_added.

confluence.write clears the same bar against Confluence's own three layers, and the two products are scoped independently: confluence.read never implies confluence.write, and a jira.* scope carries no Confluence access at all. Confluence writes land in the audit log as confluence.page_created or confluence.comment_added.

See Extension access for what each extension scope grants and the security guardrails (external sends become drafts, SQL is capped below admin, tenant isolation).

The API keys table

Each row represents one active key. Columns:

Use the search box to filter by key name, prefix, or creator email. Status and Creator dropdowns narrow further.

Key details and settings

Click a row or select View details from the row menu to open the key's detail modal. Here you see:

• Full metadata (scopes, rate limit, budget, expiration)
• Actor (the user this key is attributed to)
• Created and last-used timestamps
• Rotation history (if the key has been rotated)
• Usage this billing cycle (tokens and calls)

Select Edit settings to rename the key, adjust scopes or allowed models, change the rate limit or budget, toggle pool participation, or update the expiration date. Changes take effect immediately on all new requests. A revoked key cannot be edited — revoke and mint a new one instead.

Revoking and rotating

Revoke — click the row menu, select Revoke, and confirm. The key becomes invalid immediately; the row disappears from the table. Revocation is final — a revoked key cannot be reactivated. The full audit trail remains in the audit log.

Rotate — to safely roll over a key (e.g., if you suspect it was exposed), select Rotate key. Strata mints a new key with the same settings and begins a 24-hour grace period during which both the old and new keys work. When grace expires, the old key auto-revokes. The new key's raw value is displayed once — copy it immediately.

Per-key webhooks

API keys can deliver event notifications to your infrastructure via webhooks. Configure them in the key's detail modal under the Webhooks section.

Adding a webhook endpoint

1. Click Add webhook in the key detail modal.
2. Select the event type — currently key.revoked (fired when this key is revoked).
3. Enter the webhook URL (your HTTPS endpoint that will receive POST requests).
4. Click Add. Strata displays the webhook signing secret — copy it now; you'll only see it once.

Webhook format and signing

Strata POSTs JSON to your endpoint with these headers:

The body wraps the event payload under a data object:

{
  "event_id": "f1e2d3c4-...",
  "event_type": "key.revoked",
  "timestamp": 1717520000,
  "data": {
    "key_id": "...",
    "prefix": "sk_strata_live_4f2a8e9c0b3d1e5a",
    "name": "My integration key",
    "revoked_at": "2026-06-24T14:30:00Z",
    "reason": null,
    "grace_period_ends_at": null
  }
}

Validating signatures

To verify the webhook came from Strata:

1. Read the Strata-Timestamp header and the raw request body (exact bytes — do not re-serialize parsed JSON).
2. Concatenate them as {timestamp}.{rawBody}.
3. Compute HMAC-SHA256 over that string using your webhook secret as the key.
4. Compare (constant-time) to the hex value after sha256= in the Strata-Signature header.

Example in Node.js:

const crypto = require('crypto');

function verifyWebhook(rawBody, timestamp, signatureHeader, secret) {
  const message = `${timestamp}.${rawBody}`;
  const expected = crypto
    .createHmac('sha256', secret)
    .update(message, 'utf8')
    .digest('hex');
  const received = (signatureHeader || '').replace(/^sha256=/, '');
  if (received.length !== expected.length) return false;
  return crypto.timingSafeEqual(
    Buffer.from(received, 'hex'),
    Buffer.from(expected, 'hex')
  );
}

Delivery, retries, and replay protection

Always validate the timestamp — reject any webhook more than 5 minutes old to prevent replay attacks. Respond with a 2xx status to acknowledge receipt. If your endpoint fails, Strata retries with exponential backoff over up to six attempts (immediate, then +1 min, +5 min, +30 min, +2 hr, +12 hr), replaying the exact same body, event ID, and signature each time. After repeated consecutive failures the webhook is auto-disabled and flagged in the admin UI so you can investigate and re-enable it.

API authentication

API keys authenticate to Strata using HTTP Bearer tokens in the Authorization header:

GET /v1/conversations HTTP/1.1
Host: app.strata.kronisys.com
Authorization: Bearer sk_strata_live_4f2a8e9c0b3d1e5a<rest_of_key>
Content-Type: application/json

Keys are scoped to your organization: a key only ever operates within the org it was minted in. Resources that belong to a different org (files, conversations) are invisible to it — a request for one returns 404 Not Found, never another org's data. (Requests from a key whose org has been suspended are rejected with 403 Forbidden.)

For full API authentication details and request examples, see API authentication and API overview.

Permissions and limits

• View keys: requires canManageApiKeys permission.
• Create, edit, rotate, revoke: requires canManageApiKeys permission.
• Key name length: 1–120 characters; must be unique per org.
• Scopes: at least one of chat, files, excel, pdf, pptx, docx.
• Models: at least one chat model the org has enabled; voice, transcription, and embedding models are not selectable.
• Rate limit per hour: 1–1,000,000 requests.
• Monthly token budget: blank (no cap) or any non-negative integer; defaults to 5,000,000.
• Expiration: optional; if set, must be in the future and within 5 years.
• Rotation grace window: up to 720 hours (default 24).

What happens when a key expires

On the expiration date, the key's status changes to expired. The key stops working — any request with that key is rejected with a 401 Unauthorized error. The key remains in the table and audit log indefinitely, but you cannot reactivate it. If you need access again, mint a fresh key.

Troubleshooting

Related

• API authentication — how keys authenticate to the Strata API
• API overview — base URL, versioning, and first call
• Audit log — view all key creation, rotation, and revocation events
• Roles and permissions — manage the canManageApiKeys permission