Using internal REST API's: no transaction count

When a flow service is invoked from a workflow, it does not consume transaction counts. This makes sense because the workflow remains active during the request, accumulating transaction counts accordingly. If the called flow service takes longer to execute (e.g., 6 seconds), the workflow incurs additional transaction counts, which aligns with the billing model.

We believe the same principle should apply when a flow service calls another flow service (in a different project) using its internal REST API. In this case, the called flow service should not incur transaction counts—just as it wouldn’t if invoked by a workflow.

Structuring our codebase across multiple projects is essential for maintainability and scalability. However, under the current model, using internal REST APIs results in double or even triple transaction counts, even when the total execution time remains under 3 seconds (which would otherwise fit within a single transaction count). In an on-premises environment, calling a flow service across packages is unrestricted. We are only forced to use internal REST APIs due to platform limitations, and this should not result in increased costs.

We request IBM to align the billing model for internal REST API calls with the workflow-based approach to ensure fair usage and cost efficiency.