How Exstream API and batch jobs are counted

Most Exstream output is not produced one document at a time by a person clicking a button. It is produced by batch jobs that run on a schedule and by API calls that other systems make to generate communications on demand. That changes the counting question in a way an audit can exploit. How Exstream API and batch jobs are counted determines whether the finding reflects the communications genuinely produced or some proxy that inflates the figure, such as the number of jobs run, the number of API calls made, or the documents generated inside runs that never reached a customer. The buyer who understands the counting mechanics can keep the finding tied to genuine delivered output.

This article explains how automated production is counted, where the count overreaches, and how a buyer corrects it. It supports our Exstream and customer communications audit defense practice and links up to the complete OpenText audit defense playbook for 2026.

What a batch job and an API call actually generate

A batch job is a scheduled run that produces many communications at once, a statement cycle or a renewal mailing for example. An API call is a request from another system to generate one or a few communications immediately, often as part of a customer interaction. Both ultimately produce documents, and in almost every case the contractual unit is the document or communication produced, not the job that produced it or the call that requested it. The first defensive principle follows directly: a count tied to jobs or calls rather than to produced communications is counting the wrong thing, and the buyer reads it back to the contractual unit established in what an Exstream volume based license metric is.

Where the automated count overreaches

Automated production introduces its own inflation patterns on top of the usual volume overreaches:

• Reruns and reprocessing. A batch job that failed partway and was rerun, or a cycle reprocessed to correct an error, can be counted twice if the count sums runs rather than delivered output.
• Test and validation runs. Jobs run to validate a release or an API integration produce output that was never delivered, the non production volume scoped in Exstream non production and test volume scope.
• Multichannel expansion. An API call that requests a communication delivered to several channels can be counted per channel, the trap examined in Exstream output channel counting traps.
• Provisioned throughput. Reading the API or batch infrastructure's sized capacity as produced volume, the capacity error in Exstream transactional versus capacity metrics.

Each of these turns automation into apparent volume that the buyer never delivered.

How a buyer corrects the automated count

The correction is to count delivered communications, not the machinery that produced them. A buyer does this by reconciling job and API logs against delivery records, so that reruns collapse into the single delivered output they represent, test runs are excluded, multichannel deliveries map back to their communications, and the count reflects what genuinely reached customers over a representative period. This reconciliation is part of the discipline in reconciling Exstream entitlements before an audit, and the records that support it are assembled as set out in documenting Exstream output volume for a rebuttal.

How the four Rs apply to automated production

The method keeps the count tied to delivered output throughout. In the respond stage the firm takes the single controlled channel inside the seven day notice window, so raw job and API logs do not reach the vendor unmanaged. In the reconstruct stage it reconciles those logs against delivery records to rebuild genuine produced volume, before any vendor measurement script runs. In the rebut stage every place the count uses jobs, calls, reruns, test runs, or provisioned throughput as a proxy for delivered output is challenged at its source. In the resolve stage the settlement reflects delivered communications and the forward agreement defines the unit so automation cannot be recounted as volume in the next audit.

A representative outcome

In a recent engagement, an Exstream finding had summed batch job runs and API calls as though each were a unit of licensed output, counting reruns and validation runs alongside genuine production. The buyer reconciled the job and API logs against its delivery records, collapsed the reruns, removed the validation runs, and mapped multichannel requests back to their communications. The genuine delivered volume was far below the activity based figure. The matter settled well below its opening number, consistent with the reductions the firm sees across customer communications matters, with nothing introduced beyond what the delivery records contained.

API and batch counting in one line

How Exstream API and batch jobs are counted comes down to one rule: count communications delivered, not jobs run or calls made, and the activity based inflation falls away. Reconcile the logs against delivery and the automated count returns to genuine output. To see how that corrected count becomes a settlement, read reducing an Exstream finding with volume evidence, and to correct your own automated count you can open a case with our team.

For the first week after a notice arrives, read the OpenText seven day notice response white paper.