Salesforce Docs Portal

Usage-Based Pricing: Usage and Rates

Anypoint Platform captures usage metrics across products, but not all metrics are billable or reflected in usage reports.

Usage Type Description

This table defines usage metrics by product and explains how each metric is calculated for reporting.

Product Metric Description Usage Details

Mule Runtime

Mule flow: Flow within a deployed and running Mule app that contains a Mule event source or route APIKit request

Flows are aggregated using a Max Concurrent model. The usage for a month is the highest number of flows that exist in a single given hour during a month.

Mule message: Container of the core information processed by the runtime

A Mule message counts as a single unit when an event source triggers it. Messages are aggregated using a total of all messages sent during a month.

Data throughput: Total amount of data transferred in and out of the infrastructure that runs Mule where the Mule app is deployed

Data throughput counts when the deployed application transfers data to execute its business logic, including but not limited to internal operational network traffic for monitoring, logs, and health checks. Data throughput is aggregated as a sum of all bytes during a month.

API Manager

API instances: API instances in production, preproduction, and unclassified APIs (not associated with an environment) that are managed by API Manager after they are created using add, promote, or import options.

API instances remain under management until they are deleted. Instances of API Manager are aggregated using a Max Concurrent model with three separate metrics for production, preproduction, and unclassified (APIs that aren’t associated with an environment).

Data for API Manager is available starting in October 2024.

API Governance

API under Governance: APIs identified by the selection criteria of at least one of the governance profiles

If an API is governed, all versions of that API are considered one governed API. Instances of API Governance are aggregated using a Max Concurrent model. The usage for a month is the highest number of APIs governed in a single given hour during a month.

Omni Gateway

Omni Gateway API call: Any access request received by Omni Gateway regardless of whether the response to the request is successful

Omni Gateway requests are aggregated as a total of all requests during a month.

Model Proxy

Prompt tokens: Number of tokens a Model Proxy in the prompts a Model Proxy sends to a specific LLM Model

These tokens are the sum of all prompt tokens a specific Model Proxy sends to a specific LLM Model during a month. A prompt sent to a Model Proxy are considered an Omni Gateway API call and count towards the Omni Gateway API call metric.

Completion tokens: Number of tokens in the responses that a Model Proxy receives from a specific LLM Model

These tokens are the sum of all response tokens a specific Model Proxy receives from a specific LLM Model during a month.

Total tokens: Total number of tokens used in interactions between a Model Proxy and a specific LLM Model

Some LLM Providers, such as Gemini, use thinking tokens. Total tokens are the sum of prompt tokens, completion tokens, and thinking tokens if applicable.

Anypoint MQ

Anypoint MQ API request: A request made to retrieve one or more messages from the Anypoint MQ APIs

Anypoint MQ uses API requests to calculate billing. Anypoint MQ API requests are calculated in the aggregate across all environments (including production, pre-production, sandbox, and design). Anypoint MQ API requests are available via API and aggregated on usage reports.

Object Store

Object Store API request: A request made to retrieve one or more messages from the Object Store APIs as further defined in the Object Store documentation

Each Object Store API request includes up to 100 KB of data. Object Store API requests over 100 KB count as multiple requests with no fractional units. Object Store API requests are available via API and aggregated on usage reports.

DataGraph

DataGraph orchestration: An API request made by Anypoint DataGraph to the source APIs to get data for the GraphQL API request made to Anypoint DataGraph

Orchestrations are not currently aggregated on usage reports.

Anypoint MQ Usage

Anypoint MQ usage reports show this information in tables and cards:

Business Group

Business group that owns the resources where the app with the queue is deployed

Environment

Environment within the business group where the app with the queue is deployed

Region id

Region where the app with the queue is deployed

Object type

Queue or message exchange

Object name

Name of the queue or message exchange

Message units

Number of encoded characters in a message, used to determine the size of message data in the response for rate limiting (not billing)

Messages bytes

Size of the message data in the response, based on message units

API requests

Number of API calls via the connector or API, used to calculate monthly quota for billing

Messages received

Number of messages received

Total Message units

Sum of message units across all queues in the organization

Total Messages bytes

