# Get dashboard analytics Source: https://docs.app.strix.ai/api-reference/analytics/get-dashboard-analytics /openapi.json get /analytics/stats Aggregate counts powering the dashboard (scans, vulnerabilities by severity/status, and more). Accepts the same filter query params as the dashboard. Asset-scoped tokens cannot access organization-wide analytics. # Get dashboard overview Source: https://docs.app.strix.ai/api-reference/analytics/get-dashboard-overview /openapi.json get /analytics/overview Unified dashboard overview: KPIs with period-over-period deltas, issues-over-time by source (pentests vs PR reviews), severity breakdown, PR review effectiveness (distinct PRs, verdicts, addressed rate, top repos and contributors), remediation trends, exploitability (KEV/EPSS) of open issues and active dependency CVEs, threat intelligence feed (recently exploited and high-risk CVEs, flagged when they match your open issues), and activity heatmap. Asset-scoped tokens cannot access organization-wide analytics. # Get scan frequency timeline Source: https://docs.app.strix.ai/api-reference/analytics/get-scan-frequency-timeline /openapi.json get /analytics/scan-frequency Daily scan counts for roughly the last 10 months, suitable for a contribution-style heatmap. Asset-scoped tokens cannot access organization-wide analytics. # Add a domain Source: https://docs.app.strix.ai/api-reference/assets/add-a-domain /openapi.json post /domains Register a domain asset for the authenticated organization and return verification instructions. # Add repositories Source: https://docs.app.strix.ai/api-reference/assets/add-repositories /openapi.json post /repositories Register one or more repository assets for the authenticated organization. # List domains Source: https://docs.app.strix.ai/api-reference/assets/list-domains /openapi.json get /domains Returns a paginated list of domains for the authenticated organization. # List repositories Source: https://docs.app.strix.ai/api-reference/assets/list-repositories /openapi.json get /repositories Returns a paginated list of repositories for the authenticated organization. # Remove a domain Source: https://docs.app.strix.ai/api-reference/assets/remove-a-domain /openapi.json delete /domains/{domainId} # Remove a repository Source: https://docs.app.strix.ai/api-reference/assets/remove-a-repository /openapi.json delete /repositories/{repositoryId} # Update a domain Source: https://docs.app.strix.ai/api-reference/assets/update-a-domain /openapi.json patch /domains/{domainId} Update a domain's context, tags, or business_unit. Tags and business_unit require the Enterprise plan. # Update repository settings Source: https://docs.app.strix.ai/api-reference/assets/update-repository-settings /openapi.json patch /repositories/{repositoryId} # Verify a domain Source: https://docs.app.strix.ai/api-reference/assets/verify-a-domain /openapi.json post /domains/{domainId}/verify Checks DNS, verification file, meta tag, allowlist, and existing organization verification methods. # Verify a domain through a connected DNS provider Source: https://docs.app.strix.ai/api-reference/assets/verify-a-domain-through-a-connected-dns-provider /openapi.json post /domains/{domainId}/auto-verify Creates the _strix-verification TXT record through the organization's connected DNS provider (Vercel or Cloudflare) and runs the DNS verification check. Requires an organization admin to have connected the provider in the dashboard first. # List audit events Source: https://docs.app.strix.ai/api-reference/audit/list-audit-events /openapi.json get /audit Returns enterprise audit events for the authenticated organization, with optional CSV, Snowflake NDJSON, or Splunk NDJSON export formats. # Buy credits with a machine payment Source: https://docs.app.strix.ai/api-reference/billing/buy-credits-with-a-machine-payment /openapi.json post /billing/topup Buy scan credits with the Machine Payments Protocol (MPP). Authenticate with `X-Strix-Authorization: Bearer ` because MPP uses the standard Authorization header for its payment credential. The first request without a payment credential returns HTTP 402 with a payment challenge. Pay the challenge with a Stripe agent wallet (https://link.com/agents), then retry the request with the payment credential. The user approves each payment in the Link app. If the user does not want a wallet, create a hosted checkout link with the billing checkout operation instead. A verified payment grants the credits one time and returns a receipt. Requires the billing:write scope and the admin role. # Create a billing portal link Source: https://docs.app.strix.ai/api-reference/billing/create-a-billing-portal-link /openapi.json post /billing/portal Create a hosted billing portal link. A person must open the link to change the payment method or the subscription. Requires the admin role and the billing:write scope. # Create a checkout link Source: https://docs.app.strix.ai/api-reference/billing/create-a-checkout-link /openapi.json post /billing/checkout Create a hosted checkout link for a plan or a credit pack. A person must open the link and complete the payment. Requires the admin role and the billing:write scope. # Get automatic top-up settings Source: https://docs.app.strix.ai/api-reference/billing/get-automatic-top-up-settings /openapi.json get /billing/auto-topup Get the automatic top-up settings for the organization. Requires the billing:read scope, an unscoped token, and the admin role. # Get the credit balance Source: https://docs.app.strix.ai/api-reference/billing/get-the-credit-balance /openapi.json get /billing/credits Get the current top-up credit balance for the organization. Requires the billing:read scope. # Update automatic top-up settings Source: https://docs.app.strix.ai/api-reference/billing/update-automatic-top-up-settings /openapi.json put /billing/auto-topup Update the automatic top-up settings for the organization. Automatic top-up charges the saved payment method when a scan needs more credits. Requires the billing:write scope and the admin role. # Arm a chat with engagement credentials Source: https://docs.app.strix.ai/api-reference/chat/arm-a-chat-with-engagement-credentials /openapi.json post /chat/{chatId}/credentials Attaches saved domain test users and/or credentials supplied in the request to a chat, so its agent can authenticate to the target. Values are encrypted at rest and handed only to the chat's trusted orchestrator, where host-side auth tools expose derived values (a resolved login, a TOTP code) to the agent; they never enter the chat transcript, the model context, or the agent sandbox. Re-attaching an account replaces it. Recorded as a chat.credentials.attached audit event. # Create a chat share link Source: https://docs.app.strix.ai/api-reference/chat/create-a-chat-share-link /openapi.json post /chat/{chatId}/share Generates a public, read-only share URL for the chat. # Download a chat's whole workspace as a zip Source: https://docs.app.strix.ai/api-reference/chat/download-a-chats-whole-workspace-as-a-zip /openapi.json get /chat/{chatId}/files/archive Streams every file in the running chat agent's /workspace as a zip archive using safe relative POSIX entry names. Production follows response backpressure and aborts in-flight sandbox downloads if the consumer disconnects, so the whole archive is never buffered. Export is rejected before streaming when the workspace listing exceeds 2 MiB or 10,000 entries, any file is over 50 MiB, or advertised content exceeds 512 MiB total. Each file response is bounded before JSON parsing and base64 decoding, and the stream fails instead of returning a partial archive if a file grows beyond 50 MiB after listing, actual total content exceeds 512 MiB, a file cannot be read, or the 30-second archive deadline expires. # Download a file from a chat's workspace Source: https://docs.app.strix.ai/api-reference/chat/download-a-file-from-a-chats-workspace /openapi.json get /chat/{chatId}/files/download Downloads one file (max 50 MiB) from the running chat agent's /workspace. The bridge response is bounded before JSON parsing and base64 decoding. # File a chat finding into the organization's issues Source: https://docs.app.strix.ai/api-reference/chat/file-a-chat-finding-into-the-organizations-issues /openapi.json post /chat/{chatId}/findings/{findingId}/file Adds a chat-discovered finding to the organization's issue list. Idempotent: re-filing returns the same finding. When the organization already tracks an equivalent finding (same title, target and endpoint), the finding is left unfiled and duplicate_of identifies the existing issue. Recorded as a chat.finding.filed audit event. # Get a chat Source: https://docs.app.strix.ai/api-reference/chat/get-a-chat /openapi.json get /chat/{chatId} # Get a finding reported in a chat Source: https://docs.app.strix.ai/api-reference/chat/get-a-finding-reported-in-a-chat /openapi.json get /chat/{chatId}/findings/{findingId} Returns the complete vulnerability row for a finding reported in the chat. The row includes findings that are not filed in the organization's issue list. # List a chat's engagement credentials Source: https://docs.app.strix.ai/api-reference/chat/list-a-chats-engagement-credentials /openapi.json get /chat/{chatId}/credentials Returns metadata for the credentials armed on a chat plus the saved domain test users the caller may attach. Secret material (passwords, TOTP seeds) is never returned. # List chats Source: https://docs.app.strix.ai/api-reference/chat/list-chats /openapi.json get /chat Most recent chats for the organization (up to 50). # List exportable files in a chat's workspace Source: https://docs.app.strix.ai/api-reference/chat/list-exportable-files-in-a-chats-workspace /openapi.json get /chat/{chatId}/files Lists files in the running chat agent's /workspace so artifacts (reports, PoCs, generated files) can be exported. The sandbox response is limited to 2 MiB and 10,000 entries before JSON normalization. # List the findings an agent reported in a chat Source: https://docs.app.strix.ai/api-reference/chat/list-the-findings-an-agent-reported-in-a-chat /openapi.json get /chat/{chatId}/findings Findings discovered inside a chat are exploratory and stay out of the organization's issue lists until a member files one; filed_at reflects that state. # Re-scope a chat to verified domains Source: https://docs.app.strix.ai/api-reference/chat/re-scope-a-chat-to-verified-domains /openapi.json put /chat/{chatId}/domains Replaces the verified organization domains a chat is authorized against, including while it is running: the domains are re-validated (owned, verified, inside the caller's access scopes), persisted, and pushed to the running agent, which re-labels proxy traffic and is told its scope changed. An empty list restores organization-wide authorization. # Revoke a chat's engagement credentials Source: https://docs.app.strix.ai/api-reference/chat/revoke-a-chats-engagement-credentials /openapi.json delete /chat/{chatId}/credentials Clears every credential armed on the chat, in storage and in the running orchestrator. Recorded as a chat.credentials.revoked audit event. # Run a command in a chat's agent sandbox Source: https://docs.app.strix.ai/api-reference/chat/run-a-command-in-a-chats-agent-sandbox /openapi.json post /chat/{chatId}/terminal Executes one non-interactive command inside the chat agent's sandbox, starting from a directory under /workspace. Execution time and output size are capped by the runtime, and every attempt is recorded as a chat.terminal.command audit event. # Send a chat message Source: https://docs.app.strix.ai/api-reference/chat/send-a-chat-message /openapi.json post /chat/{chatId}/message Sends a message to an active chat. Use `application/json` for text-only, or `multipart/form-data` to attach files. `message` may be omitted for a control-only request when `cancel_current` or `stop_agent` is true. # Start a chat Source: https://docs.app.strix.ai/api-reference/chat/start-a-chat /openapi.json post /chat Starts a new agent chat. Use `application/json` for text-only, or `multipart/form-data` to attach files (field `files`). # Change current CLI session scopes Source: https://docs.app.strix.ai/api-reference/cli/change-current-cli-session-scopes /openapi.json patch /cli/session Change the saved scope profile or custom requested scopes without exceeding the immutable ceiling approved at login. Broader access requires a new browser sign-in. # Complete an interactive CLI sign-in Source: https://docs.app.strix.ai/api-reference/cli/complete-an-interactive-cli-sign-in /openapi.json post /cli/login/complete Finish an interactive CLI sign-in after the user picks a workspace and scopes. Send the `selection_token` from the poll response. The workspace must be one of the user's memberships. The server always includes the minimum scopes and the member's role limits the final set. When `workspace_name` is present, the server checks that the user is an admin, mints the token, and then renames the chosen workspace. A failed rename does not fail the sign-in. The selection token expires after 10 minutes. This endpoint does not require authentication. # Explain the CLI sign-in endpoint Source: https://docs.app.strix.ai/api-reference/cli/explain-the-cli-sign-in-endpoint /openapi.json get /cli/login Browsers sometimes open this URL. The endpoint accepts POST only, so this GET performs no action. It returns 405 with an Allow header and a short explanation. The body is HTML when the Accept header includes text/html, otherwise JSON. This endpoint does not require authentication. # Explain the CLI sign-in poll endpoint Source: https://docs.app.strix.ai/api-reference/cli/explain-the-cli-sign-in-poll-endpoint /openapi.json get /cli/login/poll Browsers sometimes open this URL. The endpoint accepts POST only, so this GET performs no action. It returns 405 with an Allow header and a short explanation. The body is HTML when the Accept header includes text/html, otherwise JSON. This endpoint does not require authentication. # Get the current CLI session Source: https://docs.app.strix.ai/api-reference/cli/get-the-current-cli-session /openapi.json get /cli/session Inspect the authenticated CLI device session, its effective scopes, saved scope preference, and immutable login consent ceiling. No API scope is required; the bearer must be a personal Strix CLI session. # Poll a CLI sign-in Source: https://docs.app.strix.ai/api-reference/cli/poll-a-cli-sign-in /openapi.json post /cli/login/poll Exchange a device code for a personal API token. While the user has not approved the sign-in, the response is 400 with an `error` field of `authorization_pending` or `slow_down` — wait for the returned interval and poll again. `access_denied` and `expired_token` are terminal. On approval, the endpoint provisions the user and a default organization when needed, and returns a personal API token with a 90 day expiry. Set `interactive` to true to get a workspace list and a scope catalog instead of a token, then finish with POST /cli/login/complete. This endpoint does not require authentication. # Revoke the current CLI session Source: https://docs.app.strix.ai/api-reference/cli/revoke-the-current-cli-session /openapi.json delete /cli/session Revoke the authenticated CLI session itself. No token-management scope is required. # Start a CLI sign-in Source: https://docs.app.strix.ai/api-reference/cli/start-a-cli-sign-in /openapi.json post /cli/login Start the OAuth 2.0 device authorization flow (RFC 8628). The response contains a user code and a verification URL. Show both to the user, then poll POST /cli/login/poll with the device code. This endpoint does not require authentication. # Create a network connector Source: https://docs.app.strix.ai/api-reference/connectors/create-a-network-connector /openapi.json post /connectors Provisions a connector and returns a `docker run` command to start the agent inside the customer network. Requires a tier with network connectors enabled. Personal tokens must belong to an organization admin (parity with the dashboard). # Delete a network connector Source: https://docs.app.strix.ai/api-reference/connectors/delete-a-network-connector /openapi.json delete /connectors/{connectorId} Deletes the connector and revokes its devices. Personal tokens must belong to an organization admin (parity with the dashboard). # Get a network connector Source: https://docs.app.strix.ai/api-reference/connectors/get-a-network-connector /openapi.json get /connectors/{connectorId} # Get live connector status Source: https://docs.app.strix.ai/api-reference/connectors/get-live-connector-status /openapi.json get /connectors/{connectorId}/status Queries the connector's live health and updates the stored status. # List network connectors Source: https://docs.app.strix.ai/api-reference/connectors/list-network-connectors /openapi.json get /connectors # Add a cloud project connection Source: https://docs.app.strix.ai/api-reference/integrations/add-a-cloud-project-connection /openapi.json post /integrations/cloud/{id}/projects Adds a project under an existing cloud connection. The source connection must own a provider credential. # Connect bitbucket with a token Source: https://docs.app.strix.ai/api-reference/integrations/connect-bitbucket-with-a-token /openapi.json post /integrations/bitbucket/connect Connects Bitbucket with an API token. Personal tokens must belong to an organization admin (parity with the dashboard). # Connect gitlab with a token Source: https://docs.app.strix.ai/api-reference/integrations/connect-gitlab-with-a-token /openapi.json post /integrations/gitlab/connect Connects GitLab with a personal access token. Personal tokens must belong to an organization admin (parity with the dashboard). # Create an installation link Source: https://docs.app.strix.ai/api-reference/integrations/create-an-installation-link /openapi.json post /integrations/{provider}/install-url Create the hosted installation link for one provider. A person must open the link and approve the access. The github provider returns a GitHub App installation link. The slack provider returns a Slack authorization link. Requires the admin role and the integrations:write scope. # Disconnect an integration Source: https://docs.app.strix.ai/api-reference/integrations/disconnect-an-integration /openapi.json delete /integrations/{provider} Disconnects the integration for the organization. `installation_id` is required for GitHub, GitLab, and Bitbucket, which may have multiple installations; omit it for organization-wide providers such as Slack. Personal tokens must belong to an organization admin (parity with the dashboard). # List cloud connections Source: https://docs.app.strix.ai/api-reference/integrations/list-cloud-connections /openapi.json get /integrations/cloud Returns the cloud connections available to scans in the organization. # List integrations Source: https://docs.app.strix.ai/api-reference/integrations/list-integrations /openapi.json get /integrations Connected SCM installations, ticketing accounts, and OAuth availability. # Reject an unsupported token-based integration provider Source: https://docs.app.strix.ai/api-reference/integrations/reject-an-unsupported-token-based-integration-provider /openapi.json post /integrations/{provider}/connect Authenticated JSON fallback for provider identifiers other than the dedicated GitLab and Bitbucket connect routes. Always returns 400 after scope and admin checks. # Reject an unsupported token-validation provider Source: https://docs.app.strix.ai/api-reference/integrations/reject-an-unsupported-token-validation-provider /openapi.json post /integrations/{provider}/validate Authenticated JSON fallback for provider identifiers other than the dedicated GitLab and Bitbucket validation routes. Always returns 400 after scope and admin checks. # Validate a bitbucket token Source: https://docs.app.strix.ai/api-reference/integrations/validate-a-bitbucket-token /openapi.json post /integrations/bitbucket/validate Checks a personal access token without persisting it. Personal tokens must belong to an organization admin (parity with the dashboard). # Validate a gitlab token Source: https://docs.app.strix.ai/api-reference/integrations/validate-a-gitlab-token /openapi.json post /integrations/gitlab/validate Checks a personal access token without persisting it. Personal tokens must belong to an organization admin (parity with the dashboard). # List pending invitations Source: https://docs.app.strix.ai/api-reference/invitations/list-pending-invitations /openapi.json get /organization/invitations # Revoke invitation Source: https://docs.app.strix.ai/api-reference/invitations/revoke-invitation /openapi.json delete /organization/invitations/{invitationId} # Create a knowledge document Source: https://docs.app.strix.ai/api-reference/knowledge/create-a-knowledge-document /openapi.json post /knowledge Manage organization knowledge. Organization-global knowledge writes are not available to asset-scoped tokens. # Create or update a knowledge policy Source: https://docs.app.strix.ai/api-reference/knowledge/create-or-update-a-knowledge-policy /openapi.json post /knowledge/policies Creates or updates an organization knowledge policy. Personal tokens must belong to an organization admin (parity with the dashboard). Organization-global knowledge writes are not available to asset-scoped tokens. # Delete a knowledge document Source: https://docs.app.strix.ai/api-reference/knowledge/delete-a-knowledge-document /openapi.json delete /knowledge/{documentId} Manage organization knowledge. Organization-global knowledge writes are not available to asset-scoped tokens. # Delete a knowledge policy Source: https://docs.app.strix.ai/api-reference/knowledge/delete-a-knowledge-policy /openapi.json delete /knowledge/policies/{policyKey} Deletes an organization knowledge policy. Personal tokens must belong to an organization admin (parity with the dashboard). Organization-global knowledge writes are not available to asset-scoped tokens. # List knowledge documents Source: https://docs.app.strix.ai/api-reference/knowledge/list-knowledge-documents /openapi.json get /knowledge # List knowledge entries for a repository Source: https://docs.app.strix.ai/api-reference/knowledge/list-knowledge-entries-for-a-repository /openapi.json get /knowledge/repos/{repo}/entries # List knowledge policies Source: https://docs.app.strix.ai/api-reference/knowledge/list-knowledge-policies /openapi.json get /knowledge/policies # List repository knowledge profiles Source: https://docs.app.strix.ai/api-reference/knowledge/list-repository-knowledge-profiles /openapi.json get /knowledge/repos # Update a knowledge document Source: https://docs.app.strix.ai/api-reference/knowledge/update-a-knowledge-document /openapi.json patch /knowledge/{documentId} Manage organization knowledge. Organization-global knowledge writes are not available to asset-scoped tokens. # Update a repository knowledge profile Source: https://docs.app.strix.ai/api-reference/knowledge/update-a-repository-knowledge-profile /openapi.json patch /knowledge/repos/{repo}/profile Update a repository knowledge profile. Asset-scoped tokens may update profiles only for repositories covered by their token scopes. # Get license status Source: https://docs.app.strix.ai/api-reference/license/get-license-status /openapi.json get /license License state for self-hosted installs: whether licensing is enforced, the current state (unlicensed/valid/expired/grace_exceeded/invalid), signed entitlements (seat, domain, repo, developer, pentest, and concurrency limits plus feature flags), expiry, and install-wide aggregate usage counts. Licenses are verified offline from a signed token, so there is no sync (last_synced_at is always null). On SaaS this always reports enforced=false. Requires the license:read scope. Personal tokens must belong to an org admin (service tokens are admin-issued and exempt). # Get LLM costs overview Source: https://docs.app.strix.ai/api-reference/llm/get-llm-costs-overview /openapi.json get /llm-costs Self-hosted (on-prem) only — returns 404 on SaaS. Full LLM spend analytics: KPIs with period deltas, month-to-date and projected burn, cost and token timelines, breakdowns by model/asset/member, most expensive runs, and cache efficiency. Requires an unrestricted token (tokens limited by rbac scopes are rejected). # Get LLM model settings Source: https://docs.app.strix.ai/api-reference/llm/get-llm-model-settings /openapi.json get /llm-settings Self-hosted (on-prem) only — returns 404 on SaaS. Requires the organization admin role. Named model configurations (API keys and extra headers are never returned, only whether they are set), per-purpose model assignments (default, scan, pr_review, chat, dedupe, app), env-fallback models per purpose, and current month-to-date spend per run type. # Get LLM usage for a run Source: https://docs.app.strix.ai/api-reference/llm/get-llm-usage-for-a-run /openapi.json get /llm-costs/runs/{runType}/{runId} Self-hosted (on-prem) only — returns 404 on SaaS. Cost, token, and request totals recorded for a single scan, PR review, or chat run. `usage` is null until the run has reported cost. Requires an unrestricted token (tokens limited by rbac scopes are rejected). # Update LLM model settings Source: https://docs.app.strix.ai/api-reference/llm/update-llm-model-settings /openapi.json put /llm-settings Self-hosted (on-prem) only — returns 404 on SaaS. Requires the organization admin role. Full-state save of model configurations and per-purpose assignments. Include `apiKey` on a model config to set or replace its key (stored encrypted). Omit it to keep the existing key. Same for `extraHeaders` (an empty string clears the stored value). # Invite organization member Source: https://docs.app.strix.ai/api-reference/members/invite-organization-member /openapi.json post /organization/members # List organization members Source: https://docs.app.strix.ai/api-reference/members/list-organization-members /openapi.json get /organization/members # Remove member Source: https://docs.app.strix.ai/api-reference/members/remove-member /openapi.json delete /organization/members/{membershipId} # Update member role Source: https://docs.app.strix.ai/api-reference/members/update-member-role /openapi.json patch /organization/members/{membershipId} # Get notification settings Source: https://docs.app.strix.ai/api-reference/organization/get-notification-settings /openapi.json get /settings/notifications Returns the organization's notification settings, including SLA deadline reminder configuration. # Get organization Source: https://docs.app.strix.ai/api-reference/organization/get-organization /openapi.json get /organization Returns workspace configuration for the authenticated token organization. # Update notification settings Source: https://docs.app.strix.ai/api-reference/organization/update-notification-settings /openapi.json patch /settings/notifications Update the organization's notification settings (admin only). Enable SLA deadline reminders and choose email/Slack delivery and the warning period. # Update organization Source: https://docs.app.strix.ai/api-reference/organization/update-organization /openapi.json patch /organization Rename the authenticated token organization. # Get a PR review Source: https://docs.app.strix.ai/api-reference/pr-reviews/get-a-pr-review /openapi.json get /pr-reviews/{prReviewId} Fetches a PR review with its findings. Results are limited to repositories within the token's rbac scopes. # Get PR review settings Source: https://docs.app.strix.ai/api-reference/pr-reviews/get-pr-review-settings /openapi.json get /pr-reviews/settings # List PR reviews Source: https://docs.app.strix.ai/api-reference/pr-reviews/list-pr-reviews /openapi.json get /pr-reviews Lists PR reviews for the organization. Results include only repositories within the token RBAC scopes. # List security issues caught by PR reviews Source: https://docs.app.strix.ai/api-reference/pr-reviews/list-security-issues-caught-by-pr-reviews /openapi.json get /pr-reviews/findings Lists every security issue that the organization's PR reviews caught. Each issue appears once. Repeated reports of the same issue across review runs of one pull request are collapsed. Dependency CVEs and retest rows are excluded. Results include only repositories within the token RBAC scopes. # Start a PR review Source: https://docs.app.strix.ai/api-reference/pr-reviews/start-a-pr-review /openapi.json post /pr-reviews/start Triggers a security review of a specific pull request. The target repository must be within the token's rbac scopes. # Update PR review settings Source: https://docs.app.strix.ai/api-reference/pr-reviews/update-pr-review-settings /openapi.json patch /pr-reviews/settings Updates organization PR review settings. Personal tokens must belong to an organization admin (parity with the dashboard). # Cancel a scan Source: https://docs.app.strix.ai/api-reference/scans/cancel-a-scan /openapi.json post /scans/{scanId}/cancel Cancel a pending or running scan. Credits may be refunded if cancelled within 5 minutes. # Create a scan Source: https://docs.app.strix.ai/api-reference/scans/create-a-scan /openapi.json post /scans Launch a new penetration test scan against the specified targets. For retry-safe at-most-once creation, send an Idempotency-Key and reuse the exact same key and request after a lost or ambiguous response. The key is optional for backward compatibility, retained for 24 hours, and cannot be reused with a different actor, operation, or payload. A terminal response is replayed only after the caller still passes current target/resource authorization; revoked access returns a fresh 403/404 without exposing the receipt. Use a new key only for a deliberate new attempt. # Delete a scan Source: https://docs.app.strix.ai/api-reference/scans/delete-a-scan /openapi.json delete /scans/{scanId} Permanently deletes a scan and its findings. # Download scan report Source: https://docs.app.strix.ai/api-reference/scans/download-scan-report /openapi.json get /scans/{scanId}/report Generate and download a report for a completed scan. Report downloads require an Enterprise plan. # Download scan SARIF Source: https://docs.app.strix.ai/api-reference/scans/download-scan-sarif /openapi.json get /scans/{scanId}/sarif Generate a SARIF 2.1.0 export for active vulnerabilities on a scan. # Get a scan as a reusable template Source: https://docs.app.strix.ai/api-reference/scans/get-a-scan-as-a-reusable-template /openapi.json get /scans/{scanId}/template Returns the scan's configuration shaped for starting a new, similar scan. Credentials are returned as metadata only (username, notes, MFA method, has_stored_secret) — raw secrets such as passwords, TOTP seeds, MFA inboxes, and login URLs are never included. Use test_user_ids with POST /scans to reuse saved test users. Their secrets are rehydrated server-side. # Get scan details Source: https://docs.app.strix.ai/api-reference/scans/get-scan-details /openapi.json get /scans/{scanId} Returns full scan details including associated vulnerabilities. A pentest's list omits dependency CVE findings. A supply-chain scan's findings are all dependency CVEs. The response embeds them only when the token also holds the `dependencies:read` scope. Without that scope, the list is empty. # List scan retests Source: https://docs.app.strix.ai/api-reference/scans/list-scan-retests /openapi.json get /scans/{scanId}/retests Lists retest scans spawned from this scan. # List scans Source: https://docs.app.strix.ai/api-reference/scans/list-scans /openapi.json get /scans Returns a paginated list of scans for the authenticated organization. Each scan carries finding counts. A pentest's counts omit dependency CVE findings. A supply-chain scan's findings are all dependency CVEs, so its counts are nonzero only when the token also holds the `dependencies:read` scope. # List the agents of a scan Source: https://docs.app.strix.ai/api-reference/scans/list-the-agents-of-a-scan /openapi.json get /scans/{scanId}/agents Lists the agents that ran in this scan, with the task, status, parent agent, and finding count of each agent. Use the returned agent id with GET /scans/{scanId}/trace to read what one agent did. # Read one agent's trace Source: https://docs.app.strix.ai/api-reference/scans/read-one-agents-trace /openapi.json get /scans/{scanId}/trace Returns one page of an agent's steps, oldest first. A step is an agent message, a tool call, a tool result, or a reported finding. Long payloads are shortened and marked with truncated. To read a shortened payload in full, call GET /scans/{scanId}/trace/{eventId} with the step's event_id. To read the next page, send the returned cursor value. If the response contains a note field, the trace is incomplete and the note tells you why. # Read one trace step in full Source: https://docs.app.strix.ai/api-reference/scans/read-one-trace-step-in-full /openapi.json get /scans/{scanId}/trace/{eventId} Returns the complete payload of one trace step. Use this endpoint when the trace returned the step with truncated set to true. # Rename a scan Source: https://docs.app.strix.ai/api-reference/scans/rename-a-scan /openapi.json patch /scans/{scanId} Sets a new scan title. The server trims the title and accepts 1 to 120 characters. # Rerun a scan Source: https://docs.app.strix.ai/api-reference/scans/rerun-a-scan /openapi.json post /scans/{scanId}/rerun Create a new scan with the same configuration as the specified scan. For retry-safe at-most-once creation, send an Idempotency-Key and reuse the exact same key and request after a lost or ambiguous response. The key is optional for backward compatibility, retained for 24 hours, and cannot be reused with a different actor, operation, or source scan. A terminal response is replayed only after the caller still passes current source-scan authorization; revoked access returns a fresh 403/404 without exposing the receipt. Use a new key only for a deliberate new rerun. # Retest all findings Source: https://docs.app.strix.ai/api-reference/scans/retest-all-findings /openapi.json post /scans/{scanId}/retest-all Starts a retest covering all of the scan's findings. # Send a scan message Source: https://docs.app.strix.ai/api-reference/scans/send-a-scan-message /openapi.json post /scans/{scanId}/message Sends a live prompt to a running scan. `message` is required unless `cancel_current` is true. You must provide at least one of these fields. # Upload scan SARIF to GitHub Source: https://docs.app.strix.ai/api-reference/scans/upload-scan-sarif-to-github /openapi.json post /scans/{scanId}/sarif Generate SARIF for active scan vulnerabilities and upload it to GitHub code scanning. Requires an Enterprise plan. # Create a schedule Source: https://docs.app.strix.ai/api-reference/schedules/create-a-schedule /openapi.json post /schedules Create a recurring scan schedule. Optionally trigger an immediate scan with `also_run_now`. Supply Chain schedules require the Enterprise Supply Chain entitlement. When `also_run_now` creates a chargeable scan, the optional Idempotency-Key covers both schedule creation and that immediate scan; reuse the exact same key only to retry the exact same request. Replay and in-progress responses are still subject to current authorization against the persisted schedule when it exists. # Delete a schedule Source: https://docs.app.strix.ai/api-reference/schedules/delete-a-schedule /openapi.json delete /schedules/{scheduleId} # Get a schedule's editable configuration Source: https://docs.app.strix.ai/api-reference/schedules/get-a-schedules-editable-configuration /openapi.json get /schedules/{scheduleId}/template Returns the full stored configuration of the schedule, in a format that you can edit with PATCH /schedules/{scheduleId} — targets, prompts, test users, headers, scope, timing, notifications, and uploads. Credentials are returned as metadata only (username, notes, MFA method, has_stored_secret) and headers as metadata only (name, notes, has_stored_value) — raw secrets such as passwords, TOTP seeds, header values, MFA inboxes, and login URLs are never included. Keep a stored header value on PATCH by sending keep_stored_value: true. # Get schedule details Source: https://docs.app.strix.ai/api-reference/schedules/get-schedule-details /openapi.json get /schedules/{scheduleId} Returns schedule details including recent run history. # List schedules Source: https://docs.app.strix.ai/api-reference/schedules/list-schedules /openapi.json get /schedules Returns all scan schedules for the organization. Requires Pro plan. # Trigger a schedule immediately Source: https://docs.app.strix.ai/api-reference/schedules/trigger-a-schedule-immediately /openapi.json post /schedules/{scheduleId}/trigger Trigger an immediate run of a scheduled scan. Stored Supply Chain schedules require the Enterprise Supply Chain entitlement. A 200 acknowledges durable queue acceptance; later execution failures are reported in the schedule's run health and are never silently launched a second time. Manual schedule fires support the optional Idempotency-Key contract used by scan creation: reuse the exact same key only to retry the same schedule trigger after a lost or ambiguous response. Replay and in-progress responses are returned only after current authorization against the schedule succeeds. # Update a schedule Source: https://docs.app.strix.ai/api-reference/schedules/update-a-schedule /openapi.json patch /schedules/{scheduleId} Update a schedule's configuration, cron expression, or pause/resume it. Send `action: "pause"` or `action: "resume"` to toggle, or provide fields to update. # Export repository SBOM Source: https://docs.app.strix.ai/api-reference/supply-chain/export-repository-sbom /openapi.json get /repositories/{repositoryId}/supply-chain/sbom # Get organization supply-chain summary Source: https://docs.app.strix.ai/api-reference/supply-chain/get-organization-supply-chain-summary /openapi.json get /supply-chain/summary # Get repository supply-chain summary Source: https://docs.app.strix.ai/api-reference/supply-chain/get-repository-supply-chain-summary /openapi.json get /repositories/{repositoryId}/supply-chain/summary Counts for the resolved scope. Pull-request and merge-request scans keep no SBOM snapshot, so scoping to one of those jobs with `job_id` serves `component_count`, `finding_count`, `malicious_count`, `suspicious_count`, `vulnerable_count`, and `severity_counts` from the job's stored scan result. For those scopes `latest_snapshot` is null and `ecosystem_counts` is empty, because neither can be derived without stored component rows. A change-scan job that ran before scan results were stored reports zero counts. # List repository SBOM components Source: https://docs.app.strix.ai/api-reference/supply-chain/list-repository-sbom-components /openapi.json get /repositories/{repositoryId}/supply-chain/components # List repository supply-chain findings Source: https://docs.app.strix.ai/api-reference/supply-chain/list-repository-supply-chain-findings /openapi.json get /repositories/{repositoryId}/supply-chain/findings Open findings for the resolved scope. Pull-request and merge-request scans keep no SBOM snapshot, so scoping to one of those jobs with `job_id` serves the findings from the job's stored scan result: `snapshot` is null, and on each finding `id`, `source`, `first_seen_at`, and `last_seen_at` are null because no stored finding row exists to carry them. For those scopes `component_id` matches nothing (there are no stored component rows to filter on), and the list is capped at the first 100 findings while `finding_count` on the summary endpoint still covers the whole set. A change-scan job that ran before scan results were stored returns an empty list. # Trigger a supply-chain scan Source: https://docs.app.strix.ai/api-reference/supply-chain/trigger-a-supply-chain-scan /openapi.json post /repositories/{repositoryId}/supply-chain/scan # Update repository supply-chain policy Source: https://docs.app.strix.ai/api-reference/supply-chain/update-repository-supply-chain-policy /openapi.json patch /repositories/{repositoryId}/supply-chain/policy # Create a domain test user Source: https://docs.app.strix.ai/api-reference/test-users/create-a-domain-test-user /openapi.json post /domains/{domainId}/test-users Creates a test account the agent can log in as. Secrets are encrypted at rest and never returned. Email-based MFA requires a Strix-managed inbox (see provision-inbox). # Delete a domain test user Source: https://docs.app.strix.ai/api-reference/test-users/delete-a-domain-test-user /openapi.json delete /domains/{domainId}/test-users/{userId} Deletes the test user when called on its home domain. When called on another domain covered by the user's scope, only detaches that domain from the scope (response includes `detached: true`). Org-wide (all-domains) users can only be deleted from their home domain (409 otherwise). # Get the latest login verification Source: https://docs.app.strix.ai/api-reference/test-users/get-the-latest-login-verification /openapi.json get /domains/{domainId}/test-users/{userId}/verify Returns the latest login verification for a saved test user, or `null` if it has never been verified. Poll this while a verification is `pending` / `running`. # List domain test users Source: https://docs.app.strix.ai/api-reference/test-users/list-domain-test-users /openapi.json get /domains/{domainId}/test-users # Provision a Strix-managed inbox Source: https://docs.app.strix.ai/api-reference/test-users/provision-a-strix-managed-inbox /openapi.json post /domains/{domainId}/test-users/provision-inbox Creates a Strix-controlled AgentMail inbox (in the caller's org pod) for email-OTP / magic-link MFA. The agent reads verification emails from this inbox during scans. # Read a single inbox message Source: https://docs.app.strix.ai/api-reference/test-users/read-a-single-inbox-message /openapi.json get /domains/{domainId}/test-users/{userId}/inbox/{messageId} Returns the full message body as readable text (HTML converted to text so OTP codes and magic-link URLs are preserved). # Read a test user's inbox Source: https://docs.app.strix.ai/api-reference/test-users/read-a-test-users-inbox /openapi.json get /domains/{domainId}/test-users/{userId}/inbox Lists recent messages in the test user's Strix-managed inbox (e.g. OTP / magic-link emails). # Update a domain test user Source: https://docs.app.strix.ai/api-reference/test-users/update-a-domain-test-user /openapi.json patch /domains/{domainId}/test-users/{userId} # Verify a test user's login Source: https://docs.app.strix.ai/api-reference/test-users/verify-a-test-users-login /openapi.json post /domains/{domainId}/test-users/{userId}/verify Starts a short agent run (usually a minute or two) that drives the target's real login form with the saved credentials and reports a structured outcome, so a broken login surfaces before a scan. Returns 202 with a pending verification, or 200 with an in-flight / recent one that is reused. The domain must be ownership-verified. The login URL may live on another host (SSO tenant, IdP, separate auth site) as long as it is a public http(s) endpoint. # Create an API token Source: https://docs.app.strix.ai/api-reference/tokens/create-an-api-token /openapi.json post /tokens Create a new service or personal API token. The raw token secret is returned only in this response. Asset-scoped tokens cannot access organization-wide token management. # List API tokens Source: https://docs.app.strix.ai/api-reference/tokens/list-api-tokens /openapi.json get /tokens List API tokens visible to the authenticated user. Admins see all tokens. Non-admins see only their own personal tokens. Asset-scoped tokens cannot access organization-wide token management. # Revoke an API token Source: https://docs.app.strix.ai/api-reference/tokens/revoke-an-api-token /openapi.json delete /tokens/{tokenId} Revoke an API token. Asset-scoped tokens cannot access organization-wide token management. # Delete an upload Source: https://docs.app.strix.ai/api-reference/uploads/delete-an-upload /openapi.json delete /uploads/{uploadId} Delete an unreferenced upload. Asset-scoped tokens may delete only uploads created by their effective user; unscoped tokens retain organization-wide access. Inaccessible upload IDs return 404. Uploads already attached to any scan are immutable and return 409 without removing the storage object or soft-deleting the row. # Finalize an upload Source: https://docs.app.strix.ai/api-reference/uploads/finalize-an-upload /openapi.json post /uploads/complete Marks a pending upload complete after the bytes have been transferred. Before the transition, every .zip is validated as a bounded repository archive, including pending legacy rows labeled as documentation. Repeating completion for an already-completed upload is idempotent. Asset-scoped tokens may finalize only uploads created by their effective user; unscoped tokens retain organization-wide access. # Request a signed upload URL Source: https://docs.app.strix.ai/api-reference/uploads/request-a-signed-upload-url /openapi.json post /uploads/request Reserves an upload and returns a signed URL (and resumable endpoint for large files) to PUT the file bytes to. Files ending in .zip are always treated as repository source archives and cannot be downgraded to documentation by setting category. # Create a fix pull request Source: https://docs.app.strix.ai/api-reference/vulnerabilities/create-a-fix-pull-request /openapi.json post /vulnerabilities/{vulnerabilityId}/create-fix-pr Opens a pull request with an agent-authored fix for the vulnerability. For code findings, this patches the affected files. For dependency findings (npm-based projects), it bumps the direct dependency in package.json or pins the vulnerable transitive package through the project's override mechanism (npm overrides, yarn resolutions, or pnpm overrides). # Export a vulnerability to a ticketing provider Source: https://docs.app.strix.ai/api-reference/vulnerabilities/export-a-vulnerability-to-a-ticketing-provider /openapi.json post /vulnerabilities/{vulnerabilityId}/push Creates or syncs a Jira or Linear ticket for the vulnerability using the organization's connected ticketing integration. If a ticket already exists for the vulnerability and provider, its status is synced instead of creating a duplicate. # Export multiple vulnerabilities to a ticketing provider Source: https://docs.app.strix.ai/api-reference/vulnerabilities/export-multiple-vulnerabilities-to-a-ticketing-provider /openapi.json post /vulnerabilities/bulk-push Creates or syncs Jira or Linear tickets for up to 100 vulnerabilities in a single request. Each vulnerability is processed independently. The response reports per-vulnerability success or failure. # Get vulnerability details Source: https://docs.app.strix.ai/api-reference/vulnerabilities/get-vulnerability-details /openapi.json get /vulnerabilities/{vulnerabilityId} Returns full details for a single vulnerability. # Get vulnerability history Source: https://docs.app.strix.ai/api-reference/vulnerabilities/get-vulnerability-history /openapi.json get /vulnerabilities/{vulnerabilityId}/history Returns lifecycle audit entries for one vulnerability, including status, severity, snooze, note, and reason changes. # List captured HTTP exchanges Source: https://docs.app.strix.ai/api-reference/vulnerabilities/list-captured-http-exchanges /openapi.json get /vulnerabilities/{vulnerabilityId}/http-exchanges Returns the HTTP request metadata that supports a vulnerability. Set `include_content` to `true` to include stored request and response text. # List vulnerabilities Source: https://docs.app.strix.ai/api-reference/vulnerabilities/list-vulnerabilities /openapi.json get /vulnerabilities Returns a paginated list of vulnerabilities across all scans for the organization. Set the finding_type query parameter to dependency to read dependency findings. This filter also requires the dependencies:read scope. # Retest a vulnerability Source: https://docs.app.strix.ai/api-reference/vulnerabilities/retest-a-vulnerability /openapi.json post /vulnerabilities/{vulnerabilityId}/retest Starts a focused retest to confirm whether a single finding is still exploitable. # Update vulnerability status or severity Source: https://docs.app.strix.ai/api-reference/vulnerabilities/update-vulnerability-status-or-severity /openapi.json patch /vulnerabilities/{vulnerabilityId} Change the status and/or severity of a vulnerability. At least one of `status` or `severity` must be provided. # Create a webhook Source: https://docs.app.strix.ai/api-reference/webhooks/create-a-webhook /openapi.json post /webhooks Create a new webhook subscription. The signing `secret` is returned only in this response. Asset-scoped tokens must provide an in-scope business_unit and cannot create organization-wide subscriptions. # Delete a webhook Source: https://docs.app.strix.ai/api-reference/webhooks/delete-a-webhook /openapi.json delete /webhooks/{webhookId} Delete a webhook. Asset-scoped tokens may delete only a webhook whose business_unit is covered by their token scopes. # Get a webhook Source: https://docs.app.strix.ai/api-reference/webhooks/get-a-webhook /openapi.json get /webhooks/{webhookId} Returns a webhook subscription. Asset-scoped tokens may access only a webhook whose business_unit is covered by their token scopes. # List webhook deliveries Source: https://docs.app.strix.ai/api-reference/webhooks/list-webhook-deliveries /openapi.json get /webhooks/{webhookId}/deliveries Returns a paginated delivery log for a specific webhook. Asset-scoped tokens may access deliveries only for an in-scope business_unit webhook. # List webhooks Source: https://docs.app.strix.ai/api-reference/webhooks/list-webhooks /openapi.json get /webhooks Returns webhooks for the organization. Asset-scoped tokens see only subscriptions whose business_unit is covered by their token scopes. # Update a webhook Source: https://docs.app.strix.ai/api-reference/webhooks/update-a-webhook /openapi.json patch /webhooks/{webhookId} Update webhook URL, events, active status, or rotate the signing secret. Asset-scoped tokens may update only an in-scope business_unit webhook. If you omit business_unit, the webhook keeps its current business_unit. If you change business_unit, use an in-scope value. # Create a workspace Source: https://docs.app.strix.ai/api-reference/workspaces/create-a-workspace /openapi.json post /workspaces Create a workspace and make the token owner its admin. Requires a personal token and the organizations:write scope. # List your workspaces Source: https://docs.app.strix.ai/api-reference/workspaces/list-your-workspaces /openapi.json get /workspaces List the workspaces that the token owner is a member of. Requires a personal token; no API scope is required so a minimal CLI session can recover and switch. # Switch the token to another workspace Source: https://docs.app.strix.ai/api-reference/workspaces/switch-the-token-to-another-workspace /openapi.json post /workspaces/{organizationId}/token Switch the authenticated personal token in place to a workspace that its owner is already a member of. The token row, bearer secret, expiry, saved scope preference, and immutable login consent ceiling are preserved, so the request is safe to retry after a lost response. The owner's current target-workspace role caps effective authority. No API scope is required and widening beyond the consent ceiling is rejected. # Authentication Source: https://docs.app.strix.ai/authentication Token types, scopes, and best practices ## Token types Strix has two types of API tokens: ### Personal tokens * Attached to one user * Expire after 90 days (default) * Best for individual scripts and local tools ### Service keys * Org-level, not attached to a user * Can stay valid for a long time (no default expiry) * Best for CI/CD pipelines and production integrations * **Only org admins can create service keys** ## Default scopes **Service keys** default scopes: ``` scans:read, scans:write, vulnerabilities:read, vulnerabilities:write, schedules:read, schedules:write, assets:read, webhooks:read, webhooks:write ``` **Personal tokens** default scopes: ``` scans:read, scans:write, vulnerabilities:read, vulnerabilities:write, schedules:read, schedules:write, assets:read ``` These defaults apply when creating a token from API Access or `POST /api/v1/tokens`. Device login creates a named CLI session with Minimal, Recommended, Full, or Custom access and an immutable login ceiling. It is shown separately from ordinary keys in API Access and reused by later sign-ins from the same CLI installation. See [CLI login](/guides/cli-login). `webhooks:write` is admin-only. `tokens:write` lets an active member manage ordinary personal tokens; the current CLI session can list/switch its memberships, inspect or narrow itself, and revoke itself without that scope. Its login ceiling prevents switching from widening authority. Only organization admins can create service keys or manage another member's tokens. You can change the scopes when you create a token. ## Resource-restricted tokens API `scopes` control what a token may do. With Enterprise RBAC, optional `rbac_scopes` further restrict which assets it may access. Each resource restriction is an object with exactly these fields: ```json theme={null} {"type": "tag", "value": "payments"} ``` `type` is `target`, `tag`, or `business_unit`; `value` is 1–120 characters and may contain ASCII letters, digits, `.`, `_`, `:`, `/`, `@`, or `-`. A `target` value identifies one asset, while `tag` and `business_unit` values match asset metadata. An empty `rbac_scopes` array means organization-wide asset access within the token's API scopes and the creator's current role. When a token-authenticated caller creates another token and omits `rbac_scopes`, the new token inherits the caller's restrictions. An explicit list must be a subset of the caller token's restrictions. API scopes are similarly capped by the member's current organization role and by the caller token. The CLI exposes the token request fields directly: ```bash theme={null} strix cloud tokens create \ --type personal \ --name payments-reader \ --scopes scans:read vulnerabilities:read assets:read \ --rbac-scopes '[{"type":"tag","value":"payments"}]' \ --expires-in-days 30 ``` Use `--expires-at ` instead for an absolute expiration. The token secret is returned only by the create response; store it securely before leaving the output. ## Available scopes Each endpoint specifies the scope that it requires. A token can only call the endpoints that match its scopes. | Scope | Grants | | ------------------------------------------------ | ----------------------------------------------------------------------------------- | | `scans:read` / `scans:write` | View / manage pentests, retests, templates | | `scans:message` | Send messages to a running pentest | | `vulnerabilities:read` / `vulnerabilities:write` | View / update findings, history, fix PRs | | `dependencies:read` | View dependency inventory | | `supply_chain:read` / `supply_chain:write` | View / update supply-chain alerts | | `schedules:read` / `schedules:write` | View / manage scheduled scans | | `assets:read` / `assets:write` | View / manage domains and repositories | | `pr_reviews:read` / `pr_reviews:write` | View / start PR reviews and settings | | `connectors:read` / `connectors:write` | View / manage network connectors | | `knowledge:read` / `knowledge:write` | View / manage org knowledge, policies, settings | | `integrations:read` / `integrations:write` | View / connect / disconnect SCM integrations | | `uploads:write` | Request, finalize, and delete file uploads | | `chat:read` / `chat:write` | View / start chats and send messages | | `analytics:read` | Read dashboard analytics | | `llm:read` / `llm:write` | View / update self-hosted LLM settings and usage | | `test_users:read` / `test_users:write` | View / manage domain test users and inboxes | | `license:read` | View license details | | `billing:read` / `billing:write` | View billing / buy credits and manage automatic top-up | | `organizations:read` / `organizations:write` | View / manage organization settings | | `members:read` / `members:write` | View / manage members | | `invitations:read` / `invitations:write` | View / manage invitations | | `webhooks:read` / `webhooks:write` | View / manage webhooks (write is admin-only) | | `audit:read` | Read the audit log | | `tokens:write` | Manage your personal tokens; admins can manage organization tokens and service keys | ## Using tokens Include the token in the `Authorization` header: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/scans" \ -H "Authorization: Bearer " ``` Managed CLI sessions also send `X-Strix-Workspace: ` on normal API requests. This pins a process to the workspace it started in and turns a concurrent switch into a safe `409` conflict. Ordinary API tokens do not require this header. ## Best practices * Give each integration only the scopes that it needs (**least privilege**) * **Rotate tokens regularly**, especially service keys * If a token is compromised, **revoke it immediately**. A revoked token stops operation on the next request * Use **personal tokens** for development and **service keys** for production # Analytics Source: https://docs.app.strix.ai/guides/analytics Read dashboard analytics and scan frequency timelines Analytics endpoints supply the same aggregate metrics that the dashboard shows. ## Dashboard overview One unified response contains all the data that the dashboard shows: * KPIs with deltas against the previous period * Issues over time (stacked by severity, split by pentest or PR review source) * Severity breakdown * Open-vs-fixed and MTTR trends * Exploitability (KEV and EPSS) * Top issues and affected assets * CWE distribution * Activity heatmap * PR review metrics (reviews over time split by verdict, findings-addressed rate, top repos and contributors) ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/analytics/overview?range=30d" \ -H "Authorization: Bearer " ``` The `range` parameter accepts `7d`, `30d`, `90d`, `all`, or `custom` (with `from` and `to` ISO dates). Stock metrics (security score, open issues, severity breakdown, top issues and assets) always show the current all-time posture. Flow metrics (issues found, PRs reviewed, pentests run) apply only to the selected window. **Required scope:** `analytics:read` ## Dashboard stats Severity counts, status counts, and headline metrics for your organization: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/analytics/stats" \ -H "Authorization: Bearer " ``` **Required scope:** `analytics:read` ## Scan frequency A timeline of scan activity. Use it to make charts of throughput over time: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/analytics/scan-frequency" \ -H "Authorization: Bearer " ``` **Required scope:** `analytics:read` # Billing and credits Source: https://docs.app.strix.ai/guides/billing Read the credit balance, buy credits with machine payments, and manage automatic top-ups Non-Enterprise workspaces use scan credits for standard managed pentests. One credit costs \$1.00. Enterprise scans are included in the plan and do not consume the credit wallet. Retests and supply-chain dependency scans are also credit-exempt. These endpoints let an API caller or agent read the balance, buy credits, and manage automatic top-ups. The scan price is calculated from the requested scope before launch. At the current default `ultra` tier, a standard code review or live test starts at 60 credits for one target, then adds 20 credits for each additional repository or domain. A local-source-only code review therefore starts at 60 credits; uploading source does not make the scan free. Other scan tiers and full-audit engagements have different estimates, so treat the estimate returned for the request as authoritative. If a non-Enterprise workspace cannot cover the estimate, scan creation returns HTTP `402 Payment Required` with code `scan_credit_limit_reached`. The CLI maps this to exit code `5`. The rejected request creates no scan and consumes no credits. Validation and plan rejections that occur before launch also consume no credits. The `402` body tells the caller how to recover. It contains a `hint`, the `topup_url` of the billing page, and a `topup_options` list. Each option contains the API `method` and `path`, the matching `cli` command, and a `description`. The options are in the order that a headless caller should try them: ```json theme={null} { "detail": "Out of credits. Buy more to keep running pentests. Buy credits with `strix cloud billing topup --credits ` or at https://app.strix.ai/settings/billing. Then retry this request.", "requiredTier": "cloud", "code": "scan_credit_limit_reached", "hint": "Buy credits with `strix cloud billing topup --credits ` or at https://app.strix.ai/settings/billing. Then retry this request.", "topup_url": "https://app.strix.ai/settings/billing", "topup_options": [ { "method": "POST", "path": "/api/v1/billing/topup", "cli": "strix cloud billing topup --credits ", "description": "Buy credits with a machine payment. ..." }, { "method": "POST", "path": "/api/v1/billing/checkout", "cli": "strix cloud billing subscribe --plan strix_top_up", "description": "Create a hosted checkout link. The user pays in the browser." }, { "method": "GET", "path": "/api/v1/billing/credits", "cli": "strix cloud billing credits", "description": "Check the current credit balance." } ], "plan_trial": { "plan": "strix_cloud", "trial_days": 7, "includes": "PR security reviews on every pull request", "method": "POST", "path": "/api/v1/billing/checkout", "cli": "strix cloud billing subscribe --plan strix_cloud", "url": "https://app.strix.ai/settings/billing", "description": "Scan credits are separate from the Cloud plan. The Cloud plan includes PR security reviews on every pull request and starts with a free trial of up to 7 days. ..." } } ``` Scan reruns, schedule creation with `also_run_now: true`, and manual schedule triggers return the same body. The `plan_trial` object is present only when the workspace has not subscribed before and can still start the Cloud plan trial. The Cloud plan includes PR security reviews and does not include scan credits. When the object is present, the `detail` text also mentions the trial. Use `plan` as the `product` value for `POST /api/v1/billing/checkout`. Subscribers, former subscribers, and workspaces with an ended trial receive the plain top-up guidance. ## Get the credit balance ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/billing/credits" \ -H "Authorization: Bearer " ``` **Required scope:** `billing:read` The response contains the current `balance` and `price_per_credit_cents`. An Enterprise workspace may still have a wallet balance, but normal Enterprise scan launches do not debit it. ## Buy credits with a machine payment This endpoint accepts agent payments through the Stripe Machine Payments Protocol (MPP). The purchase requires an admin role on the workspace. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/billing/topup" \ -H "X-Strix-Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"credits": 20}' ``` **Required scope:** `billing:write` Send the API token in the `X-Strix-Authorization` header for this endpoint. MPP uses the standard `Authorization` header for the payment credential. The first request returns HTTP `402 Payment Required` with a payment challenge in the `WWW-Authenticate` header. Pay the challenge with an MPP wallet, for example the Stripe Link agent wallet, and retry the request with the payment credential. See the [Stripe machine payments documentation](https://docs.stripe.com/payments/machine) for wallet setup. When the payment succeeds, the response confirms the grant: ```json theme={null} { "credits_granted": 20, "duplicate": false, "reference": "pi_...", "balance": 40 } ``` Credit grants are idempotent on the payment `reference`. A retry with the same paid credential returns `duplicate: true` and grants no additional credits. ## Get automatic top-up settings ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/billing/auto-topup" \ -H "Authorization: Bearer " ``` **Required scope:** `billing:read` The response contains `enabled`, `topup_credits`, `monthly_cap_credits`, and `used_this_month`. ## Update automatic top-up settings Automatic top-ups charge the saved payment method of the workspace when the balance runs out. The update requires an admin role on the workspace. ```bash theme={null} curl -X PUT "https://app.strix.ai/api/v1/billing/auto-topup" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "enabled": true, "topup_credits": 240, "monthly_cap_credits": 2400 }' ``` **Required scope:** `billing:write` Set `monthly_cap_credits` to `null` to remove the monthly limit. ## Create a checkout link Use this endpoint to buy a plan or a credit pack. The response contains a hosted checkout page. A person must open the page and complete the payment. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/billing/checkout" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"product": "strix_cloud"}' ``` **Required scope:** `billing:write` The accepted products are `strix_cloud` for the Cloud plan, `strix_startup` for an approved startup offer, and `strix_top_up` for a credit pack. The request needs an admin role on the workspace. The response contains `checkout_url`. The open-source CLI opens this page with the `strix cloud billing subscribe --plan strix_cloud` command. ## Create a billing portal link The billing portal shows the invoices of the workspace. A person can change the payment method and the plan there. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/billing/portal" \ -H "Authorization: Bearer " ``` **Required scope:** `billing:write` The request needs an admin role on the workspace. The response contains `portal_url`. If the workspace does not yet have a billing customer, the endpoint returns HTTP `409 Conflict` with instructions to subscribe first. Create a checkout link with the preceding endpoint, complete that handoff as a person, and then request the portal again. Provider failures return `502 Bad Gateway`; an on-premises deployment where the hosted portal is unavailable returns `400 Bad Request`. The CLI equivalent is `strix cloud billing portal`. It prints or opens the hosted link; it never changes payment details by itself. For machine-payment top-ups, `strix cloud billing topup --credits --no-pay` prints the payment challenge without paying it. In an interactive terminal, the paying form asks for confirmation. In an agent, CI, or other non-interactive process, payment cannot proceed unless `--yes` is present; obtain the user's approval before running `strix cloud billing topup --credits --yes`. The `--yes` and `--no-pay` options are mutually exclusive. `--yes` authorizes the CLI to invoke the configured wallet, but Link may still require the user to approve or complete the payment. # Chat Source: https://docs.app.strix.ai/guides/chat Start and continue Strix chat sessions programmatically Use chat to send messages to a Strix agent and get replies. You can attach repositories and files to give context. Chat requires an enterprise plan. ## List chats ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/chat?limit=20" \ -H "Authorization: Bearer " ``` **Required scope:** `chat:read` ## Start a chat ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/chat" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "message": "Review the auth flow in my-org/my-repo for IDOR risks", "repos": [{"repoId": "", "branch": "main"}] }' ``` To attach files, send `multipart/form-data` instead of JSON. Use the same fields and add the file parts. **Required scope:** `chat:write` ## Get a chat ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/chat/" \ -H "Authorization: Bearer " ``` **Required scope:** `chat:read` ## Send a message ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/chat//message" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"message": "Now check the password reset endpoint"}' ``` To stop an active agent turn before you send the message, set `"cancel_current": true`. `message` can be omitted for a control-only request when either `cancel_current` or `stop_agent` is `true`. `cancel_current` cancels the in-flight turn; `stop_agent` parks the target agent and its descendants: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/chat//message" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"stop_agent": true}' ``` **Required scope:** `chat:write` ## Export workspace files Chat artifacts live under `/workspace` in the running agent sandbox. List exportable files: ```bash theme={null} curl "https://app.strix.ai/api/v1/chat//files" \ -H "Authorization: Bearer " ``` The listing is capped at 10,000 entries and 2 MiB before the sandbox response is parsed and normalized. An oversized listing returns `413`. Download one file. The API accepts either an absolute path under `/workspace` or a convenient relative path such as `report.md`; relative paths resolve from `/workspace`. Traversal and absolute paths outside `/workspace` are rejected. An individual export is limited to 50 MiB. ```bash theme={null} curl --get "https://app.strix.ai/api/v1/chat//files/download" \ -H "Authorization: Bearer " \ --data-urlencode "path=/workspace/report.md" \ --output report.md ``` Or stream the whole workspace as a ZIP: ```bash theme={null} curl "https://app.strix.ai/api/v1/chat//files/archive" \ -H "Authorization: Bearer " \ --output workspace.zip ``` Archive export preflights the same 2 MiB / 10,000-entry listing limit, a 50 MiB per-file limit, and 512 MiB of uncompressed content, with a 30-second archive deadline. ZIP entries must be safe relative POSIX paths. The service bounds sandbox JSON and base64 responses before parsing or decoding them, streams with response backpressure, and cancels in-flight sandbox work if the client disconnects. An empty workspace returns `404`, and oversized listings or files return `413`. Invalid listing, export, or file data from the sandbox returns `502`; an unavailable, unready, or timed-out sandbox returns `503`. A file read failure or actual-byte overflow fails the stream instead of returning a valid-looking partial ZIP. **Required scope:** `chat:read` The CLI adds safe file handling and refuses to replace an existing output unless `--force` is explicit: ```bash theme={null} strix cloud chat files strix cloud chat files download --path report.md --output report.md strix cloud chat files archive --output workspace.zip ``` ## Create a share link ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/chat//share" \ -H "Authorization: Bearer " ``` **Required scope:** `chat:write` # CLI login Source: https://docs.app.strix.ai/guides/cli-login Sign in from the Strix CLI with the device authorization flow The CLI login endpoints let a terminal or a coding agent create a Strix account and get an API token without a dashboard visit. The flow uses OAuth 2.0 device authorization. The open-source CLI runs this flow with the `strix cloud login` command. ## Start device authorization This endpoint does not require authentication. The browser step establishes the user identity. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/cli/login" ``` The response contains a `user_code`, a `verification_uri_complete`, a `device_code`, an `expires_in` value, and a poll `interval` in seconds. Show the `user_code` to the user and open `verification_uri_complete` in a browser. Keep the `device_code` private. This endpoint and the poll endpoint accept POST only. If a browser opens one of these URLs with GET, the server starts no sign-in. It returns `405` with an `Allow: POST` header and a short explanation. The body is HTML for a browser and JSON for other clients. The JSON body contains the `strix cloud login` command, the install URL, and the documentation URL. ## Poll for completion Poll this endpoint with the `device_code` at the returned interval. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/cli/login/poll" \ -H "Content-Type: application/json" \ -d '{"device_code": "", "scope_profile": "recommended", "client_instance_id": "", "device_name": "macOS CLI · a1b2c3d4"}' ``` Choose `scope_profile` as `minimal`, `recommended`, or `full`, or send a custom `scopes` array. The server always includes the minimum scopes `scans:read`, `scans:write`, and `billing:read`; the member's role caps the final set. The CLI exposes `--scope-profile` and `--scopes`. The open-source CLI generates one opaque `client_instance_id` per installation and a privacy-safe `device_name` that contains no hostname. Sending both makes later sign-ins from the same installation replace that session's secret and expiry in the same database row instead of creating an unlimited series of keys. Different installations remain separately visible and revocable in **Settings → API Access** as CLI sessions. Omit both fields only for compatibility with an older client. Without either field, the server uses Recommended. This profile covers the resources that `strix cloud` commands use every day: * Scans: `scans:read`, `scans:write`, `scans:message`, `uploads:write` * Findings: `vulnerabilities:read`, `vulnerabilities:write`, `dependencies:read`, `supply_chain:read`, `supply_chain:write` * Assets and schedules: `assets:read`, `assets:write`, `schedules:read`, `schedules:write` * Reviews and knowledge: `pr_reviews:read`, `pr_reviews:write`, `knowledge:read`, `knowledge:write`, `chat:read`, `chat:write` * Connectors: `connectors:read`, `connectors:write` * Integrations: `integrations:read`, `integrations:write` * Workspace: `organizations:read`, `organizations:write`, `webhooks:read`, `audit:read`, `analytics:read`, `license:read`, `billing:read`, `billing:write` The workspace and integration scopes let an admin agent complete the first-time setup steps from the login response. The agent can name the workspace and connect a repository provider. The billing scopes let an admin agent complete the user-approved Link/MPP credit top-up flow when a scan needs credits. Account administration still requires Full or an explicit custom scope request: `members:read`, `members:write`, `invitations:read`, `invitations:write`, `webhooks:write`, `tokens:write`, `llm:read`, `llm:write`, `test_users:read`, and `test_users:write`. Workspace listing and switching the current CLI session do not themselves require `organizations:read` or `tokens:write`. The server omits the scopes that the member's role cannot receive. A profile change applies to new logins only. An existing session keeps the ceiling that the user approved at sign-in. While the user has not confirmed in the browser, the response is an error with the code `authorization_pending`. Continue to poll. If the response code is `slow_down`, increase the poll interval by 5 seconds. ## Interactive workspace and scope selection Send `"interactive": true` in the poll request to select a workspace and scopes after the browser step. When the user confirms in the browser, the response then contains `selection_required: true`, a short-lived `selection_token`, `is_new_user`, the workspaces of the user, and the full scope catalog with descriptions. Each scope entry shows if the scope is part of the minimum set, if it is a default, and the lowest member role that can receive it. Each workspace entry contains `has_default_name`. This value is true when the user is an admin and the workspace still has the generated name, for example `Alex's Workspace`. Complete the login with the selection: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/cli/login/complete" \ -H "Content-Type: application/json" \ -d '{"selection_token": "", "organization_id": "", "scope_profile": "minimal", "workspace_name": "Acme Security"}' ``` The workspace must be one of the memberships of the user. The server always includes the minimum scopes. The role of the member limits the final set. The selection token expires after 10 minutes. The `strix cloud login` command uses this flow in an interactive terminal. It offers a workspace picker and the scope presets Recommended, Full access, and Minimal. The `--workspace` flag selects a workspace by name or ID without a prompt. The `workspace_name` field is optional. Use it when the workspace has `has_default_name` set to true. The user must be an admin of the workspace. The server mints the token and then renames the workspace. A failed rename does not fail the sign-in. If the value equals the current default name, the server records that the user chose the name. An empty value keeps the current name. In an interactive terminal, the `strix cloud login` command asks a first-time user for a workspace name. When the user confirms, the response contains the account and a personal API token: ```json theme={null} { "api_token": "strix_...", "organization_id": "", "organization_name": "My workspace", "email": "user@example.com", "expires_at": "2026-11-24T00:00:00.000Z", "is_new_user": true, "scopes": ["scans:read", "scans:write", "billing:read"], "scope_ceiling": ["scans:read", "scans:write", "billing:read"], "requested_scopes": ["scans:read", "scans:write", "billing:read"], "scope_profile": "minimal", "token_id": "", "credential_source": "cli", "device_name": "macOS CLI · a1b2c3d4", "onboarding": { "workspace_named": false, "repositories_connected": false, "domains_added": false, "github_install_url": "https://github.com/apps/strix/installations/new?state=..." }, "next_steps_hint": "Your workspace still has its default name. Name it with strix cloud org update --name. ...", "next_steps": [ { "action": "Name your workspace", "cli": "strix cloud org update --name \"Acme Security\"", "method": "PATCH", "path": "/api/v1/organization" }, { "action": "Connect GitHub repositories for PR security reviews and code scans", "cli": "strix cloud integrations install github", "method": "POST", "path": "/api/v1/integrations/github/install-url" }, { "action": "List your workspaces", "cli": "strix cloud workspaces list", "method": "GET", "path": "/api/v1/workspaces" }, { "action": "Add a domain to test", "cli": "strix cloud domains add --domain example.com --asset-type web_app", "method": "POST", "path": "/api/v1/domains" }, { "action": "Check your scan credits", "cli": "strix cloud billing credits", "method": "GET", "path": "/api/v1/billing/credits" }, { "action": "Start a scan", "cli": "strix cloud scans start --engagement-type live_test --domain-ids --wait", "method": "POST", "path": "/api/v1/scans" } ], "dashboard_url": "https://app.strix.ai" } ``` The `next_steps` list gives the first actions after a sign-in, in order. Each step contains the CLI command and the matching API call. An agent can read the list from the JSON response. The CLI prints `next_steps_hint` after a successful login. The `onboarding` object reports what the workspace still lacks. The server computes it from live data on every sign-in: * `workspace_named` is false while the workspace still has the generated default name. Rename the workspace with `PATCH /api/v1/organization`. * `repositories_connected` is true when at least one repository has an active installation. * `domains_added` is true when at least one domain exists in the workspace. * `github_install_url` is present for an admin session without asset scopes while no repository is connected. A person opens the link in a browser. If the browser has no dashboard session, the dashboard asks the person to sign in with the same account and then returns to the installation. The link expires after 10 minutes. The setup steps in `next_steps` match the permissions of the session. The list contains the rename step only when the session has `organizations:write`. The list contains the GitHub step only when the session has `integrations:write` and `github_install_url` is present. If the server cannot read the live state, the response omits `onboarding`. The token is still valid in that case. When the workspace can still start the Cloud plan trial, the list ends with a step that starts the trial. The Cloud plan includes PR security reviews and starts with a free trial of up to 7 days. The plan does not include scan credits. The `api_token` value is shown only once. Store it in a secure location. `scope_ceiling` is the immutable maximum authority accepted at this login; workspace and profile changes can narrow it but cannot widen it. Broader access requires another browser sign-in. For a first-time user, Strix creates the account and a default workspace automatically. The token is valid for 90 days. ## CLI output and automation In a terminal, `strix cloud` output is compact and action-oriented: lists favor names, branches, lifecycle states, and numbered selectors. Internal organization and user IDs are omitted, while a required selector that is too long for a compact table is repeated losslessly in a copyable block. Paginated lists print the next `--page` or `--offset`, and detail views prioritize useful prose within a safe terminal bound. A bare resource group with a safe read operation runs its default list/read action; use `-h` or `help` to list that group's verbs. Pass `--json` for the complete record. When stdout is redirected or is not a terminal, output automatically becomes JSON and the CLI never prompts. Binary downloads are the exception: redirect their raw bytes intentionally, or use `--output FILE --json` to write the file and receive structured download metadata. ## Workspaces A personal token belongs to one workspace. Use these endpoints to list the workspaces of the user, create a workspace, and retarget the active personal token to another workspace. All three need a personal token from the login flow. A service token belongs to a single workspace and cannot use them. ### List workspaces ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/workspaces" \ -H "Authorization: Bearer " ``` **Required scope:** none. The bearer must be a personal token. Keeping this recovery operation scope-independent lets a Minimal CLI session discover and switch workspaces. Each entry contains `id`, `name`, `role`, and `current`. In an interactive terminal, the CLI presents the entries as a numbered list and hides the long IDs from the compact table. JSON output still contains the complete records: ```bash theme={null} strix cloud workspaces # numbered human-readable list strix cloud workspaces --json # complete records for agents ``` ### Create a workspace ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/workspaces" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"name": "My Team"}' ``` **Required scope:** `organizations:write` and an admin role. The Recommended preset includes this scope for admins. The user becomes the admin of the new workspace. ### Switch the active token to another workspace ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/workspaces//token" \ -H "Authorization: Bearer " \ -H "X-Strix-Workspace: " \ -H "Content-Type: application/json" \ -d '{"scope_profile": "minimal"}' ``` **Required scope:** none. The bearer must be a personal token. The user must be a member of the workspace. An ordinary switch preserves the server-side requested profile, then the target-workspace role caps its effective scopes. A `scope_profile` or custom `scopes` request may narrow within `scope_ceiling`; a request beyond the ceiling returns `403` and requires login again. The endpoint retargets the same row and keeps its bearer secret and expiry, making an exact retry safe after a lost response. ```bash theme={null} strix cloud workspaces use 3 # number from the current list strix cloud workspace use "My Team" # singular alias and exact name strix cloud workspaces use # stable ID for automation strix cloud session scopes # effective scopes and login ceiling strix cloud session scopes set minimal # narrow without logging in again ``` `workspace` and `workspaces` are aliases. The `use` selector accepts a displayed number, exact case-insensitive name, or workspace ID. If names are duplicated, use the displayed number or ID. A list number is convenient for a person but is not a stable automation identifier; an agent should use the ID from `--json`. Ordinary switching does not ask for scopes again. `workspaces use --json` returns the resulting profile, granted/requested/ceiling scopes, expiry, CLI-session metadata, and a `stored` boolean without returning the bearer secret. The CLI updates local metadata only after success and never persists `--token` or `STRIX_API_TOKEN` overrides. ## Session safety and revocation Managed CLI-session requests include `X-Strix-Workspace` with the organization selected when the process started. If another shell switches the same device session, a stale command receives `409 workspace_session_changed` instead of silently running against the new workspace. JSON CLI output preserves the error code plus current and expected workspace IDs for agent recovery. `GET /workspaces`, `GET /cli/session`, and an exact workspace-switch retry remain available for recovery; stale processes cannot change scopes or revoke the session. Direct API clients using a CLI session should send the same header; ordinary API tokens are unchanged. ```bash theme={null} strix cloud session # fetch remote session state strix cloud session scopes --json # effective/requested/ceiling scopes strix cloud session scopes set recommended strix cloud logout # remote revoke, then local deletion strix cloud logout --local-only # deliberate emergency local cleanup ``` When a command needs a scope that the session does not have, the API returns `403` with `details.code` set to `insufficient_scope`, the `required_scope`, and a `hint`. The hint gives the one instruction that resolves the error: * If the scope is inside the login ceiling, run `strix cloud session scopes set full`. * If the scope is outside the login ceiling, run `strix cloud login --scope-profile full` and approve the wider access in the browser. * If the role of the member cannot hold the scope, ask a workspace admin to change the role. * For an ordinary API token, create a token that includes the scope in **Settings → API Access**. `GET /api/v1/cli/session` returns the current session. `PATCH` changes `scope_profile` or custom `scopes` within the ceiling. `DELETE` revokes that same bearer without requiring `tokens:write`. Normal logout keeps the local token after transport or server failures so revocation can be retried; a definitive success or already-invalid (`401`) response permits local deletion. Revoked and expired CLI-session rows are retained for a bounded audit window, then purged. ## Tab completion Completion is generated by the source CLI as well as packaged binaries. It therefore works with `uv run strix` too: ```bash theme={null} source <(strix completions zsh) # From a source checkout: source <(uv run strix completions zsh) # bash: source <(strix completions bash) # fish: strix completions fish | source ``` Add the appropriate command to the shell startup file to enable it in future terminals. Completion covers cloud groups, verbs, flags, and singular resource aliases; it does not send a request or expose token values. # Network Connectors Source: https://docs.app.strix.ai/guides/connectors Reach internal targets through Strix network connectors With a network connector, Strix can scan internal or private targets. Strix sends its traffic through a connector that you install in your network. ## List connectors ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/connectors" \ -H "Authorization: Bearer " ``` **Required scope:** `connectors:read` ## Create a connector When you create a connector, the response contains the enrollment material that you need to make the connector operational: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/connectors" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"name": "prod-vpc-connector"}' ``` **Required scope:** `connectors:write` ## Get a connector ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/connectors/" \ -H "Authorization: Bearer " ``` **Required scope:** `connectors:read` ## Check live status ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/connectors//status" \ -H "Authorization: Bearer " ``` **Required scope:** `connectors:read` ## Delete a connector ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/connectors/" \ -H "Authorization: Bearer " ``` **Required scope:** `connectors:write` # Integrations Source: https://docs.app.strix.ai/guides/integrations Connect and manage source control integrations List connected integrations, and connect GitLab or Bitbucket with a personal access token. GitHub App and Slack installations use interactive approval flows. The API and CLI return an installation link for a person to approve; neither completes that approval automatically. Validate, connect, install, and disconnect operations require an organization admin. ## List integrations ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/integrations" \ -H "Authorization: Bearer " ``` **Required scope:** `integrations:read` ## Validate a token Validate a token before you connect (this operation does not store data): ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/integrations/gitlab/validate" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"access_token": "", "instance_url": "https://gitlab.example.com"}' ``` **Required scope:** `integrations:write` Invalid or rejected provider credentials return HTTP `422 Unprocessable Entity`. A provider outage or other upstream validation failure returns `502 Bad Gateway`. HTTP `401 Unauthorized` means the Strix API token used for this request is invalid; it is not how an invalid GitLab or Bitbucket credential is reported. ## Create an installation link GitHub and Slack require a person to approve an installation. Request the handoff URL like this: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/integrations/github/install-url" \ -H "Authorization: Bearer " ``` **Required scope:** `integrations:write` The response contains `url`. Opening it is a separate human step; receiving the URL does not install or authorize the integration. The CLI equivalent is `strix cloud integrations install github` (or `slack`); add `--no-browser` to print the URL without opening it. ## Connect with a token ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/integrations/gitlab/connect" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"access_token": "", "instance_url": "https://gitlab.example.com"}' ``` For Bitbucket, use the `bitbucket` endpoints and pass the account email: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/integrations/bitbucket/connect" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"access_token": "", "account_email": "dev@example.com"}' ``` **Required scope:** `integrations:write` CLI equivalents keep the provider credential separate from the Strix API token used for authentication: ```bash theme={null} strix cloud integrations validate gitlab \ --provider-token --instance-url https://gitlab.example.com strix cloud integrations connect bitbucket \ --provider-token --account-email dev@example.com ``` ## Disconnect an integration ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/integrations/" \ -H "Authorization: Bearer " ``` `` is one of `github`, `gitlab`, `bitbucket`, or `slack`. GitHub, GitLab, and Bitbucket can have multiple installations, so pass the integer `installation_id` returned by the list endpoint: ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/integrations/github?installation_id=" \ -H "Authorization: Bearer " ``` Omit `installation_id` for organization-wide providers such as Slack. Passing it for Slack, or omitting it for GitHub, GitLab, or Bitbucket, returns `400 Bad Request`. **Required scope:** `integrations:write` CLI equivalents: ```bash theme={null} strix cloud integrations list --json strix cloud integrations disconnect github --installation-id strix cloud integrations disconnect slack ``` # Jira Integration Source: https://docs.app.strix.ai/guides/jira-integration Connect Strix to Jira Cloud to export vulnerabilities as issues and keep statuses in sync Strix connects natively to Jira Cloud. Strix can export the vulnerabilities that scans and PR reviews find as Jira issues, and keep the statuses synchronized in both directions. This page describes the setup, the OAuth scopes that Strix requests, the data that Strix and Jira exchange, and the disconnect procedure. ## Overview | | | | --------------------- | ------------------------------------------------------------------------------------------------ | | Integration type | Native Atlassian OAuth 2.0 (3LO) app — no third-party middleware in the data path | | Direction | Bidirectional. Strix creates and updates issues. Jira status changes come back through a webhook | | Who can connect | Strix organization **admins** only | | Jira products touched | Jira Cloud (through the `api.atlassian.com` gateway, scoped to one site and cloud ID) | | Hosting | Jira Cloud only (Strix does not support Jira Server or Data Center) | ## Setup 1. In Strix, go to **Settings → Integrations** and click **Connect** on the Jira card. You must be an organization admin, and your plan must include ticketing integrations. 2. Strix opens the standard Atlassian consent screen (`auth.atlassian.com`). Sign in with a Jira account that can browse projects and create issues in the target projects. Then approve the requested scopes. 3. Atlassian redirects back to `https://app.strix.ai/api/integrations/jira/callback`. Strix exchanges the authorization code for tokens, records the Jira site (cloud ID and site URL), and registers a webhook for inbound status synchronization. 4. In Strix, select a **default project** (and, if you want, a default issue type) as the export destination. You can also enable **auto-sync** with a minimum severity. Auto-sync exports new findings automatically. If the authorizing Atlassian account has access to more than one Jira site, Strix connects the first accessible site. If you have more than one site, use an account that has access only to the applicable site. ## OAuth scopes requested | Scope | Why Strix needs it | | --------------------- | --------------------------------------------------------------------------------------- | | `read:jira-work` | List projects and issue types, and read issue status during synchronization | | `write:jira-work` | Create issues, post status comments, and transition issues | | `read:jira-user` | Atlassian requires this scope for issue operations that resolve users | | `manage:jira-webhook` | Register and refresh the webhook for inbound status synchronization | | `offline_access` | Receive a refresh token so that the connection continues after the access token expires | Access tokens are short-lived. Strix refreshes them automatically with the rotating refresh token. All API calls go through `https://api.atlassian.com/ex/jira//rest/api/3` and apply only to the one connected site. ## What data flows where **Strix → Jira** (when you export a vulnerability manually, or when auto-sync exports it): * Issue summary: the vulnerability title (shortened to the Jira limit). * Issue description: severity, CVSS and CVE (when present), target, endpoint or affected file, impact, technical analysis, evidence, suggested fix or remediation steps, proof of concept, and a link back to the issue in Strix. * Priority mapped from severity, and a due date when an issue is snoozed. * Status comments (for example, "marked In Progress by …") when the Strix status changes. **Jira → Strix** (through a webhook on `jira:issue_updated`): * The issue ID and key, its status category (new, in progress, or done), the due date, and the display name of the user who made the change. Strix applies the status category to the status of the linked vulnerability. Strix does not read existing Jira issues, attachments, comments, or user directories. Inbound processing applies only to status and due-date updates for the issues that Strix created. ## Security * **Admin-gated**: The connect and callback endpoints require an authenticated Strix org admin. Strix checks the role again at the callback. Thus a demoted user cannot complete a pending connection. * **CSRF-protected OAuth**: The OAuth `state` is HMAC-signed and bound to the initiating organization and user. It expires after 10 minutes. * **Webhook verification**: Atlassian does not sign Jira dynamic webhooks. Thus the callback URL contains a per-connection random secret. Strix compares this secret (in a timing-safe operation) with the stored value before it processes a payload. * **Token storage**: Strix keeps the access and refresh tokens server-side in its database. The tokens apply only to your organization. The browser and other tenants cannot see them. * **Revocation on disconnect**: When you disconnect the integration, Strix deletes the webhook and revokes the Atlassian grant. Refresh-token revocation makes the full grant invalid. Thus no live tokens stay on the Atlassian side. * **Audit trail**: The Strix audit log records the connection of the integration and the changes to the settings. ## Disconnecting An org admin can disconnect Jira at any time from **Settings → Integrations**, or through the API: ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/integrations/jira" \ -H "Authorization: Bearer " ``` **Required scope:** `integrations:write` The disconnect operation removes the stored tokens, deletes the Jira webhook, and revokes the OAuth grant. Strix does not delete the issues that it already created in Jira. # Knowledge Source: https://docs.app.strix.ai/guides/knowledge Manage organization knowledge, policies, and repository profiles The knowledge base gives Strix context about your organization. The context includes documents, policies, and per-repository profiles. Strix uses this context when it does scans and reviews. ## Documents List documents: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/knowledge" \ -H "Authorization: Bearer " ``` **Required scope:** `knowledge:read` Create a document: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/knowledge" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "title": "Auth architecture", "content": "We use WorkOS for SSO and short-lived JWTs...", "tags": ["auth", "architecture"] }' ``` **Required scope:** `knowledge:write` Update or delete a document: ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/knowledge/" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"content": "Updated content"}' curl -X DELETE "https://app.strix.ai/api/v1/knowledge/" \ -H "Authorization: Bearer " ``` **Required scope:** `knowledge:write` ## Search documents Use the `search` parameter to filter the document list: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/knowledge?search=authentication" \ -H "Authorization: Bearer " ``` **Required scope:** `knowledge:read` ## Policies List policies: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/knowledge/policies" \ -H "Authorization: Bearer " ``` **Required scope:** `knowledge:read` Create or update a policy (upsert by `policy_key`): ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/knowledge/policies" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "policy_key": "out-of-scope", "policy_value": "Never test the billing provider endpoints.", "policy_type": "constraint", "is_active": true, "metadata": {"owner": "security"} }' ``` Delete a policy: ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/knowledge/policies/" \ -H "Authorization: Bearer " ``` **Required scope:** `knowledge:write` ## Repository profiles List repository knowledge profiles and their entries: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/knowledge/repos" \ -H "Authorization: Bearer " curl -X GET "https://app.strix.ai/api/v1/knowledge/repos//entries" \ -H "Authorization: Bearer " ``` **Required scope:** `knowledge:read` Update a repository profile: ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/knowledge/repos//profile" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"content": "This service handles PCI data."}' ``` **Required scope:** `knowledge:write` # Linear Integration Source: https://docs.app.strix.ai/guides/linear-integration Connect Strix to Linear to export vulnerabilities as issues and keep statuses in sync Strix connects natively to Linear. Strix can export the vulnerabilities that scans and PR reviews find as Linear issues, and keep the statuses synchronized in both directions. This page describes the setup, the OAuth scopes that Strix requests, the data that Strix and Linear exchange, and the disconnect procedure. ## Overview | | | | ---------------- | -------------------------------------------------------------------------------------------------- | | Integration type | Native Linear OAuth 2.0 app — no third-party middleware in the data path | | Direction | Bidirectional. Strix creates and updates issues. Linear status changes come back through a webhook | | Who can connect | Strix organization **admins** only | | Scope of access | The Linear workspace that the authorizing user approves | ## Setup 1. In Strix, go to **Settings → Integrations** and click **Connect** on the Linear card. You must be an organization admin, and your plan must include ticketing integrations. 2. Approve the app on the standard Linear consent screen (`linear.app/oauth/authorize`). Linear redirects back to `https://app.strix.ai/api/integrations/linear/callback`. There, Strix exchanges the authorization code for a token and records the workspace. 3. In Strix, select a **default team or project** as the export destination. You can also enable **auto-sync** with a minimum severity. Auto-sync exports new findings automatically. ## OAuth scopes requested | Scope | Why Strix needs it | | ------- | --------------------------------------------------------------------- | | `read` | List teams and projects, and read issue status during synchronization | | `write` | Create issues, post status comments, and update issue state | Linear supplies long-lived access tokens (no refresh token). Thus the connection continues until you disconnect it or revoke it. ## What data flows where **Strix → Linear** (when you export a vulnerability manually, or when auto-sync exports it): * Issue title: the vulnerability title. * Issue description: severity, CVSS and CVE (when present), target, endpoint or affected file, impact, technical analysis, evidence, suggested fix or remediation steps, proof of concept, and a link back to the issue in Strix. * Priority mapped from severity, and a due date when an issue is snoozed. * Status comments (for example, "marked In Progress by …") when the Strix status changes. **Linear → Strix** (through a webhook on issue updates): * The issue ID and identifier, its workflow state type (for example, started or completed), and the display name of the actor who made the change. Strix applies the state to the status of the linked vulnerability. Strix does not read existing Linear issues, comments, or user directories. Inbound processing applies only to status updates for the issues that Strix created. ## Security * **Admin-gated**: The connect and callback endpoints require an authenticated Strix org admin. Strix checks the role again at the callback. Thus a demoted user cannot complete a pending connection. * **CSRF-protected OAuth**: The OAuth `state` is HMAC-signed and bound to the initiating organization and user. It expires after 10 minutes. * **Signed webhooks**: Strix makes sure that each Linear webhook delivery has a correct HMAC-SHA256 signature (in a timing-safe comparison) and a timestamp in the permitted window. This limits replay. * **Token storage**: Strix keeps the access token server-side in its database. The token applies only to your organization. The browser and other tenants cannot see it. * **Revocation on disconnect**: When you disconnect the integration, Strix revokes the token on the Linear side. Thus no live tokens stay. * **Audit trail**: The Strix audit log records the connection of the integration and the changes to the settings. ## Disconnecting An org admin can disconnect Linear at any time from **Settings → Integrations**, or through the API: ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/integrations/linear" \ -H "Authorization: Bearer " ``` **Required scope:** `integrations:write` The disconnect operation removes the stored token and revokes the OAuth grant. Strix does not delete the issues that it already created in Linear. # Live Scan Prompt Source: https://docs.app.strix.ai/guides/live-scan-prompt Send live prompts to a running pentest agent With live scan prompts, you can send a message into a running pentest agent graph. This feature is available only on the enterprise plan. Use this endpoint to send the message to the agent that is selected in the scan UI. If you omit `agent_id`, the message goes to the root agent. ## Send a live prompt ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/scans//message" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "message": "Check whether the login form is protected against CSRF", "agent_id": "" }' ``` The request body accepts these fields: * `message` — required. The text to send to the running scan. * `cancel_current` — optional boolean. Set it to `true` to stop the active agent turn before Strix sends the message. * `agent_id` — optional target agent id. If you omit it, the message goes to the scan root agent. **Required scope:** `scans:message` ## Readiness and errors The API applies the same guardrails as the dashboard UI: * `403` if the organization does not have the enterprise `live_scan_prompt` feature * `409` if the scan is not active (`pending` or `running`) * `503` until the scan sandbox bridge is ready When the bridge is ready, Strix sends the prompt to the running agent through the `/user-message` endpoint of the scan sandbox. # Login Methods Source: https://docs.app.strix.ai/guides/login-methods Select the correct login method for a test user, and verify that Strix can sign in A test user tells Strix how to sign in to your application. Sign in to the application yourself. Then select the method that the application asks you for. ## The four methods The account signs in with a username (or email) and a password. There is no second factor. Start with this method. It needs the least configuration, and it is the fastest method to verify. Give Strix these items: 1. The username or the email address of the account. 2. The password of the account. The application asks for a code of 6 digits from an authenticator app, for example Google Authenticator, Authy, or 1Password. Some applications call this code a TOTP code. Give Strix these items: 1. The username and the password of the account. 2. The setup key of the account. The setup key is the Base32 secret behind the **Can't scan?** link on the enrollment page. Strix makes each code from the setup key. Thus Strix does not need your telephone. Strix cannot use a factor that asks a person to approve the login, for example Duo Push, Okta Verify push, or SMS. The application sends a numeric code to the email address of the account. Usually the application also asks for a password. Give Strix these items: 1. A Strix inbox as the email address of the account. 2. The password of the account, if the application asks for one. Strix must read the code. Thus Strix must be the owner of the mailbox. The account has no password. The application sends a link (or a code) that signs you in. Give Strix one item: a Strix inbox as the email address of the account. This method has the same condition as Email Code. Strix must be the owner of the mailbox. ## An account with MFA needs a Strix inbox Strix can only complete a second factor that it controls. Strix controls a setup key that you give it, and email that comes to a Strix inbox. Strix cannot read a code that goes to your telephone or to your own mailbox. Do these steps for the Email Code method and for the Magic Link method: 1. Make a Strix inbox in the test-user dialog. As an alternative, use the [provision-inbox endpoint](/guides/test-users#provision-a-managed-inbox). 2. Make a new test account with the inbox address, or change the email address of an existing account to the inbox address. 3. Switch on email login for that account. The inbox address is also the username of the account. Thus you give the address one time. Strix removes an inbox that no scan used for 30 days. You can make a new inbox at any time. ## Login verification Strix verifies the credentials when you save them. The verification is a short run, usually one or two minutes, in the same sandbox that a scan uses. Strix opens the login page, signs in, and reports if it got access to authenticated content. The test user then shows one of two results: verified or failed. Thus you find a bad login before the scan, and not after it. This table gives the usual failures and the correction for each failure: | Result | Correction | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | The username or the password is wrong | Give the credentials again. Make sure that the account does not use SSO only. | | Strix did not find the login page | Set **Login URL** in the **Advanced** section to the correct sign-in page. | | The login needs a second factor that Strix does not have | Select **Authenticator App** and give the setup key, or move the account to a Strix inbox. | | Strix could not read the code | Make sure that the email address of the account is the Strix inbox address, and that email login is on. | | The account is locked, or bot protection stopped the login | Unlock the account, or permit the scan traffic. | You can start a scan after a failed verification. Strix first shows a warning, because the scan can possibly test no authenticated area. To do a verification with the API, refer to [Verify a test user's login](/guides/test-users#verify-a-test-users-login). # MCP server Source: https://docs.app.strix.ai/guides/mcp Connect ChatGPT, Claude, Cursor, and other MCP clients to your Strix workspace Strix hosts a remote Model Context Protocol (MCP) server. An AI assistant that supports remote MCP servers can start scans, read vulnerabilities, manage schedules, and use the rest of the Strix API as tools. The server URL is: ```text theme={null} https://app.strix.ai/mcp ``` The server uses the Streamable HTTP transport and OAuth 2.1 authorization. You do not create an API token for MCP. You sign in to Strix in the browser when the client asks. ## Add the server to a client Most clients ask for a name and a server URL. Enter `Strix` and `https://app.strix.ai/mcp`. The client then opens a browser window for the Strix sign-in. After you sign in and approve the request, the client can call the Strix tools. ### Claude Add a custom connector in the Claude connector settings. Enter the server URL and select **Connect** to complete the sign-in. ### ChatGPT Enable developer mode in the ChatGPT connector settings. Create a connector with the server URL and select OAuth as the authentication method. ### Cursor Add this entry to `.cursor/mcp.json` and complete the sign-in when Cursor asks: ```json theme={null} { "mcpServers": { "strix": { "url": "https://app.strix.ai/mcp" } } } ``` ### Other clients Any client that supports remote MCP servers with OAuth can use the same URL. If the client asks for authorization server details, the client can read them from the discovery documents that this page describes. ## Workspace and permissions The sign-in binds the OAuth access token to one Strix workspace. Tools then run as you, in that workspace. Access tokens expire after one hour. The server advertises the `offline_access` scope. A client that requests this scope receives a refresh token and renews the session without a new sign-in. Your member role limits the tools that you can use. The same rules apply to API tokens: * A **viewer** can call read tools only. * An **analyst** can also call tools that start scans and change data. * An **admin** can also call tools for members, invitations, webhooks, and the audit log. If your membership has resource-level restrictions, the tools return only the targets, tags, or business units that you can access. The MCP server does not accept a Strix API token. The REST API does not accept an MCP access token. Use API tokens with the REST API and use the OAuth sign-in with MCP. ## Tools The server exposes one tool for each REST API operation that works without a browser. The tool name is the `operationId` of the operation in the API reference, written in `snake_case`. For example, the `POST /api/v1/scans` operation has the `createScan` operation ID and becomes the `create_scan` tool. Every tool argument carries a description that matches the parameter description in the API reference. The server also accepts the `operationId` as a tool name. Clients that cached the previous names, for example `createScan`, continue to work. Each tool declares MCP annotations so that the assistant can ask for your confirmation before it makes a change: | Annotation | Meaning | | ----------------- | ----------------------------------------------------------------------------------- | | `readOnlyHint` | The tool reads data and does not change the workspace. | | `destructiveHint` | The tool deletes or overwrites existing data, or runs a command. | | `idempotentHint` | A repeated call with the same input has no additional effect. | | `openWorldHint` | The tool contacts systems outside Strix, for example a scan target or a repository. | Tools that start scans, retests, PR reviews, or chats spend credits. Confirm the target with the assistant before it calls one of these tools. Every tool that returns a JSON body declares an `outputSchema`. Clients that support structured results receive the API response in `structuredContent`. When the API returns a JSON object, `structuredContent` is that object. When the API returns an array or `null`, `structuredContent` wraps the body as `{ "result": ... }` because MCP structured results must be objects. Tools such as `get_scan_frequency` and `get_vulnerability_history` return wrapped results. The `get_scan_sarif` tool returns the SARIF document as an object. The `list_audit_events` tool always returns JSON. Use the REST API for the CSV, NDJSON, Snowflake, and Splunk export formats. ### Tool profiles The default URL exposes every available tool. Some clients limit the number of tools per server or select tools less accurately when a server exposes many tools. For these clients, connect to the curated `core` profile: ```text theme={null} https://app.strix.ai/mcp?profile=core ``` | Profile | URL | Tools | | ------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | `full` | `https://app.strix.ai/mcp` | Every available tool. | | `core` | `https://app.strix.ai/mcp?profile=core` | Scans, vulnerabilities, assets, schedules, PR reviews, supply chain, knowledge, analytics, credits, and the organization. | The `core` profile does not include workspace administration tools such as members, invitations, webhooks, integrations, connectors, test users, chat, and the audit log. A call to a tool outside the connected profile returns an error result that names the profile that includes the tool. An unknown `profile` value returns `400 Bad Request`. The server does not expose these operations: * API token and CLI session management. * Billing checkout, billing portal, and credit purchases. * Connector install links and connector credential intake. * Network connector creation and the connector deploy command. * LLM provider key updates and engagement credential intake. * File upload, scan report download, and chat workspace file download. The `create_webhook` tool creates the webhook but does not return the signing secret. The `update_webhook` tool cannot rotate the secret. Open the dashboard to rotate a webhook secret. Use the dashboard or the REST API for these operations. ## Prompts The server also exposes MCP prompts. Clients such as Claude and Cursor show them as reusable commands. Each prompt tells the assistant which tools to call and how to present the result. | Prompt | Arguments | Purpose | | ------------------------ | ------------------------------------------- | ---------------------------------------------------------------- | | `triage_vulnerabilities` | `severity` (optional), `scan_id` (optional) | Group open findings by severity and recommend fixes. | | `scan_summary` | `scan_id` | Summarize one scan and its findings. | | `start_scan` | `target` (optional) | Choose an asset, confirm the cost, then start a scan. | | `pr_review_status` | `repository` (optional) | Report recent PR reviews and their findings. | | `weekly_security_report` | `audience` (optional) | Build a weekly report from scans, open findings, and PR reviews. | The `start_scan` prompt asks the assistant to wait for your confirmation before it calls `create_scan`. ## Discovery documents MCP clients and directories find the authorization server and the tool catalog with these documents. You do not need to read them to use the server. | Document | URL | | ---------------------------------------- | ------------------------------------------------------------- | | Protected resource metadata (RFC 9728) | `https://app.strix.ai/.well-known/oauth-protected-resource` | | Authorization server metadata (RFC 8414) | `https://app.strix.ai/.well-known/oauth-authorization-server` | | Server card | `https://app.strix.ai/mcp/server-card` | | AI catalog | `https://app.strix.ai/.well-known/ai-catalog.json` | The server card lists the server identity, the version, the icon, the remote endpoint, and the protocol versions that the server supports. Directories that cannot complete OAuth read this document to index the server. The server card does not list the tools or the prompts. Clients get them from the server after sign-in. The server card contains no workspace data. The AI catalog is the entry point for discovery clients. It points to the server card. The protected resource metadata lists the Strix authorization server and the OAuth scopes `openid`, `profile`, `email`, and `offline_access`. The client does not request Strix scopes during sign-in. The server derives your permissions from your role and your RBAC settings. The permission names match the API token scopes in [Authentication](/authentication). ## Errors If a request has no valid access token, the server returns `401 Unauthorized` with a `WWW-Authenticate` header. The header points to the protected resource metadata so that the client can start the sign-in. If a tool needs a scope that your role does not grant, the tool returns an error result with the missing scope name. The assistant can show this message to you. If a tool call fails in the REST API, the tool returns the API error message. The HTTP status of the MCP response stays `200`. # PR Reviews Source: https://docs.app.strix.ai/guides/pr-reviews Trigger and inspect automated pull request security reviews A PR review runs Strix on one pull request and shows the findings inline. ## Ways to trigger a review After you install the GitHub App on a repository, reviews start: * **Automatically when a PR is opened** (or marked ready for review). Strix does not review draft PRs. * **Automatically on new pushes to an open PR** when `review_on_push` is enabled in your PR review settings. * **When you tag Strix in a PR comment.** To start (or restart) a review, write `@strix` or `@strix-security` in a PR comment or an inline review comment. The commenter must be a repository owner, member, or collaborator. Comments from GitHub Apps and bots also start a review. * **Through the API** with `POST /api/v1/pr-reviews/start` (refer to the section below). ## List PR reviews ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/pr-reviews?limit=20" \ -H "Authorization: Bearer " ``` **Required scope:** `pr_reviews:read` The CLI's human view shows the repository, PR number and title, branches, pull-request lifecycle, review status/verdict, and open/total findings. Request exact totals for every review disposition group and lane with: ```bash theme={null} strix cloud pr-reviews list --include-counts ``` Use `--json` for the complete records and stable IDs in an agent workflow. ## Get a PR review ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/pr-reviews/" \ -H "Authorization: Bearer " ``` **Required scope:** `pr_reviews:read` ## List security issues caught by PR reviews List every security issue that the PR reviews of your organization caught. Each issue appears once. Strix collapses repeated reports of the same issue across the review runs of one pull request. Dependency CVEs and retest rows are excluded. Set `include_stats=true` to also get the all-time impact numbers: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/pr-reviews/findings?include_stats=true" \ -H "Authorization: Bearer " ``` **Required scope:** `pr_reviews:read` You can filter with `severity`, `pr_state`, `search`, and `repository_full_name`. The matching CLI command can include the all-time impact totals: ```bash theme={null} strix cloud pr-reviews findings --include-stats ``` Use `--json` when an agent needs the complete finding records. ## Start a PR review Start a review for a pull request. Specify the provider and installation ID from the repository record, plus the repository full name and PR number: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/pr-reviews/start" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "provider": "github", "installation_id": 12345678, "repository_full_name": "my-org/my-repo", "pr_number": 42 }' ``` **Required scope:** `pr_reviews:write` The open-source CLI exposes the same operation as `strix cloud pr-reviews start --provider github --installation-id 12345678 --repository-full-name my-org/my-repo --pr-number 42`. Use `strix cloud repos list` to read `provider` and `installation_id`. ## PR review settings Read the PR review configuration of your organization: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/pr-reviews/settings" \ -H "Authorization: Bearer " ``` **Required scope:** `pr_reviews:read` The `review_on_push` setting controls automatic reviews when you push commits to an open PR. When this setting is off, reviews run only when a PR is opened or when a comment includes `@strix`. Update one or more settings. The PATCH body is partial, but it must include at least one supported field: ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/pr-reviews/settings" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"review_on_push":true}' ``` **Required scope:** `pr_reviews:write` # Pentests Source: https://docs.app.strix.ai/guides/scans Start, monitor, and download pentest results ## List pentests Get pentests with optional filters and pagination. ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/scans?limit=20" \ -H "Authorization: Bearer " ``` By default, the list does not include per-finding retest scans. To include them, pass `include_retests=true`. **Required scope:** `scans:read` ## Verify a domain Strix scans a domain only after you prove that you own the domain. Add the domain, then call the verify endpoint. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/domains//verify" \ -H "Authorization: Bearer " ``` **Required scope:** `assets:write` A `200` response does not mean success. Read the `status` field: * `verified` — Strix confirmed ownership. The `verification_method` field names the method that passed. You can start scans against the domain. * `pending` — Strix found no verification record yet. The `next_steps` list gives one instruction per method and the retry command. The `verification` object contains the DNS record, the file URL and content, and the meta tag. Add one of the records, then call the endpoint again. DNS changes can take up to 24 hours to propagate. The CLI command is `strix cloud domains verify `. ## Start a new pentest Provide `domain_ids` for blackbox pentests or `repository_ids` for whitebox pentests. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/scans" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "domain_ids": [""], "concerns": "Check for authentication bypass vulnerabilities" }' ``` **Required scope:** `scans:write` ### Retry a launch safely Creating a scan is billable and may outlive an interrupted HTTP response. Send an `Idempotency-Key` when you call the API directly, and reuse the exact same key and request body after a timeout, connection loss, `429`, retryable `409`, or `5xx` response: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/scans" \ -H "Authorization: Bearer " \ -H "Idempotency-Key: scan-$(uuidgen)" \ -H "Content-Type: application/json" \ -d '{"domain_ids":[""]}' ``` Keys are retained for 24 hours and are bound to the authenticated actor, operation, and canonical request. Reusing a key for different input returns `409 Conflict`. A completed retry is replayed only after Strix rechecks the caller's current authorization. Use a new key only for a deliberate new scan. The CLI generates a key automatically for `scans start` and `scans rerun`; use `--idempotency-key` when an agent needs to persist the key across processes. ### Pentest depth The optional `scan_tier` field sets the pentest depth. The depth controls how deep the pentest goes and which model quality it uses: * `lite` — the full standard methodology at the lowest price (×0.3 credits). * `standard` — balanced testing at a lower price (×0.75 credits). * `ultra` — the deepest pentest and the default (×1, the standard price). The multiplier applies to the pentest's credit price. The field is not applicable on self-hosted deployments, for organizations with raw model selection, and for organizations on the Enterprise plan. Managed SaaS users normally choose only these three depth tiers; they do not submit arbitrary provider/model identifiers. A small set of explicitly enabled workspaces has a separate curated or raw model picker. Self-hosted deployments can instead select a named `model_config_id` configured by an administrator. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/scans" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "domain_ids": [""], "scan_tier": "ultra" }' ``` ## Get pentest detail ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/scans/" \ -H "Authorization: Bearer " ``` **Required scope:** `scans:read` ## Rerun a pentest Run a previous pentest configuration again: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/scans//rerun" \ -H "Authorization: Bearer " \ -H "Idempotency-Key: rerun-$(uuidgen)" ``` **Required scope:** `scans:write` ## Cancel a pentest Cancel a pending or running pentest: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/scans//cancel" \ -H "Authorization: Bearer " ``` **Required scope:** `scans:write` ## Download report Report downloads are available on the Enterprise plan. The default report is a technical PDF; `retest`, `attestation`, and `executive_summary` formats and DOCX output are also available. ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/scans//report" \ -H "Authorization: Bearer " \ -o report.pdf ``` **Required scope:** `scans:read` The CLI can write the response directly to a file and add optional cover branding: ```bash theme={null} strix cloud scans report \ --format executive_summary \ --type docx \ --provider-name "Acme Security" \ --member-name-0 "Alex Doe" \ --member-email-0 "alex@example.com" \ --output report.docx ``` `--provider-name` accepts up to 80 characters. Add up to two preparers with `--member-name-0` / `--member-email-0` and `--member-name-1` / `--member-email-1`; each member field accepts up to 120 characters. Existing output files are not replaced unless `--force` is explicit. ## Retest findings List the retests recorded for a pentest: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/scans//retests" \ -H "Authorization: Bearer " ``` **Required scope:** `scans:read` Run validation again for each finding in a pentest: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/scans//retest-all" \ -H "Authorization: Bearer " ``` **Required scope:** `scans:write` ## Get a reusable template Get the configuration of a pentest as a template. You can use the template to start new pentests: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/scans//template" \ -H "Authorization: Bearer " ``` **Required scope:** `scans:read` ## Delete a pentest ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/scans/" \ -H "Authorization: Bearer " ``` **Required scope:** `scans:write` # Schedules Source: https://docs.app.strix.ai/guides/schedules Create and manage recurring pentest schedules ## List schedules ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/schedules" \ -H "Authorization: Bearer " ``` **Required scope:** `schedules:read` ## Create a schedule A schedule requires `cron_expression`, `timezone`, and at least one target in `domain_ids`, `repository_ids`, `upload_ids`, or `internal_targets`. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/schedules" \ -H "Authorization: Bearer " \ -H "Idempotency-Key: schedule-$(uuidgen)" \ -H "Content-Type: application/json" \ -d '{ "name": "Weekly production pentest", "cron_expression": "0 9 * * 1", "timezone": "America/New_York", "domain_ids": [""], "also_run_now": false }' ``` **Required scope:** `schedules:write` With `also_run_now: false`, this creates the recurring schedule without launching or charging a scan. With `also_run_now: true`, the immediate run goes through the same pre-launch credit check as an ordinary scan. If a non-Enterprise workspace lacks the estimated credits, the endpoint returns HTTP `402 Payment Required`; neither the schedule nor the immediate scan is created, and no credits are consumed. Enterprise scans are plan-included. Set `supply_chain: true` for a free dependency scan schedule. Supply-chain schedules accept repository targets only and require the Enterprise Supply Chain entitlement, but their runs do not consume scan credits. When `also_run_now` starts a billable scan, retain the `Idempotency-Key` and reuse the exact request after an interrupted or retryable response. The key is bound to the actor and request for 24 hours, so a retry cannot create or charge a second immediate run. The CLI supplies this key automatically. ## Get schedule detail ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/schedules/" \ -H "Authorization: Bearer " ``` **Required scope:** `schedules:read` ## Get a schedule's editable configuration This endpoint returns the full stored configuration of the schedule in a format that you can edit with PATCH. The configuration includes targets, prompts, test users, headers, scope, timing, notifications, and uploads. The response gives stored secrets (passwords, TOTP seeds, and header values) as metadata only, not in plaintext. ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/schedules//template" \ -H "Authorization: Bearer " ``` **Required scope:** `schedules:read` ## Pause a schedule ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/schedules/" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"action": "pause"}' ``` To resume, use `{"action": "resume"}`. You can also update the schedule configuration (name, cron\_expression, timezone, targets) in the same PATCH request. **Required scope:** `schedules:write` ## Delete a schedule ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/schedules/" \ -H "Authorization: Bearer " ``` **Required scope:** `schedules:write` ## Trigger a schedule immediately Run a scheduled pentest configuration immediately, before the next cron interval: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/schedules//trigger" \ -H "Authorization: Bearer " \ -H "Idempotency-Key: trigger-$(uuidgen)" ``` **Required scope:** `schedules:write` The trigger uses the stored scope estimate. If a non-Enterprise workspace lacks enough credits, it returns HTTP `402 Payment Required`, creates no scan, and consumes no credits. The CLI reports this as exit code `5`. Enterprise runs are credit-exempt. Recurring fires also check the wallet before launch. A run that cannot be funded is skipped rather than launched without a charge. If automatic top-up is enabled, Strix may first try the configured top-up policy; otherwise add credits before the next fire. Manual triggers use the same 24-hour idempotency contract as scan creation. Reuse the exact key and request after an ambiguous response. A delayed or duplicate queue delivery is collapsed before billing or launch. # ServiceNow Integration Source: https://docs.app.strix.ai/guides/servicenow-integration Connect Strix to ServiceNow to export vulnerabilities as Incident or Task records Strix connects natively to ServiceNow. Strix can export the vulnerabilities that scans and PR reviews find as records on the ServiceNow `incident` table or the `task` table. You select the record type when you connect. Strix posts status changes and comments to those records as work notes. Every 5 minutes, Strix reads the state of the linked records and updates the Strix issues. This page describes the setup, the two authentication methods, the permissions that Strix needs, the data that Strix sends, and the disconnect procedure. ## Overview | | | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Integration type | Native ServiceNow Table API client. No third-party middleware in the data path | | Direction | Two-way. Strix creates and updates records. Strix reads the state of linked records every 5 minutes, see [What data flows where](#what-data-flows-where) | | Record type | `incident` (default) or `task`. You select the record type when you connect. The `task` table needs one extra ACL, see [Use the Task record type](#use-the-task-record-type) | | Authentication | OAuth 2.0 Client Credentials (recommended) or username and password of an integration user | | Who can connect | Strix organization **admins** only | | Scope of access | One ServiceNow instance for each Strix organization | | Destination | A ServiceNow assignment group | ## Before you start Strix needs a ServiceNow identity that has the `itil` role. The `itil` role permits the identity to read the `sys_user_group` table and to create and update records on the `incident` table. On a standard instance, the `itil` role cannot create records on the base `task` table. If you want Task records, a ServiceNow admin must add one ACL, see [Use the Task record type](#use-the-task-record-type). Do not use a personal account. Select one authentication method: | | OAuth client (recommended) | Username and password | | ------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------- | | What you paste into Strix | Client ID and client secret | Username and password | | ServiceNow identity | The **OAuth Application User** of the OAuth API endpoint | The integration user | | Tokens | Strix requests short-lived bearer tokens from your instance. Strix never stores a password | Strix sends the password with every request | | ServiceNow release | Washington DC or later, with the Client Credentials grant enabled | Any release | ### Option A: Create an OAuth API endpoint (recommended) A ServiceNow administrator with the `admin` role does these steps in your instance. The Strix connect dialog shows the same steps. After you enter the instance URL in the dialog, each step links into your instance. The steps differ by ServiceNow release. Do the steps for your release only. 1. Set the system property `glide.oauth.inbound.client.credential.grant_type.enabled` to `true`. Open `sys_properties.list` in the filter navigator and search for the property. If the property does not exist, open this URL on your instance to get a prefilled form, then click **Submit**: ```text theme={null} https://.service-now.com/sys_properties.do?sys_id=-1&sysparm_query=name=glide.oauth.inbound.client.credential.grant_type.enabled^type=boolean^value=true ``` Without this property, token requests fail with `access_denied`. 2. Create a service account user. The **Create a user** link in the Strix dialog opens a prefilled form. If you open `sys_user.do?sys_id=-1` yourself, enter a **User ID**, for example `strix-integration`, a **First name**, and a **Last name**. Set **Identity type** to **Machine**. Select **Internal Integration User**. The user does not need a password. Right-click the form header and click **Save**, not **Submit**, so the record stays open. 3. In the **Roles** list at the bottom of the saved user, click **Edit…**, add `itil`, and click **Save**. 4. Go to **System OAuth → Application Registry** and click **New**. ServiceNow rejects records that are inserted directly into the `oauth_entity` table, so always start from **New**. 5. Select **New Inbound Integration Experience → New Integration → OAuth – Client credentials grant**. You can also start from **Machine Identity Console → Inbound integrations → New integration**. 6. Set **Name** and **Provider name** to `Strix`. Set **OAuth application user** to the user from step 2. The picker shows only users that have a first name and a last name. 7. Under **Scope validation settings**, clear **Allow access only to APIs in selected scope**. Do not add an auth scope. Leave **Advanced options** unchanged. Click **Save**. 8. Copy the **Client ID** and the **Client secret**. The eye icon shows the secret. 1. Set the system property `glide.oauth.inbound.client.credential.grant_type.enabled` to `true`. Open `sys_properties.list` in the filter navigator and search for the property. If the property does not exist, open this URL on your instance to get a prefilled form, then click **Submit**: ```text theme={null} https://.service-now.com/sys_properties.do?sys_id=-1&sysparm_query=name=glide.oauth.inbound.client.credential.grant_type.enabled^type=boolean^value=true ``` Without this property, token requests fail with `access_denied`. 2. Create a service account user. The **Create a user** link in the Strix dialog opens a prefilled form. If you open `sys_user.do?sys_id=-1` yourself, enter a **User ID**, for example `strix-integration`, a **First name**, and a **Last name**. Select **Web service access only**. If the form shows **Internal Integration User**, select it. The user does not need a password. Right-click the form header and click **Save**, not **Submit**, so the record stays open. 3. In the **Roles** list at the bottom of the saved user, click **Edit…**, add `itil`, and click **Save**. 4. Go to **System OAuth → Application Registry** and click **New**. ServiceNow rejects records that are inserted directly into the `oauth_entity` table, so always start from **New**. 5. Select **Create an OAuth API endpoint for external clients**. On Yokohama, this option has the prefix **\[Deprecated UI]**. The classic form is the correct path for these releases. 6. Set **Name** to `Strix`. Leave **Client Secret** and **Redirect URL** empty. ServiceNow generates the secret. Do not add an auth scope. Click **Submit**. 7. Open the saved record. If the form does not show the **OAuth Application User** field, right-click the form header and select **Configure → Form Layout**, then add the field. 8. Set **OAuth Application User** to the user from step 2. Click **Update**. 9. Copy the **Client ID**. Click the padlock on **Client Secret** and copy the secret. The Client Credentials grant is a machine-to-machine flow. It does not use a redirect URL, a login URL, or a refresh token. Every request that Strix makes runs as the OAuth application user, so that user's roles control the access. ### Option B: Create an integration user Use this option if your instance does not support the Client Credentials grant. 1. Create a user. The **Create a user** link in the Strix dialog opens a prefilled form. If you open `sys_user.do?sys_id=-1` yourself, enter a **User ID**, for example `strix-integration`, a **First name**, and a **Last name**. On Zurich or later, set **Identity type** to **Machine**. On earlier releases, select **Web service access only**. Click **Set Password**, generate a password, and copy it. Right-click the form header and click **Save**, not **Submit**, so the record stays open. 2. In the **Roles** list at the bottom of the saved user, click **Edit…**, add `itil`, and click **Save**. ## Setup 1. In Strix, go to **Settings → Integrations** and click **Connect** on the ServiceNow card. You must be an organization admin, and your plan must include ticketing integrations. 2. Enter the instance URL or hostname, for example `acme.service-now.com`. Strix uses HTTPS. The setup links below the authentication choice open in your instance after you enter the URL. 3. Under **Authentication**, select **OAuth client** or **Username and password**. The default is **OAuth client**. 4. Enter the client ID and the client secret, or the username and the password. 5. Select the **record type**. **Incident** creates ITSM incidents on the `incident` table. **Task** creates generic work items on the `task` table. The default is **Incident**. If you select **Task**, Strix shows the ACL steps from [Use the Task record type](#use-the-task-record-type). Click **Connect**. 6. Strix verifies the credentials before it stores them. For an OAuth client, Strix first requests a token from `/oauth_token.do`. Then Strix reads the selected record table and the `sys_user_group` table. If the verification fails, Strix shows the reason and does not store the credentials. 7. In Strix, select a **default assignment group** as the export destination. You can also enable **auto-sync** with a minimum severity. Auto-sync exports new findings automatically. You can also connect through the API. With an OAuth client: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/integrations/servicenow/connect" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "instance_url": "https://acme.service-now.com", "auth_method": "oauth_client_credentials", "client_id": "", "client_secret": "", "record_type": "incident" }' ``` With an integration user: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/integrations/servicenow/connect" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "instance_url": "https://acme.service-now.com", "auth_method": "basic", "username": "strix-integration", "password": "", "record_type": "incident" }' ``` **Required scope:** `integrations:write` The `auth_method` field is optional. Permitted values are `oauth_client_credentials` and `basic`. If you omit `auth_method`, Strix uses `basic` when the body has `username` and no `client_id`. In all other cases Strix uses `oauth_client_credentials`. The `record_type` field is optional. Permitted values are `incident` and `task`. The default is `incident`. If you connect the same organization to a different instance URL, Strix clears the default assignment group and the links between vulnerabilities and records. If you connect with a different record type, Strix clears the links between vulnerabilities and records but keeps the default assignment group. If you only change the credentials or the authentication method for the same instance, Strix keeps the settings and the links. To change the authentication method, connect again. ### Change the record type You can change the record type after you connect. In Strix, open the ServiceNow card and click **Settings**. Under **Record type**, select **Incident** or **Task**. Strix saves the change immediately. Record identifiers are specific to one table. When you change the record type, Strix removes the links between vulnerabilities and the existing records. Strix does not delete the records in ServiceNow. The next export creates a new record on the selected table. ### Use the Task record type Most ServiceNow integrations create Incident records. Incident is the table that every ITSM instance has, with assignment groups, SLAs, and workflows in place. Strix uses Incident as the default for that reason. Select **Task** if your team tracks security work as generic tasks. On a standard instance, the `itil` role can create Incident records but cannot create records on the base `task` table. ServiceNow rejects the insert with `ACL Exception Insert Failed due to security constraints`. A ServiceNow admin must add one create ACL. This is a one-time step. 1. In ServiceNow, open your profile menu and click **Elevate role**. Select **security\_admin** and click **OK**. 2. In Strix, select **Task** as the record type and click **Open the prefilled ACL form**. The link opens `sys_security_acl.do` in your instance with **Type** set to `record`, **Operation** set to `create`, and **Name** set to `task`. Check the three values. You can also open **System Security → Access Control (ACL)**, click **New**, and enter those three values. 3. Right-click the form header and click **Save**. 4. Under **Requires role**, click **Edit…**, add `itil`, and click **Save**. After the ACL exists, Strix can create Task records with the same identity. Until then, an export to the `task` table fails with a message that names the missing ACL. Incident records need no extra step. ### Troubleshooting the OAuth connection | Message from Strix | Cause | Action | | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | ServiceNow returned access\_denied for this OAuth client | ServiceNow returns the same error for a wrong client ID or secret, for a disabled Client Credentials grant, and for a missing OAuth application user | Set `glide.oauth.inbound.client.credential.grant_type.enabled` to `true`, set the OAuth application user on the record, and copy the values again | | ServiceNow did not issue a token for this OAuth client | The Client Credentials grant is not enabled, or the record has no OAuth Application User | Do step 1 and step 6 or step 8 of Option A | | The OAuth Application User cannot read incident records or assignment groups | The service account does not have the `itil` role, or the OAuth record limits access to selected auth scopes. ServiceNow returns HTTP 200 with an empty `result` array in this case, and `X-Total-Count` shows the hidden rows | Give the service account the `itil` role. Clear **Allow access only to APIs in selected scope** and remove auth scopes | | ServiceNow denied creating a Task record | The base `task` table has no create ACL for the `itil` role | Add the ACL from [Use the Task record type](#use-the-task-record-type), or select **Incident** as the record type | | Message from ServiceNow | Cause | Action | | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | | `Invalid insert` on the OAuth form | The record was opened directly instead of through **New** | Open **Application Registry**, click **New**, and select the flow for your release | | **OAuth application user** shows no results | The service account has no first name or last name | Add a first name and a last name to the user | | `Access to unscoped api is not allowed` | The OAuth record limits access to selected auth scopes | Clear **Allow access only to APIs in selected scope** and remove auth scopes | | `ACL Exception Insert Failed due to security constraints` | The identity has no create ACL on the selected table. With the `itil` role, this happens on the `task` table | Add the ACL from [Use the Task record type](#use-the-task-record-type), or select **Incident** | ## What data flows where **Strix → ServiceNow** (when you export a vulnerability manually, or when auto-sync exports it): * `short_description`: the vulnerability title, cut to 160 characters. * `description`: severity, CVSS and CVE (when present), target, endpoint or affected file, impact, technical analysis, evidence, suggested fix or remediation steps, proof of concept, and a link back to the issue in Strix. Strix converts the Markdown to plain text. * `impact` and `urgency` mapped from severity. ServiceNow derives the record priority from these two fields. * `assignment_group`: the selected assignment group. * `due_date` when an issue is snoozed. * `state` when the Strix status changes. For `task` records, Strix maps Open to Open, In Progress to Work in Progress, On Hold to Pending, and Closed to Closed Complete. For `incident` records, Strix maps Open to New, In Progress to In Progress, On Hold to On Hold, and Closed to Resolved. * Work notes (for example, "marked In Progress by …") when the Strix status changes. **ServiceNow → Strix** (scheduled, every 5 minutes): ServiceNow does not offer an API that lets a third party subscribe to record changes. Strix therefore reads the state of the linked records with the credentials that you already provided. This is the same model that Vanta and Drata use. You do not need a Business Rule, an Outbound REST Message, or a Store app. * Strix reads only the records that it created. Strix requests the `sys_id`, `number`, `state`, `due_date`, `sys_updated_by`, and `sys_updated_on` fields. * Strix maps the ServiceNow state to the Strix issue status. For `incident` records, Resolved, Closed, and Canceled mark the issue **fixed**. In Progress marks the issue **in progress**. New reopens a fixed issue. For `task` records, Closed Complete, Closed Incomplete, and Closed Skipped mark the issue **fixed**. Work in Progress marks the issue **in progress**. Open reopens a fixed issue. * On Hold (`incident`) and Pending (`task`) snooze the issue until the `due_date` of the record. Without a future `due_date`, Strix leaves the issue unchanged. * A change in ServiceNow appears in Strix within about 5 minutes. The sync is not realtime. * Strix does not overwrite an issue that you marked **ignored** or **not affected** in Strix when the record is closed in ServiceNow. * Strix adds a note to the issue, for example "Updated from ServiceNow — ticket INC0010005 by admin". * When ServiceNow no longer returns a record, for example after a deletion, Strix leaves the issue unchanged. * When ServiceNow rejects the credentials, Strix sets the integration to **reconnect required** and stops the sync until an admin reconnects. Strix does not read comments, attachments, or user directories. ## Security * **Admin-gated**: The connect endpoint requires an authenticated Strix org admin. * **Credential verification**: Strix verifies the credentials against your instance before it stores them. * **Encrypted storage**: Strix encrypts the client secret or the password with AES-256-GCM before it writes it to the database. The browser and other tenants cannot read it. The API does not return the client secret or the password. * **Short-lived tokens**: With an OAuth client, Strix keeps the bearer token in memory only for its lifetime, 30 minutes by default. Strix requests a new token when the token expires or when ServiceNow rejects it. * **Outbound request protection**: Strix resolves the instance host and blocks requests to private network addresses. * **Audit trail**: The Strix audit log records the connection of the integration and the changes to the settings. ## Disconnecting An org admin can disconnect ServiceNow at any time from **Settings → Integrations**, or through the API: ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/integrations/servicenow" \ -H "Authorization: Bearer " ``` **Required scope:** `integrations:write` The disconnect operation removes the stored credentials. Strix does not delete the records that it already created in ServiceNow. If you no longer need them, deactivate the application registry record or the integration user in ServiceNow. # Slack Integration Source: https://docs.app.strix.ai/guides/slack-integration Connect Strix to Slack for vulnerability alerts, thread discussions, and status updates Strix connects to Slack to post vulnerability alerts and scan updates into a channel that you select. Strix also shows the Slack discussion thread in the Strix dashboard. Your team can update the status of an issue directly from Slack. This page describes the setup, the bot scopes that Strix requests, the data that Strix and Slack exchange, and the disconnect procedure. ## Overview | | | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Integration type | Slack app installed through standard OAuth 2.0 (bot token) | | Direction | Bidirectional. Strix posts messages. Status changes made in Slack come back to Strix | | Who can connect | Strix organization **admins** only | | Where it posts | One default channel that an admin selects (public or private) | | Default behavior | Sends notifications for **critical** and **high** findings only. Scan-complete and status-change notifications are off until you enable them | ## Setup 1. In Strix, go to **Settings → Integrations** and click **Connect** on the Slack card. You must be an organization admin. 2. Approve the app on the standard Slack consent screen. Slack redirects back to `https://app.strix.ai/api/integrations/slack/callback`. There, Strix stores the bot token for your workspace. 3. Select a **default channel** for notifications. The bot joins public channels automatically. For a private channel, first invite `@Strix` to the channel, then select it. 4. If necessary, change the notification settings: the severities that create alerts (`critical`, `high`, `medium`, `low`), and the notifications for scan completion and issue status changes. ## Bot scopes requested | Scope | Why Strix needs it | | ------------------------------------ | ---------------------------------------------------------------------------------------------- | | `channels:read`, `groups:read` | List public and private channels so that an admin can select the default channel | | `channels:join` | Join the selected public channel automatically so that Strix can post | | `chat:write`, `chat:write.public` | Post vulnerability alerts and scan updates | | `channels:history`, `groups:history` | Read replies **in Strix-created threads only**, to show the discussion in the Strix dashboard | | `users:read` | Get the display names and avatars of users who replied in a Strix thread | | `commands` | Support Slack interactions (for example, an update of the status of an issue from the message) | The bot reads only the message threads that it started. It does not read general channel history, direct messages, or files. ## What data flows where **Strix → Slack**: * New-finding alerts (for the severities that you enabled): the finding title, severity, target, and a link to the issue in Strix. Strix posts them to the default channel. * Optional scan-complete and issue status-change notifications. **Slack → Strix**: * The Strix dashboard shows the replies in a Strix-created thread (message text, author name, avatar) adjacent to the issue. * Status updates from Slack (for example, when a user sets an issue to in progress, resolved, or snoozed) update the linked vulnerability in Strix. Strix records the ID of the Slack user who made the change. ## Security * **Admin-gated**: The install and callback endpoints require an authenticated Strix org admin. Only admins can change the notification settings. * **CSRF-protected OAuth**: The OAuth `state` is HMAC-signed and bound to the initiating organization and user. It expires after 10 minutes. * **Token storage**: Strix keeps the bot token server-side in its database. The token applies only to your organization. The browser and other tenants cannot see it. * **Tenant isolation**: Strix compares each inbound status update from Slack with the team ID of the workspace. Strix applies the update only to the issues of the organization that is linked to that workspace. Strix also checks each thread read against the organization of the requesting user. * **Private channels are opt-in**: Strix does not join private channels itself. A workspace member must invite `@Strix` explicitly. * **Audit trail**: The Strix audit log records the changes to the settings. ## Disconnecting An org admin can disconnect Slack at any time from **Settings → Integrations**, or through the API: ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/integrations/slack" \ -H "Authorization: Bearer " ``` **Required scope:** `integrations:write` The disconnect operation deletes the stored bot token and removes all Slack thread links from Strix issues. To remove the app fully from your workspace, a Slack workspace admin can also remove it in **Slack → Manage apps**. # Test Users Source: https://docs.app.strix.ai/guides/test-users Manage authenticated test users and inboxes for a domain With test users, Strix can log in to your application during a pentest. Each test user belongs to a domain. A test user can also have an MFA configuration and a Strix-managed inbox for email-OTP and magic-link flows. To find which method a login needs, or why a login failed, refer to [Login Methods](/guides/login-methods). ## List test users ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/domains//test-users" \ -H "Authorization: Bearer " ``` **Required scope:** `test_users:read` ## Create a test user ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/domains//test-users" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "label": "Standard user", "username": "tester@example.com", "password": "", "login_url": "https://app.example.com/login" }' ``` Strix stores passwords and TOTP secrets in encrypted form. Strix does not return them in responses. ### MFA Set `mfa_method` to `totp`, `email_otp`, or `magic_link`: * `totp` requires `totp_secret`. * `email_otp` and `magic_link` require `mfa_email`. This must be a Strix-managed inbox address (refer to the section below). The only accepted values are `none`, `totp`, `email_otp`, and `magic_link`. Any other value is rejected with `422`; it is never silently treated as no MFA. **Required scope:** `test_users:write` ## Update a test user This is a partial update. Only the fields that you send change: ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/domains//test-users/" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"notes": "Rotated password 2026-06"}' ``` **Required scope:** `test_users:write` ## Delete a test user ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/domains//test-users/" \ -H "Authorization: Bearer " ``` **Required scope:** `test_users:write` ## Provision a managed inbox Create a Strix-managed inbox address to receive MFA emails for a test user: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/domains//test-users/provision-inbox" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"label": "otp-inbox"}' ``` Use the returned address as `mfa_email` when you create or update a test user. **Required scope:** `test_users:write` ## Verify a test user's login Start a short verification to make sure that Strix can sign in with the stored credentials. The verification usually takes one or two minutes. It runs in the same sandbox that a scan uses. You must first verify that you are the owner of the domain. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/domains//test-users//verify" \ -H "Authorization: Bearer " ``` Strix uses a recent result again. To do the verification one more time after you change the credentials, add `?force=1`. **Required scope:** `test_users:write` Get the result: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/domains//test-users//verify" \ -H "Authorization: Bearer " ``` The `status` field is `pending`, `running`, `succeeded`, or `failed`. A failed verification also gives a `failure_code` field and a short `detail` field. Strix removes all secrets from the `detail` field. These are the possible values of `failure_code`: `invalid_credentials`, `login_page_not_found`, `mfa_required_not_configured`, `mfa_code_unavailable`, `account_locked`, `target_unreachable`, `bot_protection`, and `other`. **Required scope:** `test_users:read` ## Read a test user's inbox ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/domains//test-users//inbox?limit=25" \ -H "Authorization: Bearer " ``` Read a single message by id: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/domains//test-users//inbox/" \ -H "Authorization: Bearer " ``` **Required scope:** `test_users:read` # Uploads Source: https://docs.app.strix.ai/guides/uploads Upload local repositories and documentation for whitebox scans With uploads, you can run whitebox pentests on code or documentation that is not connected through an SCM integration. You can let the CLI select and package a local working tree, or use the three upload API calls directly. ## Start a scan from local source Review exactly what the CLI would send before uploading anything: ```bash theme={null} strix cloud scans start --source . --dry-run --show-files --json ``` The dry run builds the same bounded ZIP locally and prints its manifest, selected paths, exclusion counts, compressed size, and SHA-256 digest. It neither uploads the archive nor starts a scan. For an agent or CI workflow, capture `source.archive_sha256` after reviewing the manifest, then approve that exact source snapshot: ```bash theme={null} SOURCE_SHA256="" strix cloud scans start --source . --approve-sha256 "$SOURCE_SHA256" --wait ``` Repeat the same `--source`, every `--exclude`, and all `--include-*` selection flags. The CLI rebuilds the archive and rejects the upload if the source or selection flags produce a different digest. Non-interactive and JSON runs never prompt; they accept either a matching `--approve-sha256` or deliberate one-shot `--yes`. The latter approves only the archive built in that invocation and is best suited to a human or one-shot workflow, not a digest-bound agent handoff. In an interactive terminal, omitting both approval flags shows the source summary and asks `Upload this source and start the scan? [y/N]` for the current snapshot. ### Default privacy filters The CLI includes only regular files and respects Git ignores when the source is in a Git worktree. It excludes these by default: * version-control metadata such as `.git`, `.hg`, and `.svn`, plus symlinks and non-files * hidden files and directories * dependency, cache, coverage, and build directories such as `node_modules`, `vendor`, `venv`, `.venv`, `env`, `__pycache__`, `.tox`, `.pytest_cache`, `.mypy_cache`, `.ruff_cache`, `dist`, `build`, `coverage`, `target`, `.next`, `.nuxt`, and `.gradle` * secret-like filenames such as `.env`, private keys, `.git-credentials`, application-default credentials, and service-account files * common cloud, container, and cluster credential paths such as `.aws/credentials`, `.docker/config.json`, `.config/gcloud/credentials.db`, `.azure/accesstokens.json`, and `.kube/config` * nested archives * patterns in `.strixignore` and every repeated `--exclude GLOB` Use `--include-hidden`, `--include-sensitive`, or `--include-archives` only after reviewing a dry run. These approvals are independent: a hidden secret-like file such as `.env` needs both `--include-hidden` and `--include-sensitive`. Version-control metadata, symlinks, and dependency/build output remain excluded. `.strixignore` is exclusion-only and does not support negated `!` patterns. The CLI refuses a selection above 20,000 files, 25 MiB for any file, 250 MiB expanded in total, or 50 MiB for the compressed archive. It opens selected files without following symlinks and rejects replacements, appends, truncation, or metadata changes between selection and the completed archive read. The platform validates repository ZIPs again while streaming and inflating them. It rejects malformed or empty ZIPs, absolute or parent-traversal paths, more than 20,000 files, entries over 25 MiB, more than 250 MiB expanded, or more than 100 MiB compressed. A rejected upload cannot be attached to a scan and is removed immediately or by cleanup. ### Scan type and credits When `--engagement-type` is omitted, local source by itself infers `code_review`. Local source plus a domain infers `live_test`. An explicit engagement type takes precedence. An upload is scan input, not a free scan. A non-Enterprise scan consumes its normal scope estimate; at the current default `ultra` tier, a source-only code review starts at 60 credits. Enterprise scans are plan-included. A request rejected before launch does not consume credits, and the CLI makes a best-effort deletion of the staged upload when scan creation fails. See [Billing and credits](/guides/billing). ### Cleanup and ambiguous launches The CLI always removes its private temporary local archive. After a remote upload is staged, a definitive scan rejection causes the CLI to delete it. A network failure, `5xx` response, malformed success response, or interruption after launch begins is ambiguous because the platform may already have accepted the scan. In that case the CLI retains the upload and returns its `upload_id` with `launch_outcome_unknown: true`. If cleanup itself cannot be confirmed, it returns the retained ID with `cleanup_unknown: true`. Check `strix cloud scans list` before retrying an ambiguous launch. If no scan uses the upload, remove it with `strix cloud uploads delete `. ## Upload through the API The direct API procedure has three steps: request a signed URL, upload the file directly to storage, and finalize the upload. Finalizing stores an upload for later use; start a scan with its ID in `upload_ids` to analyze it. ## 1. Request a signed upload URL ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/uploads/request" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "file_name": "service.zip", "file_size": 1048576, "category": "repository" }' ``` The response contains an `upload_id`, `signed_url`, and upload `token`. Send the file to `signed_url` with `PUT`. Treat the short-lived upload token as a secret and do not log it. The `category` field is optional (`repository` or `documentation`). If you set `repository`, the file must be a ZIP code archive. If you omit the category, Strix selects it from the filename. **Required scope:** `uploads:write` ## 2. Upload the file Send the raw file bytes to the signed URL with `PUT`: ```bash theme={null} curl -X PUT "" \ -H "Authorization: Bearer " \ -H "Content-Type: application/zip" \ --upload-file service.zip ``` ## 3. Finalize the upload ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/uploads/complete" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"upload_id": ""}' ``` **Required scope:** `uploads:write` The completed upload is not scanned automatically. Pass its ID as `upload_ids` when you create a scan. Delete unused uploads rather than leaving source artifacts attached to the workspace. ## Delete an upload With the CLI: ```bash theme={null} strix cloud uploads delete ``` Or call the API directly: ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/uploads/" \ -H "Authorization: Bearer " ``` **Required scope:** `uploads:write` # Vulnerabilities Source: https://docs.app.strix.ai/guides/vulnerabilities List, inspect, and update vulnerability findings ## List vulnerabilities Get vulnerabilities from all pentests with filters and pagination. ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/vulnerabilities" \ -H "Authorization: Bearer " ``` **Required scope:** `vulnerabilities:read` ## Get vulnerability detail ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/vulnerabilities/" \ -H "Authorization: Bearer " ``` **Required scope:** `vulnerabilities:read` ## Inspect captured HTTP evidence Retrieve the ordered requests and responses linked to a finding: ```bash theme={null} curl "https://app.strix.ai/api/v1/vulnerabilities//http-exchanges?include_content=true" \ -H "Authorization: Bearer " ``` **Required scope:** `vulnerabilities:read`. Organization and asset access restrictions also apply. The `exchanges` array contains up to ten references in evidence order. Each entry includes `run_id`, `request_id`, `ordinal`, `lookup_state`, and request metadata. With `include_content=true`, an archived entry has `state: "archived"` and an `exchange` object containing `raw_request`, `raw_response`, `request_truncated`, and `response_truncated`. | State | Meaning | | ------------- | ---------------------------------------------------------------------------- | | `archived` | The captured request and response are available in `exchange`. | | `unarchived` | Request metadata exists, but the raw exchange was not stored or has expired. | | `not_found` | The linked request is no longer available. | | `unavailable` | The traffic or archive service could not be reached. Retry later. | Omit `include_content=true` to retrieve references and metadata only. Findings with no captured HTTP evidence, including static-only findings and older findings without links, return an empty array. Links identify captured exchanges; the API does not reconstruct missing traffic from the report text. In the dashboard, open an issue's **Reproduction** tab and select **Captured HTTP**. Exported tickets link to the same authenticated section. Request and response bodies are untrusted target content and may contain credentials or personal data; handle downloaded evidence accordingly. ## Update vulnerability status Set the status of a finding to in-progress or fixed, or add notes for remediation tracking: ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/vulnerabilities/" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"status":"in_progress","note":"Linked to remediation ticket"}' ``` **Required scope:** `vulnerabilities:write` ### Status values | Status | Description | | -------------- | ---------------------------------------------------- | | `open` | New finding, remediation not started | | `in_progress` | Remediation is in progress | | `snoozed` | Temporarily deferred until its snooze deadline | | `fixed` | Remediation is complete | | `ignored` | Known finding, risk accepted | | `not_affected` | Reviewed and determined not applicable to this asset | ## Retest a vulnerability Run validation again for one finding. This shows if the finding is still exploitable: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/vulnerabilities//retest" \ -H "Authorization: Bearer " ``` **Required scope:** `scans:write` ## Create a fix pull request Create a pull request that contains an AI-generated remediation for the finding: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/vulnerabilities//create-fix-pr" \ -H "Authorization: Bearer " ``` **Required scope:** `vulnerabilities:write` ## Get vulnerability history Get the lifecycle audit trail for a finding, including status, severity, snooze, note, and reason changes. Retest runs are not included: ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/vulnerabilities//history" \ -H "Authorization: Bearer " ``` **Required scope:** `vulnerabilities:read` # Webhooks Source: https://docs.app.strix.ai/guides/webhooks Subscribe to pentest and vulnerability lifecycle events ## Overview Webhooks send events to your endpoint when the events occur. Use webhooks to start remediation workflows, update dashboards, or send alerts to your team. ## Events | Event | Description | | -------------------------------- | ---------------------------------------------------------------- | | `scan.created` | A new pentest started | | `scan.completed` | A pentest completed successfully | | `scan.failed` | A pentest failed during execution | | `scan.cancelled` | A pentest was cancelled | | `vulnerability.created` | A new vulnerability was found | | `vulnerability.status_changed` | The status of a vulnerability changed | | `vulnerability.severity_changed` | The severity of a vulnerability changed, with an override reason | | `*` | Subscribe to all events | ## Payload format Every delivery is a `POST` with a stable JSON envelope. The `data` object is different for each event. The sections below give the payload for each event. | Field | Type | Description | | ------------ | ------------------ | ---------------------------------------------------- | | `id` | uuid | Unique delivery id. Also sent as `X-Strix-Delivery`. | | `event` | string | Webhook event type, such as `scan.completed`. | | `created_at` | ISO 8601 timestamp | Time the delivery was created. | | `data` | object | Event-specific payload. | ### scan.created A pentest was created and queued. | Field | Type | Description | | ----------------- | ------------------ | ------------------------------- | | `scan_id` | string | Scan id | | `organization_id` | string | Organization that owns the scan | | `status` | string | Current scan status | | `title` | string \| null | Scan title | | `created_at` | ISO 8601 timestamp | Scan creation time | ```json theme={null} { "id": "delivery_123", "event": "scan.created", "created_at": "2026-05-19T04:30:00.000Z", "data": { "scan_id": "scan_123", "organization_id": "org_123", "status": "pending", "title": "Production API pentest", "created_at": "2026-05-19T04:30:00.000Z" } } ``` ### scan.completed, scan.failed, scan.cancelled The status of a pentest changed. The three events have the same payload shape. The `status` field is `completed`, `failed`, or `cancelled`. | Field | Type | Description | | ----------------- | ------------------ | ------------------------------------------------ | | `scan_id` | string | Scan id | | `organization_id` | string | Organization that owns the scan | | `status` | string | New scan status | | `previous_status` | string \| null | Previous scan status | | `title` | string \| null | Scan title | | `schedule_id` | string \| null | Schedule that launched the scan, when applicable | | `updated_at` | ISO 8601 timestamp | Time the status change was observed | ```json theme={null} { "id": "delivery_123", "event": "scan.completed", "created_at": "2026-05-19T05:12:00.000Z", "data": { "scan_id": "scan_123", "organization_id": "org_123", "status": "completed", "previous_status": "running", "title": "Production API pentest", "schedule_id": "schedule_123", "updated_at": "2026-05-19T05:12:00.000Z" } } ``` ### vulnerability.created A vulnerability was created for a pentest. | Field | Type | Description | | ------------------ | ----------------------------------------- | ---------------------------------------- | | `vulnerability_id` | string | Vulnerability id | | `organization_id` | string | Organization that owns the vulnerability | | `scan_id` | string | Scan that found the vulnerability | | `title` | string | Vulnerability title | | `severity` | `critical` \| `high` \| `medium` \| `low` | Current severity | | `status` | string | Current vulnerability status | | `created_at` | ISO 8601 timestamp | Vulnerability creation time | ```json theme={null} { "id": "delivery_123", "event": "vulnerability.created", "created_at": "2026-05-19T05:08:00.000Z", "data": { "vulnerability_id": "vuln_123", "organization_id": "org_123", "scan_id": "scan_123", "title": "Unauthenticated account export", "severity": "high", "status": "open", "created_at": "2026-05-19T05:08:00.000Z" } } ``` ### vulnerability.status\_changed The status of a vulnerability changed. | Field | Type | Description | | ------------------- | -------------------------- | ---------------------------------------- | | `vulnerability_id` | string | Vulnerability id | | `organization_id` | string | Organization that owns the vulnerability | | `scan_id` | string \| null | Related scan, when present | | `pr_review_id` | string \| null | Related PR review, when present | | `status` | string | New vulnerability status | | `previous_status` | string \| null | Previous vulnerability status | | `status_changed_at` | ISO 8601 timestamp \| null | Status change time | | `status_changed_by` | string \| null | Actor that changed the status | | `updated_at` | ISO 8601 timestamp | Time the webhook event was created | ```json theme={null} { "id": "delivery_123", "event": "vulnerability.status_changed", "created_at": "2026-05-19T06:45:00.000Z", "data": { "vulnerability_id": "vuln_123", "organization_id": "org_123", "scan_id": "scan_123", "pr_review_id": null, "status": "fixed", "previous_status": "open", "status_changed_at": "2026-05-19T06:45:00.000Z", "status_changed_by": "user@example.com", "updated_at": "2026-05-19T06:45:00.000Z" } } ``` ### vulnerability.severity\_changed The severity of a vulnerability changed, with an override reason. | Field | Type | Description | | -------------------------- | ------------------------------------------------- | ---------------------------------------- | | `vulnerability_id` | string | Vulnerability id | | `organization_id` | string | Organization that owns the vulnerability | | `scan_id` | string \| null | Related scan, when present | | `pr_review_id` | string \| null | Related PR review, when present | | `severity` | `critical` \| `high` \| `medium` \| `low` | New severity | | `previous_severity` | `critical` \| `high` \| `medium` \| `low` \| null | Previous severity | | `original_severity` | `critical` \| `high` \| `medium` \| `low` \| null | Original severity before overrides | | `severity_changed_at` | ISO 8601 timestamp \| null | Severity change time | | `severity_changed_by` | string \| null | Actor that changed the severity | | `severity_override_reason` | string \| null | Reason supplied for the change | | `updated_at` | ISO 8601 timestamp | Time the webhook event was created | ```json theme={null} { "id": "delivery_123", "event": "vulnerability.severity_changed", "created_at": "2026-05-19T06:52:00.000Z", "data": { "vulnerability_id": "vuln_123", "organization_id": "org_123", "scan_id": "scan_123", "pr_review_id": null, "severity": "medium", "previous_severity": "high", "original_severity": "high", "severity_changed_at": "2026-05-19T06:52:00.000Z", "severity_changed_by": "user@example.com", "severity_override_reason": "Compensating control is deployed.", "updated_at": "2026-05-19T06:52:00.000Z" } } ``` ## Create a webhook ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/webhooks" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "url": "https://your-app.com/strix-webhook", "events": ["scan.completed", "vulnerability.created"], "is_active": true }' ``` **Required scope:** `webhooks:write` The response includes a `secret` field. Keep the secret in a safe location. Strix does not show the secret again. ## Per-business\_unit routing By default, a subscription is **org-wide**. It receives every applicable event in your organization. On Enterprise plans, you can attach a subscription to a single `business_unit`. The subscription then receives only the events for assets in that business unit. This is useful when you have multiple end-customers in one organization and each customer must receive only its own events. ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/webhooks" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "url": "https://acme.example.com/strix-webhook", "events": ["*"], "business_unit": "acme" }' ``` * For an org-wide subscription, omit `business_unit` or set it to `null`. This is the default behavior. * To receive only the events for one business unit, set `business_unit` to that value. The business units of an event come from the related assets (domains and repositories). * The `business_unit` field requires the Enterprise plan (the `rbac` feature). On other plans, requests that set this field return `403`. * To convert a scoped subscription back to org-wide, `PATCH` it with `"business_unit": null`. To set the `business_unit` of an asset, use `POST` or `PATCH` on `/v1/domains` and `/v1/repositories`. A token that is scoped to a `business_unit` can only see and manage the assets, scans, and vulnerabilities of that unit. ## Verify webhook signatures Every webhook delivery includes signature headers for verification: | Header | Description | | ------------------- | ------------------------------------------------- | | `X-Strix-Event` | The event type (for example, `scan.completed`) | | `X-Strix-Delivery` | Unique delivery ID (use it as an idempotency key) | | `X-Strix-Timestamp` | Time when the event was sent (ISO 8601) | | `X-Strix-Signature` | HMAC-SHA256 signature for payload verification | ### Signature verification (Node.js) ```javascript theme={null} import crypto from "crypto"; export function verifyStrixWebhook(rawBody, headers, secret) { const signature = headers["x-strix-signature"]; const timestamp = headers["x-strix-timestamp"]; if (!signature || !timestamp) return false; const parsedTime = Date.parse(timestamp); const ageMs = Math.abs(Date.now() - parsedTime); if (!Number.isFinite(parsedTime) || ageMs > 5 * 60 * 1000) return false; const payload = `${timestamp}.${rawBody}`; const expected = crypto .createHmac("sha256", secret) .update(payload) .digest("hex"); return crypto.timingSafeEqual( Buffer.from(expected), Buffer.from(signature) ); } ``` Always make sure that the signature is correct before you process a webhook payload. Reject requests that have a timestamp older than 5 minutes. This prevents replay attacks. ## Delivery and retries Strix sends events asynchronously, with retries and exponential backoff. A delivery can occur more than one time. When you process events, use the `X-Strix-Delivery` header as an idempotency key. ## Manage webhooks ### List webhooks ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/webhooks" \ -H "Authorization: Bearer " ``` **Required scope:** `webhooks:read` ### Update a webhook ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/webhooks/" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"events": ["*"], "is_active": true}' ``` **Required scope:** `webhooks:write` ### Rotate webhook secret ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/webhooks/" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"rotate_secret": true}' ``` The response includes the new `secret`. The old secret immediately becomes invalid. **Required scope:** `webhooks:write` ### Delete a webhook ```bash theme={null} curl -X DELETE "https://app.strix.ai/api/v1/webhooks/" \ -H "Authorization: Bearer " ``` **Required scope:** `webhooks:write` ### Inspect deliveries ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/webhooks//deliveries?limit=25" \ -H "Authorization: Bearer " ``` **Required scope:** `webhooks:read` # Introduction Source: https://docs.app.strix.ai/introduction Automate security testing with the Strix API Use the Strix API to manage pentests, vulnerabilities, schedules, and webhook automations for your organization from your own programs. ## What you can automate * **Pentests** — Start pentests, rerun or cancel pentests, and download PDF reports * **Vulnerabilities** — List and update vulnerabilities for remediation workflows * **Schedules** — Create and trigger recurring schedules for continuous testing * **Webhooks** — Subscribe to pentest and vulnerability lifecycle events ## Base URL Send all API requests to: ``` https://app.strix.ai/api/v1 ``` ## Authentication Every request must include a bearer token in the `Authorization` header: ```bash theme={null} Authorization: Bearer ``` Each token belongs to one organization. A token can only get access to the resources of that organization. To create tokens, go to **Settings > API Access** in the Strix dashboard. ## Scopes Each token has scopes that control the resources it can get access to. Give each integration only the scopes that it needs. Rotate your tokens regularly. | Scope | Description | | ----------------------- | ------------------------------------------------------------ | | `scans:read` | List pentests, read pentest detail, and download reports | | `scans:write` | Create pentests, rerun pentests, and cancel running pentests | | `vulnerabilities:read` | List vulnerabilities and read individual findings | | `vulnerabilities:write` | Update vulnerability status and notes | | `schedules:read` | List schedules and inspect schedule runs | | `schedules:write` | Create, update, delete, and trigger schedules | | `assets:read` | Read domains and repositories target inventory | | `webhooks:read` | List webhook endpoints and delivery history | | `webhooks:write` | Create, update, delete, and rotate webhook secrets | | `tokens:write` | Create and revoke API tokens | # Quickstart Source: https://docs.app.strix.ai/quickstart Make your first API call in less than one minute ## 1. Create an API token Go to **Settings > API Access** in the [Strix dashboard](https://app.strix.ai/settings/api-access). Create a new personal token with the `scans:read` scope. ## 2. List your recent pentests ```bash theme={null} curl -X GET "https://app.strix.ai/api/v1/scans?limit=5" \ -H "Authorization: Bearer " ``` The response is a JSON document that contains your most recent pentests: ```json theme={null} { "items": [ { "id": "scan_abc123", "title": "Scan of example.com", "status": "completed", "scan_type": "blackbox", "findings": { "total": 7, "critical": 1, "high": 2, "medium": 3, "low": 1 }, "created_at": "2026-04-07T10:00:00Z" } ], "meta": { "page": 1, "limit": 5, "total_items": 42, "total_pages": 9, "has_next": true, "has_prev": false } } ``` ## 3. Update a vulnerability status Create a token with the `vulnerabilities:write` scope. Then set the status of a finding to in-progress: ```bash theme={null} curl -X PATCH "https://app.strix.ai/api/v1/vulnerabilities/" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"status":"in_progress","note":"Linked to remediation ticket"}' ``` ## 4. Trigger a schedule If you have pentest schedules, you can trigger one immediately: ```bash theme={null} curl -X POST "https://app.strix.ai/api/v1/schedules//trigger" \ -H "Authorization: Bearer " ``` ## Next steps Learn about the token types and scopes Subscribe to pentest and vulnerability events