How Fortify integration and API users are counted

A mature Fortify deployment talks to a great deal of other software. Issue trackers pull in findings, dashboards query results, build systems submit scans, and security platforms read data through the API. Each of those integrations authenticates with an identity, and that identity shows up in the user tables alongside real developers. When an audit enumerates the user list without distinguishing humans from integrations, the machine to machine accounts inflate the seat count. Understanding how Fortify integration and API users are counted is the way to keep automation out of a figure that is meant to license people.

This article explains what integration and API identities are, why an audit tends to count them as seats, and how a buyer separates automation from users with evidence. It supports our Fortify and AppSec audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What integration and API identities do

An integration identity exists so that two systems can talk. A defect tracker uses one to create tickets from Fortify findings; a reporting tool uses one to read results; a build pipeline uses one to submit scans on behalf of many developers. None of these identities represents a person sitting at a Fortify client. They are service credentials that act for software, and often for many people at once. The seat metric licenses the human population that uses the tool, not the connective tissue that links it to the rest of the toolchain.

Why an audit counts them as seats

The user tables in the Software Security Center do not always label an account as human or machine. An audit measurement that exports the full user list and counts every row treats an API client the same as a developer. Because integrations are often highly active, generating large volumes of calls and submissions, they can even look like the busiest users in the data, which makes the overcount worse rather than better. This is the same problem we develop for pipeline credentials in CI pipeline service accounts counted as Fortify seats, applied to the wider set of integrations that touch the API.

Separating automation from users

The defensible count includes only the human population that used the tool. Integration and API identities are isolated and set aside, because they act for software rather than as individuals. The buyer does this with evidence drawn from the deployment itself:

• Identify service credentials by their configuration. Accounts provisioned for integrations, with API tokens rather than interactive logins, are machine identities, not seats.
• Trace what each identity does. An account that only creates tickets, reads results, or submits on behalf of a pipeline is connective, not a consumer, a distinction examined in Fortify Software Security Center user counting traps.
• Attribute the work back to people. Where an integration submits scans, those scans are attributed to the contributors who triggered them, using the method in reducing a Fortify finding with commit and scan evidence.

What remains after the integrations are removed is the active human population, counted under the applicable metric, whether named or concurrent, as set out in Fortify named user versus concurrent user definitions.

Anchoring to the entitlement

The corrected human count is read against the buyer's effective license position, reconstructed before any vendor measurement script runs. That reconstruction, the subject of reconciling Fortify entitlements before an audit, gives the removal of integration identities a defensible baseline to land against and prevents the buyer from accepting a count that treats its own automation as licensed seats.

A representative outcome

In a recent engagement, a Fortify finding counted a set of highly active API identities, used by a defect tracker, a reporting platform, and a build system, as developer seats, and because those identities generated more activity than most humans, they sat near the top of the usage data. By identifying each as a service credential, tracing what it actually did, and attributing any scans it submitted back to real contributors, the buyer removed the integrations from the count and rebuilt the figure around the human population. The corrected count was meaningfully lower, and the finding settled well below its opening position, consistent with the reductions we see across Fortify matters and with our E-02 case file, where a developer seat overclaim of $4.5M settled at $0.9M.

Holding the line on automation

The discipline is to refuse the equation of identity to seat. An integration is a connection between systems, and an API client is a piece of automation; neither is a person using Fortify. Each is identifiable from the deployment's own configuration and activity records, and removing them moves the finding toward the figure the entitlement supports. For the broader measurement context, see how OpenText measures Fortify usage in an audit, and for the line by line discipline, see defending a Fortify developer seat finding line by line.

For the full seat counting methodology, read the Fortify seat counting white paper.