Sum of message data across all queues in the organization

Total API requests

Sum of API calls across all queues in the organization

Total Messages received

Sum of messages received across all queues in the organization

Sideloaded apps for hybrid standalone deployments are shown with the ⓘ icon in usage reports. Redeployments of sideloaded apps result in multiple records appearing in usage reports.

API Experience Hub Usage

API Experience Hub usage reports show this information in tables and cards:

Salesforce Organization ID

OrgID for the Salesforce organization where the API is deployed

Salesforce Portal Name

Name of the Salesforce portal where the API is deployed

# of Approved Request Access

Sum of approved access requests for the API

Total # of Approved Request Access

Sum of approved access requests across all Salesforce organizations

API Governance Usage

API Governance usage reports show this information in tables and cards:

Business Group

Business group that contains governed APIs

# of APIs Governed

Sum of APIs governed in the specified business group

Maximum Number of Governed APIs

Highest number of APIs governed in a single given hour during a month

API Manager Usage

Data for API Manager is available starting in October 2024.

API Manager usage reports show this information in tables and cards:

Business Group

Business group where the API is managed

Environment

Environment type where the API is managed

Runtime

Runtime type for the API

# of APIs Managed

Sum of APIs managed in the specified business group, environment, and runtime

Maximum Number of Managed APIs

API instances in production, preproduction, and unclassified APIs (not associated with an environment)

Omni Gateway Usage

Omni Gateway usage reports show this information in tables and cards:

Business Group

Business group in which the Omni Gateway is registered.

Gateway Type

Gateway type of the Omni Gateway registered.

Data for this metric is available starting in March 2025.

Environment

Environment in which the Omni Gateway is registered.

Registration

Name of the registered Omni Gateway.

Data Egress (GB)

Total amount of outbound data in gigabytes (GB) transmitted by the Omni Gateway egress to upstream services.

Data for this metric is available starting in March 2025.

# of API Calls

Sum of API calls made by APIs that are deployed within the Omni Gateway.

Total # of API Calls

Sum of API calls across all registered Omni Gateways in the organization.

Model Proxy Usage

Model Proxy usage reports show this information in tables and cards:

Model Proxy

Name of the Model Proxy

Business Group

Business group where the Model Proxy is deployed

Client app

The client application or integration that sent requests to the Model Proxy

Provider

The external LLM provider used by the proxy

Model

The specific LLM models used by the proxy

Prompt tokens

The sum of tokens in prompts the Model Proxy sends to the model in the given time period

Completion tokens

The sum of tokens in responses the Model Proxy receives from the model in the given time period

Total tokens

Total tokens used in interactions between the Model Proxy and the model in the given time period. This includes prompt tokens, completion tokens, and any provider-specific thinking tokens when applicable.

Intelligent Document Processing (IDP)

IDP usage reports show this information in tables and cards:

Business Group

Business group the document is processed in

Action ID

ID associated with the processed action

Action Version

Version associated with the processed action

Execution Type

Execution types associated with the processed action

Processed Pages

Total pages processed

Mule Runtime Usage

MuleSoft captures usage data for Mule flows, Mule messages, and data throughput, but not all of this data is aggregated in usage reports.

To track Mule message usage, the runtime report counts the number of times a Mule event source triggers a Mule message. You can view the number of these messages in a given day or month by business group, environment, and application.

To calculate usage, MuleSoft meters and aggregates the number of messages daily and monthly. After a message is triggered, the report doesn’t track changes to the message because the message is processed within the application’s flows.

Data throughput is the total network I/O bytes produced by the infrastructure of the Mule runtime engine running the Mule application.

To calculate usage, MuleSoft tracks usage and aggregates the total daily and monthly GBs.

For some customers in the US control plane, MuleSoft offers a pricing and packaging model for Anypoint Platform that allots a number of Mule flows, Mule messages, and data throughput (measured as network I/O bytes). Not all types of Mule flows and messages count toward the allotments in a package.

Mule Runtime Usage Tables

The usage information shown in the usage report tables changes depending on your view.

Usage by Business Group

Select the Usage by Business Group tab to view:

Field Description

