Managing Schedulers in CloudHub 2.0 with the MuleSoft Platform API

In our previous post, How to Trigger a Scheduled Flow Using the MuleSoft Platform API, we triggered a scheduled flow on demand using the Anypoint Platform API. We authenticated with a Connected App, retrieved a deployment ID, retrieved a scheduler ID, and fired a POST request.

Now we go further. In this post, we'll manage the scheduler itself — not just trigger it. We will enable it, disable it, change its frequency, switch it to a cron expression, and restore its original configuration. We'll also cover a detail that is specific to CloudHub 2.0: every scheduler configuration change requires an application restart before it takes effect.

We will verify the result of every operation.

Before We Start

This post builds directly on Part 1. We assume the scheduler-trigger-demo app is still deployed and running. We also assume we already have a valid access token from our Connected App.

We'll use the same variables throughout:

Variable	Description
{{orgId}}	Your Anypoint organization ID
{{envId}}	Your target environment ID
{{accessToken}}	Bearer token from the Connected App
{{deploymentId}}	The deployment ID of scheduler-trigger-demo
{{flowName}}	scheduledFlow

CloudHub 2.0 restart requirement: In CloudHub 2.0, scheduler configuration changes are applied at startup. Changing a scheduler's type, frequency, or cron expression will have no effect until we restart the application. We will cover the restart API call after each configuration change.

The Operations We Will Cover

Operation	HTTP Method	Purpose
List schedulers	GET	Read current scheduler state
Disable / enable schedulers	PATCH	Toggle schedulers on or off
Update scheduler configuration	PUT	Change frequency or switch to cron
Restore default configuration	DELETE	Remove custom config, revert to app defaults
Restart the application	POST	Apply configuration changes in CH2.0

Operation 1 — List Schedulers (Read Current State)

Before we change anything, we'll read the current scheduler state. We'll use this request as our verification step at the end of every other operation too.

Request

GET https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}/deployments/{{deploymentId}}/schedulers
Authorization: Bearer {{accessToken}}

Response (example — default state)

{
    "items": [
        {
            "flowName": "scheduledFlow",
            "enabled": true,
            "type": "FixedFrequencyScheduler",
            "startDelay": "0",
            "frequency": "1",
            "timeUnit": "MINUTES"
        }
    ],
    "total": 1
}

This is our baseline. The scheduler fires every minute and is enabled. We'll run this same GET after each operation to confirm the change took effect.

Operation 2 — Disable and Enable Schedulers

This single endpoint handles both enable and disable. We pass a list of scheduler flow names and the desired enabled state. We can toggle multiple schedulers in one request.

2a — Disable the Scheduler

Request

PATCH https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}/deployments/{{deploymentId}}/schedulers
Authorization: Bearer {{accessToken}}
Content-Type: application/json

Body

[{
	"flowName": "scheduledFlow",
	"enabled": false
	}
]

A successful response returns HTTP 200 OK with the following body:

{
    "items": [
        {
            "flowName": "scheduledFlow",
            "enabled": false,
            "type": "FixedFrequencyScheduler",
            "startDelay": "0",
            "frequency": "1",
            "timeUnit": "MINUTES"
        }
    ],
    "total": 1
}

CloudHub 2.0 note: Enabling and disabling a scheduler does not require an application restart. The platform applies this change immediately.

Verify

We'll send the GET request from Operation 1. The response will show "enabled": false for scheduledFlow.

[
  {
    "id": "scheduledFlow/0",
    "flowName": "scheduledFlow",
    "type": "fixed-frequency",
    "enabled": false,
    ...
  }
]

We can also verify in Runtime Manager > Applications > scheduler-trigger-demo > Logs. After the disable takes effect, the The flow has been triggered message will stop appearing at the regular interval.

2b — Re-enable the Scheduler

We'll send the same PATCH request with "enabled": true.

Body

[
	{
	  "flowName": "{{flowName}}",
	  "enabled": false
	}
]

Verify

We'll run the GET from Operation 1 again. The response will show "enabled": true. Within one minute, the log message will reappear in the application logs.

2c — Disable Multiple Schedulers at Once

If our app has more than one scheduled flow, we'll include all of them in the schedulers array.

Body

[
    {
      "flowName": "scheduledFlow",
      "enabled": false
    },
    {
      "flowName": "anotherScheduledFlow",
      "enabled": false
    }
  ]

The response will be a 202 Accepted

Verify

