What you can do with the Strike Public API

The Public API lets your team pull Strike data into the tools they already use: a SIEM, a ticketing system, an internal dashboard, a compliance report. Your security data lives where your team works, instead of someone opening the platform to copy it out.

What it gives you access to

• Threat emulations: status, testing configuration, the assets in scope, and the history of runs

• Assets: type, business relevance, environment, and the threat emulations each one belongs to

• Vulnerabilities: severity, status, evidence, suggested fix, and the full triage and retest history

• Projects: manual testing engagements, with their methodology, status, dates and targets

👉 If you can see it in the platform, you can read it through the API.

What it does not do

• The API is read-only: nothing can be created, changed or deleted through it

• Credentials associated with an asset are never returned, only whether the asset has them

• Each key works for a single organization, and there is no way to reach another organization's data with it

👉 Vulnerability visibility follows your organization's triage configuration. A finding you can't see in the platform never appears in an API response.

Two ways to get the data

• Ask for it. Your systems call the API when they need it, for example a nightly sync of open vulnerabilities into your ticketing tool

• Be notified. Subscribe to webhooks and Strike sends an event to your systems the moment something happens, with nothing to poll

👉 Most teams use both: webhooks to react in the moment, calls to the API to keep a complete copy in sync.

How to get started

• Create an API key from Settings → API Keys

• Hand it to whoever is building the integration, through your secrets manager

• Point them to the API reference, which lists every endpoint, field and filter available

👉 This article explains what the API is for. The API reference explains how to call it, and it's the technical companion for whoever writes the integration.