Business Group

Business group that owns the resources. For Runtime Fabric, it’s the business group used when creating the Runtime Fabric instance.

Environment Type

Environment the resources are associated with.

For Runtime Fabric, it’s the environment the Runtime Fabric instance is associated with. If any production environment is associated with a Runtime Fabric instance, it is considered a production instance. Cluster capacity is not split within a Runtime Fabric instance between preproduction (sandbox) and production environments.

Cluster

Name of the cluster or Runtime Fabric instance containing the applications, workers, and nodes.

Cluster Capacity (Millicores)

Allocatable CPU capacity of each node within the Runtime Fabric instance.

vCore Peak

Highest hourly vCore consumption for applications in the selected business group and time period.

Usage by Application

Select the Usage by Application tab to view:

Field Description

Application

Name of the Mule application

Business Group

Business group that owns the resources. For Runtime Fabric, it’s the business group used when creating the Runtime Fabric instance.

Deployment Type

Runtime plane the Mule app is deployed to: CloudHub (abbreviated as CH), CloudHub 2.0 (abbreviated as CH2), or Runtime Fabric (abbreviated as RTF)

Environment Type

Preproduction (sandbox) or production environment the Mule app is deployed to.

Cluster

The Runtime Fabric instance that contains the nodes and applications

CPU Limit (Millicores)

Maximum amount of CPU allocated by the user that the application can burst to within the shared cluster or Runtime Fabric instance

CPU Reserve (Millicores)

Amount of CPU allocated by the user to reserve for applications within the Runtime Fabric cluster or instance

HPA Status

Indicates whether Horizontal Pod Autoscaling (HPA) is enabled for the application. Displays Enabled or N/A.

vCore Peak

Highest hourly vCore consumption for the application within the selected time period.

vCore Min

Guaranteed base vCore allocation for the application, based on the minimum replica configuration. For CloudHub (CH1) applications, vCore Min equals vCore Peak.

Mule Flows

Total number of flows in the Mule app, calculated by multiplying flows by the number of workers (CH1) or replicas (CH2 and RTF).

Mule Messages

Total number of inbound and outbound Mule messages in the Mule app

Data Throughput (GB)

Total amount of inbound and outbound data in gigabytes (GB) transmitted by the Mule app

CloudHub vCore Usage

For vCore-specific usage interpretation, including CloudHub vCore peak rollups, see vCore Pricing Usage and Rates.

Mule Runtime Usage Cards

MuleSoft usage reports cards include:

Maximum Mule Flows

A Mule flow is a sequence of logical operations configured within the XML <flow/> element of a Mule application. The runtime report tracks the Mule flows within a deployed and running Mule application that contains a Mule event source or APIkit route requests.

Mule apps in production environments typically use multiple Mule flows and subflows to divide the app into functional modules or for error-handling purposes. For example, one Mule flow might receive a record and transform data into a given format that another flow processes.

To calculate usage, MuleSoft tracks the number of Mule flows for all business groups, environments, and applications. The maximum number of Mule flows within a day or month is identified based on the peak-hour usage across the day or month. For the detailed breakdown, MuleSoft shows the peak hour usage per business group, environment, and application.

In a usage report, flow counts are calculated by multiplying the number of flows in an app by the number of workers (CloudHub) or replicas (CloudHub 2.0 and Runtime Fabric).

Mule Flow Scenarios That Count Toward Your Anypoint Platform Package Allotment

These Mule flows count toward your allotment:

Mule flows are charged only when the application containing the Mule flow is deployed and running.

Mule Flow with an Event Source

This Mule flow contains an event source as the first element. In this case, the listener counts towards your allotment.

<flow name="test-flow" >
        <http:listener config-ref="cocheras-puerto-madero-api-httpListenerConfig" path="/daily-report"/>
         <logger level="INFO" message="#[output json --- attributes.queryParams]" />
</flow>

Examples of Event Sources

Connector Source

aggregators

aggregator-listener

amqp

listener

apikit-odata

request-entity-collection-listener

request-entity-listener

as2-mule4

as2-listener

as2-mdn-listener

non-repudiation-listener

