--- schema_version: "1" id: f764c579ebd8152550998802f849817f3ddd36eacef49af8f716aab1d7884789 title: Monitoring the Endpoints of Private APIs collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/api-functional-monitoring/afm-monitoring-private-apis.md canonical_url: https://docs.mulesoft.com/api-functional-monitoring/afm-monitoring-private-apis source_site: docs.mulesoft.com content_type: documentation content_hash: 69dcc3ca19e7ccf75bd06c96eb5ece051f03b6deefe75fe7dcd31088217537d2 description: MuleSoft Documentation Site latest: true --- --- product: API Functional Monitoring --- # Monitoring the Endpoints of Private APIs > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!IMPORTANT] API Functional Monitoring now supports Mule Runtime 4.9 LTS (Java 17). You can now > upgrade your private monitoring locations to version 4.9. API Functional Monitoring (AFM) lets you monitor private APIs if you have a subscription to Anypoint Virtual Private Cloud (Anypoint VPC). Private APIs are APIs with endpoints that are accessible only within your network inside an Anypoint VPC. A private location is a Mule application that runs in an environment in CloudHub 1.0 or Cloudhub 2.0. You can run tests against APIs that are accessible only within the private location. The private location environment might have an Anypoint VPC associated with it. You can create multiple private locations in a single instance of Anypoint VPC. To test private endpoints, use the internal URLs of the applications. These are the internal/VPC IP addresses of the Mule workers, in the form of `mule-worker-internal-myapp.region.cloudhub.io`. The VPC must also have access to the applications' ports. See the [CloudHub Networking Guide](https://docs.mulesoft.com/cloudhub/cloudhub-networking-guide). > [!NOTE] You can also test public APIs using private locations. Public APIs are APIs with endpoints > that are exposed to the internet. ## Association of Private Locations with Schedules When you use private locations, you can run as many workers as your allotment of vCores allows. By default, each worker consumes 0.2 vCores. Therefore, MuleSoft does not limit the number of schedules that you can create for tests that are run from private locations. Also, you can run tests from private locations with intervals of five minutes. ## Creation of Private Locations Before you can run tests of private APIs from a private location, you must create a private location, which involves specifying a name and an environment for the worker to run in. The environment must be associated with an instance of Anypoint VPC and must be the same environment that an API to be tested is deployed in. For example, you might create a private location that you name `myLocation` and set it to run in environment `myEnvironment`. When you choose to run a test in `myLocation`, AFM allocates a worker in `myEnvironment` in Anypoint Virtual Private Cloud. > [!IMPORTANT] In early versions of private locations, for tests to run, you had to allow incoming > HTTP traffic into the private location’s environment. If you > [update your private location](#update-private-locations), you no longer need to allow incoming > HTTP traffic. ## Possible Test Configurations The following diagram depicts the types of relationships that monitors of private APIs can have with their schedules, public locations, APIs, and environments. Each type of relationship is indicated with a unique line style. ![afm private locations](/mulesoft/current/en-us/api-functional-monitoring/_images/afm-private-locations.png) 1. Monitor 1’s relationships (indicated with solid black arrows): single schedule, single location, single environment Monitor 1 runs on a single schedule, Schedule A. The schedule is associated with Private Location 1. The monitor is written to test one or more endpoints in Private API 1 and in Private API 2, although it could also test endpoints in more private APIs. The private location and APIs are in a single environment, environment A. 2. Monitor 2’s relationships (indicated with dashed green arrows): multiple schedules, single location, single environment Monitor 2 runs on two separate schedules, Schedule B and Schedule C, and each is associated with the same private location, Private Location 1. The private location is shared with the schedule that runs Monitor 1. Monitor 2 is written to test one or more endpoints in private API 3 and in private API 4, although it could also test endpoints in more private APIs. The private locations and APIs are in a single environment, environment A. 3. Monitor 3’s relationships (indicated with dashed-and-dotted light blue arrows): multiple schedules, multiple locations, single environment Monitor 3 runs on two separate schedules, Schedule D and Schedule E, and each is associated with a different private location, Private Location 2 and Private Location 3. Monitor 3 is written to test one or more endpoints in API 5 and in API 6, although it could also test endpoints in more private APIs. The private locations and APIs are in a single environment, environment A. 4. Monitor 4’s relationships (indicated with dotted orange arrows): multiple schedules, multiple environments Monitor 4 runs on two separate schedules, Schedule F and Schedule G, and each is associated with a different private location. Private Location 4 and Private API 7 are in Environment A and Private Location 5 and Private API 8 are in Environment B. One environment could be a test environment, and the other environment could be a production environment, where Private API 7 and Private API 8 are copies of the same API. Monitor 4 is written to test one or more endpoints in Private API 7 and the same endpoints in Private API 8, although it could also test endpoints in more private APIs. 5. Monitor 5’s relationships (indicated with solid violet arrows): tests private and public APIs Monitor 5 runs on one schedule, Schedule H, although it could run on multiple schedules. The schedule is associated with a private location, Private Location 5. Monitor 5 is written to test one or more endpoints in Private API 9 and in Public API 10. Private Location 5 and Private API 9 are in Environment B, and Public API 10 is on the web. ## Length of Time Before Tests Time Out When tests are run by private locations in an instance of Anypoint VPC, the workers do not share resources with other MuleSoft customers. Therefore, AFM allows tests to wait for a default of thirty minutes for a response from an endpoint. You can increase this time in Anypoint Runtime Manager. To do so, follow these steps: 1. Go to Anypoint Runtime Manager. 2. Open the settings for the private location for which you want to increase the timeout. 3. In the **executionTimeout** field, specify a longer timeout in milliseconds. ## Update Private Locations As updates become available, you are notified in the **Locations** modal dialog. Follow the prompts to apply the update to all private locations. ### Mule Runtime Compatibility Private locations run on a Mule Runtime version that you manage. To maintain security and support, ensure your private locations run on a supported Long-Term Support (LTS) version:
Runtime VersionStatusAction Required

Mule 4.9 LTS (Java 17)

Supported

No action required

Mule 4.6 LTS

Supported

Plan upgrade to 4.9 before end of support

Mule 4.4 LTS

End of Life — no longer supported

Upgrade to 4.6 or 4.9 immediately

If your private locations run on Mule Runtime 4.4, upgrade to 4.6 or 4.9 as soon as possible. Running monitors on an EOL runtime poses security risks and is not supported. After upgrading, validate your private location’s compatibility within your VPC and security configuration. See [Creating Private Locations](https://docs.mulesoft.com/api-functional-monitoring/afm-create-private-location). ## See Also - [Scheduling Testing and Monitoring](https://docs.mulesoft.com/api-functional-monitoring/bat-schedule-test-task)