Salesforce Docs Portal

CloudHub API

The CloudHub management API (CloudHub API) enables you to programmatically access the functions of Anypoint Runtime Manager, such as:

  • Manage applications:

    • Create, deploy, start, stop, list, and delete an application on CloudHub.

    • Update application metadata, including the number of workers, Mule runtime engine version, and system properties.

    • Retrieve statistics for an application or worker.

    • Retrieve application transactions and events for a transaction.

    • Check for replay data, replay the flow for a transaction, and delete replay data for an application.

    • Manage static IP addresses and release unused IP addresses associated with an application.

    • Download the Mule package file for the application.

    • Update, enable, disable, or run all or some schedules.

  • Manage logs, notifications, and alerts:

    • Add, update, or retrieve log levels for an application.

    • Download the log file for an application or instance.

    • Create, update, or retrieve a notification.

    • Mark a notification as read or unread.

    • Create, update, or delete an alert triggered by an application.

    • Retrieve an alert and alert history.

  • Manage load balancers:

    • Create, update, or delete a load balancer.

    • List load balancers in an organization.

    • Test load balancer rules and return the number of the rule applied to the input.

  • Manage VPCs, VPNs, and TGWs:

    • Create, update, list, and remove a VPC.

    • Create or delete a VPN connection.

    • Add, modify, and remove multiple AWS Transit Gateway attachments to your Anypoint Platform organization.

  • Manage persistent queues:

    • Retrieve statistics for persistent queues.

    • Clear the entries from a persistent queue.

  • Retrieve additional information about:

    • Supported Mule versions

    • The current organization, including usage statistics

    • Workers, including thread dumps and worker regions

    • Users, including permissions

    • Available domain names

For an interactive reference that includes supported resources, methods, required properties, and expected responses, see the CloudHub API.

The CloudHub API manages only applications deployed to CloudHub, the cloud-based version of Runtime Manager. To manage on-premises applications using the API, see Runtime Manager REST Services.

Use the CloudHub API

Before getting started, familiarize yourself with operations for applications.

You can use any HTTP client with the CloudHub API. With Java, use the Jersey client or HttpClient with Jackson for JSON support.

To access operations in the CloudHub API, you must:

  1. Generate an authorization bearer token (AUTH_BEARER_TOKEN) to authenticate with the API.

    To get the access token, you need the Anypoint Platform username and password of a user assigned the Organization Administrators role. See Authentication in the Access Management API.

    Your username specifies the environment to access. For example, if your username is consuela and the environment is Development, your username is consuela@Development. If you don’t specify an environment, the API defaults to Production.

  2. Get the organization ID (ORG_ID).

    See the /api/me endpoint in the Access Management API.

  3. Get the environment ID (ENV_ID).

    See the /api/organizations/ORG_ID/environments endpoint in the Access Management API.

Get a List of Applications

To get a list of apps deployed to CloudHub, run the following curl command:

curl -X GET \
  --url https://anypoint.mulesoft.com/cloudhub/api/applications \
  -H 'authorization: Bearer AUTH_BEARER_TOKEN' \
  -H 'X-ANYPNT-ENV-ID: ENV_ID' \
  -H 'X-ANYPNT-ORG-ID: ORG_ID'

Data Format

Resources and methods that return or accept a type use the JSON data format. Here is an example of data received in JSON format in response to a request to get an application:

{
  "versionId": "xxxxxxxx",
  "domain": "hello",
  "fullDomain": "hello.us-e1.cloudhub.io",
  "properties": {
    "foo":"bar"
  },
  "propertiesOptions": {},
  "status": "STARTED",
  "workers": {
    "type": {
      "name": "Micro",
      "weight": 0.1,
      "cpu": "0.1 vCores",
      "memory": "500 MB memory"
    },
    "amount": 1,
    "remainingOrgWorkers": 223.7,
    "totalOrgWorkers": 1000.0
  },
  "workerStatuses": [
    {
      "id": "i-xxxxxxxx",
      "host": "xxx.xxx.xxx.xxx",
      "port": 0,
      "status": "STARTED",
      "deployedRegion": "us-east-1",
      "staticIPEnabled": false
    }
  ],
  "lastUpdateTime": 1589868960908,
  "fileName": "hello.zip",
  "muleVersion": {
    "version": "4.3.0",
    "updateId": "xxxxxxxx",
    "latestUpdateId": "xxxxxxxx",
    "endOfSupportDate": 1633737600000
  },
  ...
}

JVM Tuning Fields

The Application API (v2) accepts two optional JVM tuning fields on POST /applications and PUT /applications/{domain}, and returns them from GET /applications/{domain}: openJvmPackagesForArrow and gcMethod. Both fields require a worker replacement to take effect, so redeploy or restart the app after you change either value.

openJvmPackagesForArrow

openJvmPackagesForArrow is a nullable Boolean that defaults to false. When you set it to true, the CloudHub worker starts with these additional JVM flags:

--add-opens=java.base/java.nio=ALL-UNNAMED
-Dmule.module.tweaking.validation.skip=true

Set this field to true only for applications that require the Apache Arrow JDBC driver, such as Snowflake Arrow, DuckDB, or any Arrow-backed connector, on Java 17. Without these flags, Java 17’s stricter module system blocks Arrow’s use of sun.misc.Unsafe and off-heap NIO buffers, and the application fails at runtime with an InaccessibleObjectException.