azure-service-bus-messaging

message-listener

core

scheduler

db

listener

email

listener-imap

listener-pop3

file

listener

ftp

listener

ftps

listener

google-sheets

new-row-listener

new-spreadsheet-listener

updated-row-listener

http

listener

ibm-mq

listener

jms

listener

kafka

batch-message-listener

message-listener

mllp

mllp-listener

netsuite

deleted-object-listener

modified-object-listener

modified-record-listener

new-record-listener

pubsub

message-listener

salesforce

deleted-object-listener

modified-object-listener

new-object-listener

replay-channel-listener

replay-topic-listener

subscribe-channel-listener

subscribe-topic-listener

sap

document-listener

function-listener

servicebus

listener

sftp

listener

sockets

listener

solace

queue-listener

topic-listener

sqs

receive-messages

receivemessages

stripe

citizen-on-new-charge-listener

on-new-charge-listener

on-new-event-listener

vm

listener

websocket

inbound-listener

outbound-listener

Mule Flows Generated by APIkit and Used for Routing APIkit Requests

APIkit is a tool that simplifies API implementation by automatically generating a minimal set of Mule flows based on the API specification. Each APIkit router endpoint counts as a distinct Mule flow. These Mule flows don’t have an event source and are used to HTTP requests for a particular API method and path.

This flow routes APIkit requests and handles the GET request in the /reservation path:

<flow name="get:\reservation:cocheras-puerto-madero-api-config">
        <logger level="INFO" message="#[output json --- attributes.queryParams]" />
</flow>

Mule Flows That Don’t Count Against Your Anypoint Platform Package Allotment

Mule flows that don’t have an event source and aren’t used for routing APIkit requests aren’t charged against your Anypoint Platform package allotment. These Mule flows are primarily used to modularize code.

For example:

2.a - Flow with only a logger component
<flow name="just-logging">
        <logger level="INFO" message="#[output json --- attributes.queryParams]" />
</flow>

Total Mule Messages

A Mule message is the data (the payload and its attributes) that passes through one or more Mule flows in an application. A Mule message is part of a Mule event, which is generated when the event source within a Mule flow is triggered. For example, a Mule event that consists of a Mule message is created when an HTTP Listener receives a request or each time the Scheduler component triggers an execution of the Mule flow.

Mule message processors in a Mule flow (such as core components, file read operations, or the HTTP request operations) can then retrieve, set, and process Mule message data that resides in the Mule event according to their configurations.

A Mule message is immutable, so every change to a Mule message results in the creation of a new instance. Each processor in a flow that receives a Mule message returns a new Mule message that consists of a message payload (the body of the message) and message attributes (metadata associated with the message).

Mule Message Scenarios That Count Toward Your Anypoint Platform Package Allotment

When an event source within a flow of a Mule application is triggered, the event source such as HTTP Listener or Scheduler, generates a Mule event that encapsulates a Mule message. The Mule message generated by the event source counts toward your Anypoint Platform package allotment. Any new instances of that message created during the processing of the original message as it moves through other processors in connected Mule flows, don’t count toward your Anypoint Platform package allotment.

Total Data Throughput

Data throughput is all of the network I/O bytes produced by the infrastructure for the Mule runtime server that runs a Mule application. This includes the data that the application produces to execute its business logic, as well as internal operational network traffic such as logs, health checks, and monitoring traffic. For example, data throughput includes inserting a record into a database and the network traffic associated with the app infrastructure, such as log forwarding, control plane connection, and monitoring metrics transfer.

Object Store Usage

Object Store v2 usage reports show this information in tables and cards:

Business Group

Business group that owns the resources where the app with the object store is deployed

Environment

Environment within the business group where the app with the object store is deployed

Region id

Region where the app with the object store is deployed

Store

Name of the object store associated with the API requests

Effective API requests

API requests along with the payload size and number of keys returned, used to calculate units against the quota

Total Effective API requests

Sum of effective API requests that return a 2xx (success) response across all object stores in the organization

Runtime Fabric Usage Metrics

The usage dashboard for Runtime Fabric lets you track, monitor, and govern core usage in hybrid environments and provides detailed metrics and analysis for Runtime Fabric instances and application deployments.