We'll send the GET from Operation 1. Both flows will appear with "enabled": false in the response list.

Operation 3 — Update the Scheduler Configuration

This endpoint replaces the scheduler configuration for a specific flow. We target the flow by its flowName in the URL path.

CloudHub 2.0 restart required: This change does not take effect until we restart the application. We will cover the restart call in Operation 4.

3a — Change to a Different Fixed Frequency

We'll change the scheduler from 1 minute to 30 seconds.

Request

PUT https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}/deployments/{{deploymentId}}/schedulers/{{flowName}}
Authorization: Bearer {{accessToken}}
Content-Type: application/json

Body

{
    "enabled": true,
    "type": "FixedFrequencyScheduler",
    "startDelay": "0",
    "frequency": "30",
    "timeUnit": "SECONDS"
}

Valid values for timeUnit are MILLISECONDS, SECONDS, MINUTES, HOURS, and DAYS.

A successful response returns HTTP 200 OK.

Then restart the app (see Operation 4).

Verify

After the restart completes, we'll run the GET from Operation 1. The response will reflect the new configuration:

{
    "items": [
        {
            "flowName": "anotherScheduledFlow",
            "enabled": false,
            "type": "FixedFrequencyScheduler",
            "startDelay": "0",
            "frequency": "5",
            "timeUnit": "MINUTES"
        },
        {
            "flowName": "scheduledFlow",
            "enabled": true,
            "type": "FixedFrequencyScheduler",
            "startDelay": "0",
            "frequency": "30",
            "timeUnit": "SECONDS"
        }
    ],
    "total": 2
}

We'll also check the application logs. The The flow has been triggered message will appear every 30 seconds instead of every minute.

3b — Modify a Cron Expression

Cron expressions give us precise control over when a flow fires. We can schedule flows to run at specific times of day, on specific days of the week, or on complex recurring patterns.

MuleSoft uses a 6-field cron expression with the following structure:

Seconds  Minutes  Hours  DayOfMonth  Month  DayOfWeek

Here are practical examples:

Goal	Cron Expression
Every 5 minutes	0 0/5 * * * ?
Every day at 8:00 AM	0 0 8 * * ?
Every Monday at 6:00 AM	0 0 6 ? * MON
First day of every month at midnight	0 0 0 1 * ?
Every weekday at 9:30 AM	0 30 9 ? * MON-FRI

Note: MuleSoft's cron format does not support both DayOfMonth and DayOfWeek simultaneously. When one is specified, the other must be ?.

We'll switch our scheduler to run every day at 8:00 AM UTC.

IMPORTANT! - We can only change a cron-based schedule on flows those flows where the Scheduling Strategy is set to Cron. Sending a request to modify the cron expression to a FixedFrequency scheduler will return an error response Invalid scheduler configuration for flow

Request

PUT https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}/deployments/{{deploymentId}}/schedulers/{{flowName}}
Authorization: Bearer {{accessToken}}
Content-Type: application/json

Body

{
  "type": "CronScheduler",
  "expression": "0 0 8 * * ?",
  "timeZone": "UTC"
}

We can set timeZone to any valid IANA time zone identifier, such as America/New_York, Europe/Rome, or Asia/Tokyo. The platform will evaluate the cron expression against that time zone.

A successful response returns HTTP 200 OK.

Then restart the app (see Operation 4).

Verify

After the restart, we'll send the GET from Operation 1. The response will show the cron configuration:

[
  {
    "flowName": "scheduledFlow",
    "type": "CronScheduler",
    "enabled": true,
    "expression": "0 0 8 * * ?",
    "timeZone": "UTC"
  }
]

The frequency field disappears from the response because it only applies to the fixed-frequency type.

Operation 4 — Restart the Application

Every scheduler configuration change in CloudHub 2.0 requires a restart.

CloudHub 2.0 does not expose a single restart command. To restart an application, we send two sequential requests: one to stop it and one to start it. Both use a PATCH against the deployment, passing the target desiredStatus in the request body.

Why this matters: CloudHub 2.0 reads scheduler configuration at startup. A stop followed by a start is the only way to make a scheduler configuration change take effect on a running application.

4a — Stop the Application

Request

PATCH https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}/deployments/{{deploymentId}}
Authorization: Bearer {{accessToken}}
Content-Type: application/json

Body

{
  "application": {
    "desiredState": "STOPPED"
  }
}

A successful response returns HTTP 200 OK. The stop is asynchronous. The application will move through a STOPPING status before reaching STOPPED.

