How Documentum API and integration users are counted

When another system reads from or writes to a Documentum repository through an API, the question of who counts as a user becomes the question that decides the finding. Treat every downstream person who touches an integrating application as a Documentum user, and the count explodes. Count the integration honestly, and it shrinks back to what was actually licensed.

Modern Documentum estates rarely stand alone. A repository feeds a portal, a line of business application pulls documents through an interface, a workflow engine writes content back, and a reporting tool reads metadata on a schedule. All of this happens through application programming interfaces and integration accounts rather than through people sitting at a Documentum client. On an audit, that indirect access is one of the most contested areas in the entire estate, because the way it is counted can multiply a modest licensed user base into a finding many times its size. Since the OpenText EULA places compliance on the licensee, the buyer carries the burden of showing how integration access really works.

Why indirect access is the pressure point

The tension is simple to state. A direct user is a person who logs into Documentum and works with content. An indirect user reaches Documentum content through another application that connects on their behalf, often through a single integration account. The vendor may argue that every person who benefits from the integration is a Documentum user and should be counted. The buyer's position is that the licensing has to follow the access that actually occurs, and that a single integration account is a single point of access, not a proxy for an unbounded downstream population. Where this line falls determines whether the count is a few accounts or thousands of end users.

This is the same indirect access problem that runs across the whole vendor estate, and it sits at the heart of how a finding is assembled. The Documentum specific version turns on how the API and integration accounts are defined and counted, and on whether the audit respects the difference between the system that connects and the people who happen to be downstream of it.

Where API and integration counting overreaches

Integration accounts counted as human seats

An integration runs under a service or system account that exists to let two systems communicate. It is not a person and consumes no human seat. Counting it as a named user is the same error examined in service and dormant accounts counted as Documentum consumers and in can OpenText count service accounts as Documentum users.

Downstream end users counted as direct consumers

The larger overreach is counting every person who uses an integrating application as a Documentum user. Those people never touch Documentum directly; they use another system that happens to retrieve content. The count should reflect the integration, not the downstream headcount, and the definition of a consumer is central, as set out in Documentum read only users and the consumer definition.

Extended ECM integrations counted as platform use

Where Extended ECM surfaces content inside a lead application, the access is by design an integration. Counting it as direct Documentum platform use blurs two products, the distinction we draw in Extended ECM versus Documentum licensing differences.

Defending integration counting under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. In that window we take control of the channel and ensure the integration architecture is documented as the measurement runs, so integration accounts are not silently reclassified as human users.

Reconstruct. We build the effective license position independently. We map every integration into and out of the repository, identify the accounts each uses, establish how access actually occurs, and distinguish the systems that connect from the people who are downstream. The reconstructed position counts integration access on its true basis rather than as a proxy for an end user population.

Rebut. We challenge the finding line by line. Integration accounts are shown to be non human. Downstream end users are shown to access through another application rather than Documentum directly. Each correction rests on the integration design and the access evidence, not on assertion.

Resolve. We settle on the corrected position and, where it serves you, convert forward into an OpenPass agreement that defines how indirect and integration access is licensed, so the next audit cannot rebuild the count from the same ambiguity.

An anonymised outcome

The financial reason this matters is the remedy that sits behind any inflated count. 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 of the audit, so an integration miscounted as thousands of users produces a finding far larger than the genuine exposure. In our anonymised insurance engagement, case file E-01, a Documentum centred ECM finding fell from $7.2M to $1.6M, a 78 percent reduction, achieved in part by holding integration access to the accounts that actually connected and refusing to let a single interface stand in for an entire downstream population.

Count the access, not the audience

The lasting lesson is that integration counting has to follow the access that genuinely occurs. A repository that is read by one reporting account on a nightly schedule is being accessed once, by one account, regardless of how many people eventually read the report. The audit's instinct is to count the audience; the buyer's defense is to document the access. The two diverge sharply wherever an integration sits between Documentum and the people who benefit from it, and that divergence is where the largest reductions in an indirect access dispute are found.

For a buyer, the practical step is to maintain a clear map of every integration touching the repository, the accounts it uses, and the access pattern it follows, so that a finding can be answered with the architecture rather than the headcount. Where that map is incomplete, it can be reconstructed from connection logs and integration configurations. To see how this fits the wider defense, read our ECM and Documentum audit defense track, and if a finding has counted your integrations as end users, open a case.

Where to go next

For the full method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026. To work through the seat count this connects to, read defending a Documentum seat overclaim line by line.