You can see your cluster capacity metrics refined by business group. To see CPU limit aggregates at the business group level, export the usage report as a CSV. The CPU limit is shown at the application level on the usage dashboard, along with the associated business groups, which helps you identify which applications use the most CPU, so you can adjust your application configurations if needed.

The dashboard helps you understand your usage and associated pricing by letting you compare cores and flows consumed by each application side-by-side. You can visualize core and flows consumed by each application alongside each other. Export the usage report to a CSV file to visualize cores and flows consumed by each app and drill down per environment ID and business group.

If you’re using the cluster capacity metric for billing, this translation from core usage to flow usage enables you to make the necessary changes to applications so you can transition to usage-based pricing iteratively, which gives you a more flexible pricing model that scales with your integration needs and isn’t tied to your infrastructure.

Mule Version Requirements for Flow Metrics

Alongside the cluster capacity and CPU limit, you can also view other usage metrics (such as flow, messages, and data throughput). Ensure that the Mule applications are using the compliant Supported Mule Runtime Versions.

Runtime Fabric Agent Version and Configuration Requirements

If you are using the cluster capacity metric for tracking, additional configuration requirements apply. These requirements don’t apply for accurate tracking of the CPU limit metric.

  • The Runtime Fabric agent must be version 2.7.0 or later.

    For more information, see Upgrading Runtime Fabric.

  • If you are using a Helm-based Runtime Fabric installation, ensure that the NODE_WATCHER parameter is enabled.

    For more information about enabling NODE_WATCHER, see Optional Parameters.

These configurations only apply to the Runtime Fabric agent and have no impact on applications. You don’t need to take any action on applications (redeployment or restarts) for tracking the cluster capacity and CPU limit metrics.

Runtime Fabric Compliance Tracking With Usage Metrics

You must adjust your clusters and application configurations for accurate usage-metric measurement. You can still use the CPU limit metric or cluster capacity metric at the root organization level for contract governance depending on your use case.

These recommendations can help you accurately measure metrics:

CPU Limit Cluster Capacity

  • Each application requires variable CPU allocation depending on its workload requirements. Use Anypoint Monitoring to analyze the CPU usage of your application during development to identify the right CPU limit and CPU reserve configurations.

  • Runtime Manager sets the CPU limit configuration to the available cluster capacity of the underlying Runtime Fabric instance by default, which can result in a higher CPU limit usage reported for applications if the CPU limit configuration isn’t explicitly modified during deployment. For an accurate CPU limit metric, ensure that the application’s CPU limit configurations are updated with the appropriate values based on the app’s performance.

  • You can install Runtime Fabric instances in a shared Kubernetes cluster, with both namespace isolation and node isolation for applications and Runtime Fabric core service workloads. These isolations aren’t reflected by the cluster capacity metric captured from the Kubelet server. To use this metric for compliance, use a dedicated cluster for Runtime Fabric instances for accurate measurements.

  • If a cluster is reconfigured with hyper-threading, virtualization of compute cores, or has system nodes for advanced cluster management, MuleSoft can’t account for the usage impact of these configurations on the cluster capacity metric. If you must have these configurations and use the cluster-capacity metric, contact your account team for accurate compliance audits.

For more information, see MuleSoft License Compliance.

Maximum CPU Limit in Production

You can drill down and track CPU limit based usage per application ID and group them using this metadata:

  • Runtime Fabric cluster name

    Tracks whether the underlying cluster has enough capacity to scale.

  • Business group

    Shows usage per business group.

  • Root organization

    Monitor core usage to stay under the total entitlement.

    The cluster-capacity metric is available only at the root organization level.

The maximum CPU limit in production is the maximum amount of CPU an app can use when deployed and running in the production runtime plane. The CPU amount is shared on the worker node. Each member of a set of workers for the same app can have a different value for the CPU limit. Autoscale policies, if implemented, can execute every 30 minutes, which can impact the worker or replica count and CPU limit of an app deployment.

Data is captured every hour but the max metric is tracked on a daily and monthly basis as shown in this example.

Example