Enabling openJvmPackagesForArrow widens the JVM’s reflective access surface, because java.base/java.nio becomes open to the unnamed module. Enable it only for apps that need Apache Arrow, not as a general default.

openJvmPackagesForArrow is a transitional setting. It’s removed after Mule runtime engine delivers Module Layer Propagation, tracked in ADR-MULE-#072.

This table shows how each value behaves:

Value in request Effect on POST (create) Effect on PUT (update)

true

Worker starts with both flags

Worker starts with both flags

false

Worker starts without the flags (default)

Worker starts without the flags

null or omitted

Treated as false

Leaves the stored value unchanged

Sample request (POST):

{
  "domain": "my-arrow-app",
  "muleVersion": { "version": "4.7.0" },
  "openJvmPackagesForArrow": true
}

Sample response (GET):

{
  "domain": "my-arrow-app",
  "openJvmPackagesForArrow": true
}

gcMethod

gcMethod is a nullable String that selects which garbage collector the CloudHub worker’s JVM uses. It defaults to null, which applies the boot-time default. Input is case-insensitive, and CloudHub persists and returns the canonical form:

Input Canonical form JVM flag applied to the worker

Serial, serial, SERIAL

Serial

-XX:+UseSerialGC

Parallel, parallel, PARALLEL

Parallel

-XX:+UseParallelGC

G1, g1

G1

-XX:+UseG1GC

null, "", or omitted

null (no override)

Boot-time default GC applies

Any other value

HTTP 400 with an allow-list error

—

Only these three canonical names match. CloudHub rejects aliases such as G1GC or ParallelOld, so use only Serial, Parallel, or G1.

Choose a collector based on the workload:

  • Serial GC minimizes the memory footprint on small workers (0.1 or 0.2 vCore).

  • Parallel GC maximizes throughput for batch and ETL-heavy apps.

  • G1 delivers lower, more predictable pause times for latency-sensitive request/response apps on 1 vCore or larger.

When gcMethod is unset, the worker uses the baseline collector baked into its CloudHub AMI’s wrapper.conf. On current CloudHub 1.0 AMIs, that baseline is Parallel GC on all Java versions (8, 11, and 17) and all worker sizes. This baseline is a CloudHub deployment choice, not a JVM ergonomics outcome, so it applies even on Java 17, where the JVM’s own default would otherwise be G1. Leaving gcMethod unset is the recommended path unless you have a specific reason to override it.

This table shows how each value behaves:

Value in request Effect on POST (create) Effect on PUT (update)

Serial, Parallel, or G1 (any case)

Stores the canonical form

Updates to the canonical form and audits the change

null or omitted

Leaves the field null (boot default applies)

Leaves the stored value unchanged

"" or whitespace only

Stores null (boot default applies)

Clears any existing override and audits the change

Any other non-empty string

HTTP 400

HTTP 400

Changing gcMethod doesn’t hot-restart running workers. The new selector applies on the next worker replacement: a redeploy, restart, or scaling event.

Sample request (POST):

{
  "domain": "my-latency-app",
  "muleVersion": { "version": "4.7.0" },
  "gcMethod": "G1"
}

Sample request (PUT), which clears the override:

{ "gcMethod": "" }

Sample response (GET):

{
  "domain": "my-latency-app",
  "gcMethod": "G1"
}

Rate Limits

The CloudHub management API enforces global usage limits, with some exceptions.

Global Rate Limits for the CloudHub Management API

The following table lists the rate limits for the CloudHub management API endpoints except those listed in Exceptions to the Global Rate Limits.

When the app reaches the rate limit, CloudHub returns a 503 status code.

Endpoints Control Plane Rate Limit Per Client IP Address Status Code

All except specified endpoints

U.S.

75 requests per second

503

EU

25 requests per second

Government Cloud

Exceptions to the Global Rate Limits

The following table lists the exceptions to the Global Rate Limits for the CloudHub Management API.

When the app reaches the rate limit, CloudHub returns the status codes shown here.

Endpoints Control Plane Rate Limit Per Client IP Address Status Code

Endpoints under /api

/notifications

U.S.

75 requests per minute

503

EU

25 requests per minute

Government Cloud

Endpoints under v2/applications/{domain}

/logs

All

10 requests per second

429

/deployments/{deploymentId}/logs

/instances/{instanceId}/logs

/instances/{instanceId}/log-file

1 request per minute

500

Status Codes and Error Handling

When you call the CloudHub API, the following status codes are returned:

Status Code Description

200

The operation was successful.

201

The resource (such as an application) was created.

The Location header contains the location of the resource.

404

The resource was not found.

409

When creating a resource (such as a server, server group, or deployment), a resource with that name already exists.

429

The operation was unsuccessful due to reaching the rate limit.

500

The operation was unsuccessful.

See the HTTP body for details.

503

The operation was unsuccessful due to a temporary condition, such as server overload or reaching a rate limit.

Retry the operation.

When errors occur, such as a 500 status code, the HTTP response contains a JSON response with an error message:

500
Content-Type: application/json
Server: Apache-Coyote/1.1
Date: Mon, 10 Aug 2015 00:12:55 GMT

{
  message : "Some error message."
}

See Also