How ALM API and integration users are counted

ALM API and integration users are one of the most reliably inflated lines in a functional testing audit, because every automated connection, service account, and integration hook leaves a user record that a measurement reads as a human consumer. The way to defend the count is to separate machine to machine connections from the people the license is meant to charge for, and to show that an integration account is not a seat.

Modern Application Lifecycle Management estates are heavily integrated. Test automation frameworks, continuous integration pipelines, defect synchronisation tools, and reporting systems all connect to ALM through its API, and each connection authenticates as an account. Those accounts exist so that systems can talk to one another without a person in the loop, but to a measurement script every authenticated identity looks the same. Because the EULA places compliance on the licensee, it falls to the buyer to demonstrate which accounts are integrations rather than users, and that demonstration is the heart of the defense.

How an audit counts API and integration accounts

A measurement enumerates the accounts that can authenticate against ALM and, by default, treats each as a licensable user. It does not distinguish the account a pipeline uses to push results from the account a tester uses to author cases. The script sees an identity with access, and an identity with access reads as a seat. The result is a finding that counts the plumbing of the estate as though it were headcount, and the inflation is the entire set of integration accounts that no human ever logs into.

This is the same category error that drives service account overclaims across the wider estate. An account created so that one system can reach another is not a person consuming the product, and counting it as one charges for use that does not exist. The disqualification logic is identical to the one applied to dormant and service accounts in named user findings, set out in defending an ALM named user overclaim line by line, and it rests on classifying each account by what it actually is.

What separates an integration account from a user

An integration account authenticates on behalf of a system, not a person. It is created for a pipeline, a synchronisation job, or a reporting connection, it runs on a schedule or in response to events, and no individual sits behind it. A user account, by contrast, belongs to a named person who logs in to do work. The evidence that tells the two apart is access pattern and purpose: an integration account shows automated, regular, non interactive activity, while a user account shows interactive sessions tied to a human. Pulling that evidence and presenting it cleanly is the same discipline as documenting concurrent ALM users for a rebuttal.

The classification also depends on the license model. Under a named model each integration account wrongly counted adds a seat, while under a concurrent model the question is whether the integration ever held a simultaneous session that a human did not, the distinction explained in named versus concurrent user counting in ALM audits. Either way, the integration layer has to be identified and set aside before the count means anything, which is why reconciling the account inventory early, as in reconciling ALM entitlements before an audit, is so valuable.

How we defend an integration account finding under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. We take over the single controlled channel and ensure the account inventory and the access logs are preserved together, because telling integration accounts from users depends on showing how each one actually behaves.

Reconstruct. We build the effective license position against entitlements before any vendor script runs, classifying every account as either a human user or a machine to machine integration and removing the integration layer from the licensable count.

Rebut. We challenge every line that counts an API or integration account as a seat, presenting the automated access pattern and the documented purpose for each one. The finding falls by the full set of accounts that exist only so systems can connect.

Resolve. We settle on the count that reflects genuine human use and, where it serves you, convert forward into an OpenPass agreement that records how integration accounts are treated, so the next review cannot recount the plumbing as headcount.

An anonymised outcome

The reason integration accounts are worth disqualifying is the remedy behind the finding. On noncompliance the licensee is deemed to have acquired licenses at then current list price, owes back maintenance and support, owes first year maintenance on the new licenses, and reimburses the cost OpenText incurs performing the audit, so every integration account miscounted as a seat carries several charges at once. Our anonymised case files show how far disqualifying the wrong accounts can go: an insurance ECM seat count finding was reduced from $7.2M to $1.6M, a 78 percent reduction built on removing service and dormant accounts that were never genuine consumers. An ALM finding that counts integration accounts as users responds to exactly the same evidence, because an automated connection is not a person.

Count people, not plumbing

The lasting principle is that a license meant to charge for human use should never be measured against the integration layer that lets systems talk to one another. A buyer who maintains a clean inventory of which accounts are integrations, and can show the automated access pattern behind each, holds the finding to genuine headcount. To prepare the position, read reconciling ALM entitlements before an audit and the rebuttal method in defending an ALM named user overclaim line by line, alongside how to challenge an ALM concurrent user headcount. For the full method see our ALM and LoadRunner audit defense track and our complete OpenText audit defense playbook for 2026. If an ALM finding has counted integration accounts as users, open a case.