Here is an example with two apps:

App1 has a CPU limit of one each and a worker count range of 1 - 3.

App2 has a CPU limit of one each and a worker count range of 2 - 5.

Data captured at 00:00 minutes:

  • App1: sum(1,1,1) = 3

  • App2: sum(1,1,1,1,1) = 5

  • Max metric captured = 8 CPU limit aggregated

Redeployment of App1 with a CPU limit of 2 and worker range of 1 - 6 at 00:45 minutes:

  • App1: sum(1,1,1,2,2,2) = 9

  • App2: sum(1,1,1,1,1) = 5

Time 01:00 min:

  • App1: sum(2,2,2,2,2,2) = 12

  • App2: sum(1,1,1,1,1) = 5

  • Max metric captured = 17 CPU limit aggregated

  • For the root organization in a given hour (not reported on the usage dashboard):

    Max concurrent limit CPU = 17

  • For the root organization in a given day:

    Max concurrent limit CPU = 17

  • For the root organization in a given month:

    Max concurrent limit CPU = 17

App2 auto scales down to three workers after 02:00 min:

  • App1: sum(2,2,2,2,2,2) = 12

  • App2: sum(1,1,1) = 3

  • Max metric = 15 CPU limit aggregate

  • For the root organization in a given hour (not reported on the usage dashboard):

    Max concurrent limit CPU = 15

  • For the root organization in a given day:

    Max concurrent limit CPU = 17

  • For the root organization in a given month:

    Max concurrent limit CPU = 17

Maximum CPU Limit in Preproduction

The maximum CPU limit in preproduction (sandbox) is the maximum amount of CPU an app can use when deployed and running in preproduction.

You can drill down and track CPU limit-based usage per application ID and group them using metadata, including:

  • Runtime Fabric cluster name

    Tracks whether the underlying cluster has enough capacity to scale.

  • Business group

    Shows usage per business group.

  • Root organization

    Monitor core usage to stay under the total entitlement.

    The cluster capacity metric is available only at the root organization level.

Data is captured every hour, but the max metric is tracked daily and monthly as shown in this Example.

When an application is moved from a preproduction to a production environment, the CPU limit configuration for that application is accounted for in the daily max meter of both preproduction and production environments.

Maximum Cluster Capacity in Production

Your maximum cluster capacity depends on your cluster configuration.

Data is captured every hour, but the max metric is tracked daily and monthly as shown in this Example.

Note that the CPU capacity of a single node is derived from the Allocatable:cpu: field when you describe the node. The total cluster CPU capacity is the sum of all these Allocatable:cpu: values in millicores from the worker nodes. These worker nodes are those that don’t have these labels node-role.kubernetes.io/master, node-role.kubernetes.io/control-plane, node-role.kubernetes.io/ingress, or rtf.mulesoft.com/ingress.

See Kubernetes (K8s) Best Practices for Runtime Fabric.

Maximum Cluster Capacity in Preproduction

Your maximum cluster capacity depends on your cluster configuration.

Data is captured every hour, but the max metric is tracked daily and monthly as shown in this Example.

Note that the CPU capacity of a single node is derived from the Allocatable:cpu: field when you describe the node. The total cluster CPU capacity is the sum of all these Allocatable:cpu: values in millicores from the worker nodes. These worker nodes are those that don’t have these labels node-role.kubernetes.io/master, node-role.kubernetes.io/control-plane, node-role.kubernetes.io/ingress, or rtf.mulesoft.com/ingress.

See Kubernetes (K8s) Best Practices for Runtime Fabric.

Exclude Nodes From Runtime Fabric Cluster Capacity

For nodes not intended to run Mule apps, exclude the nodes from your Runtime Fabric cluster’s capacity report by following these steps:

  1. Apply the label rtf.mulesoft.com/non-worker to the node. This prevents further Mule apps to be scheduled on that node.

  2. Make sure that no Mule apps are currently running on the node. The node is excluded from the capacity report if no Mule apps are detected.

  3. Make sure the Runtime Fabric agent version is 2.10.0 or higher.

Use a dedicated cluster for Runtime Fabric instances for accurate measurements

See Also