Verify

We'll send the GET from Operation 2 and poll for the deployment status:

GET https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}/deployments/{{deploymentId}}
Authorization: Bearer {{accessToken}}

We'll wait until the response shows:

{
	"status": "APPLIED",
    "application": {
        "status": "NOT_RUNNING",
        "desiredState": "STOPPED"
        ...
}

We can also confirm in Runtime Manager > Applications. The application status indicator will show Not Running. Do not send the start request until the application has fully stopped.

4b — Start the Application

Once the application status is NOT_RUNNING, we'll send the start request.

Request

PATCH https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}/deployments/{{deploymentId}}
Authorization: Bearer {{accessToken}}
Content-Type: application/json

Body

{
  "application": {
    "desiredState": "STOPPED"
  }
}

A successful response returns HTTP 200 OK.

Verify

We'll poll the same GET request until the status returns RUNNING:

{
  "status": "APPLIED",
    "application": {
        "status": "RUNNING",
        "desiredState": "STARTED"
        ...
}

Once the application is running, we'll send the GET from Operation 1 to confirm the scheduler configuration reflects the change we applied before the stop/start cycle.

Sequence Summary

Every scheduler configuration change requires us to follow this exact order:

PUT /schedulers/{{flowName}}   →   Verify: GET /schedulers
       ↓
PATCH desiredStatus: STOPPED   →   Verify: GET /deployments/{{deploymentId}} until status = STOPPED
       ↓
PATCH desiredStatus: RUNNING   →   Verify: GET /deployments/{{deploymentId}} until status = RUNNING
       ↓
GET /schedulers                →   Confirm updated configuration is active

Sending the start request before the application has fully stopped can result in a failed deployment or the scheduler picking up the old configuration. Always wait for STOPPED before sending RUNNING.

Operation 5 — Restore the Default Scheduler Configuration

If we want to remove any custom scheduler configuration and restore the original settings defined in the Mule application itself, we'll send a DELETE request targeting the flow name.

This operation removes the override stored at the platform level. It does not delete the flow or the scheduler component inside the application. The scheduler reverts to whatever configuration is defined in the app's mule-artifact.json or embedded scheduler XML.

Request

DELETE https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}/deployments/{{deploymentId}}/schedulers/{{flowName}}
Authorization: Bearer {{accessToken}}

No request body is required.

A successful response returns HTTP 200 OK.

Then restart the app (see Operation 4).

Verify

After the restart, we'll send the GET from Operation 1. The response will show the scheduler configuration as it is defined in the deployed application — in our case, the original 1-minute fixed-frequency setting:

[
	{
		"flowName": "scheduledFlow",
		"enabled": true,
		"type": "FixedFrequencyScheduler",
		"startDelay": "0",
		"frequency": "1",
		"timeUnit": "MINUTES"
	}
]

We'll also confirm in the application logs. The The flow has been triggered message will resume its original 1-minute cadence.

Complete Operation Reference

Here is a summary of every API call we used in this post.

Operation	Method	Path
List schedulers	GET	.../deployments/{{deploymentId}}/schedulers
Disable / enable schedulers	PATCH	.../deployments/{{deploymentId}}/schedulers
Update scheduler config	PUT	.../deployments/{{deploymentId}}/schedulers/{{flowName}}
Restore default config	DELETE	.../deployments/{{deploymentId}}/schedulers/{{flowName}}
Restart the application	POST	.../deployments/{{deploymentId}}/restart

All paths are relative to:

https://anypoint.mulesoft.com/amc/application-manager/api/v2/organizations/{{orgId}}/environments/{{envId}}

When to Use Each Operation

Disable the scheduler when we need to pause a flow temporarily — for example, during a maintenance window or an upstream system outage. We re-enable it with a single API call. No redeployment needed.

Update the configuration when a business requirement changes the timing of a process. We can push the new schedule through the Platform API without touching the application code or triggering a new deployment pipeline.

Switch to cron when the flow must align with a business calendar — end-of-day processing, weekly reports, or monthly batch jobs. Fixed-frequency schedulers count elapsed time. Cron expressions fire at fixed points in time regardless of when the app last started.

Restore the default when we want to discard all platform-level overrides and let the application's embedded configuration take control again. This keeps our source of truth in the codebase rather than the platform.

Restart after configuration changes because CloudHub 2.0 reads scheduler configuration at startup. This is not optional. A configuration change without a restart has no effect on the running application.