{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":29391,"path":"it-operations-management/create-synthetic-monitor-for-discovered-api.md","title":"Create a synthetic monitor for a discovered API","bundle":null,"doc_type":null,"release":"australia","body":"\n# Create a synthetic monitor for a discovered API\n\nCreate a synthetic monitor to test the availability of APIs discovered through API Insights.\n\n## Before you begin\n\n-   API Insights\n-   CMDB CI Class Models. For more information, see [API extension classes](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/servicenow-platform/cmdb-ci-class-models-api.md).\n-   An existing API component \\(cmdb\\_ci\\_api\\_component\\) record in the CMDB for the API Insights to discover APIs.\n-   One or more locations must be created to host the monitor to test private endpoints or run the monitors from your environment. To create a location, see [Create synthetic monitoring locations](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-operations-management/create-synthetic-monitoring-locations.md).\n\nRole required: sn\\_sow\\_synthetics.synthetics\\_editor or sn\\_sow\\_synthetics.synthetics\\_admin\n\n## About this task\n\nWhen API Insights discovers APIs through Service Graph Connectors, you can proactively monitor their availability and performance by creating synthetic monitors. Synthetic monitors identify issues before they impact users and verify continuous monitoring of critical API endpoints.\n\nFor more information about how API discovery integrates with synthetic monitoring, see [API discovery and synthetic monitoring integration](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-operations-management/api-discovery-integration.md).\n\n## Procedure\n\n1.  Navigate to **All** > **Service Operations Workspace** and select the synthetic monitoring icon \\(\\[Omitted image \"sys-mon-icon.png\"\\] Alt text: Synthetic monitoring\\).\n\n2.  On the Overview page, create a synthetic monitor by selecting **New**.\n\n3.  In the Monitor details section, enter a name and description for the monitor.\n\n    Use a descriptive name that identifies the discovered API being monitored, such as the API name or endpoint path.\n\n4.  In the **Endpoint settings** section, configure how the monitor interacts with the discovered API.\n\n    1.  For **Endpoint type**, select **Discovered API**.\n\n    2.  In the **API** field, select the discovered API that you want to monitor.\n\n        Each option in the list identifies a discovered API by its HTTP method, path, and URL. The method is part of the selected API component and does not require separate configuration.\n\n        **Note:** The **API** field lists only API components that meet the following criteria:\n\n        -   The endpoint's operational status is **Operational**.\n        -   The URL starts with `http`.\n        -   The URL does not contain placeholder or template characters \\(for example, `/users/{id}`\\).\n        If a known API does not appear in the list, verify that it meets these criteria.\n\n        To browse the available API component records, select the info icon beside API, and then select **View API components**.\n\n    3.  Verify the service association.\n\n        If the discovered API is related to one or more application services in the CMDB, those services and their support groups are populated automatically and shown as read-only. If no service relationship exists, these fields are hidden and the monitor is created without a service association.\n\n    4.  To configure optional request details, expand **Advanced settings**.\n\n        Under **Advanced settings**, you can configure the following optional details:\n\n        -   **Query parameters**: Query parameters to append to the request URL.\n\n            **Note:** Do not include the leading question mark. For example, use `id=xyz&customer=myco` instead of `?id=xyz&customer=myco`.\n\n        -   **Credentials**: The credential to use if the discovered API requires authentication. OAuth, Basic Auth, and API keys are supported.\n        -   Select **Add headers and body** to add custom request headers and, if the API expects a message body, the request body.\n\n            **Note:** For example, enter a JSON snippet for REST APIs that require a request body.\n\n5.  In the Locations section, select one or more locations where the monitor tests run.\n\n    Select a MID Server or Agent Client Collector location, or to run this monitor's test from your ServiceNow instance, select ServiceNow hosted location.\n\n    **Note:** When running tests from your instance, only six tests can be run every minute for performance reasons.\n\n    To create a location, select **Create new location**. For more information, see [Create synthetic monitoring locations](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-operations-management/create-synthetic-monitoring-locations.md).\n\n6.  In the Assertion section, define success criteria for the API tests.\n\n    Select one or more criteria, a condition for the criteria, and a value to determine when a test passes.\n\n    **Note:** Multiple criteria use an `AND` phrase, so the test must pass all criteria to be successful.\n\n    Common assertions for discovered APIs include:\n\n    -   **Status code**: Verify the API returns the expected HTTP status code \\(for example, 200 for successful requests\\).\n    -   **Response time**: Verify the API responds within an acceptable time threshold.\n    -   **Response body**: Validate that the API returns expected data in the response body.\n7.  In the Frequency section, enter the number of minutes between each test run.\n\n    Consider the criticality of the discovered API when setting the frequency. Critical APIs may require more frequent monitoring.\n\n8.  To receive alerts when the discovered API monitor fails, configure alert settings.\n\n    -   In the Alert settings section, activate the toggle switch.\n    -   Select an alert severity for test failures.\n    -   Add tags to the alert to help with alert management and routing. For more information about using tags in alerts, see [Tag cluster alert grouping](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-operations-management/event-management/alert-clustering-tag-definitions-concept.md).\n9.  Select **Save**.\n\n\n## Result\n\nThe synthetic monitor begins testing the discovered API endpoint at the specified frequency. The Overview page displays test results, including availability, response time, and assertion status. See [Identifying system issues with synthetic monitoring](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-operations-management/identifying-system-issues.md) for more information about viewing and analyzing test results.\n\n## What to do next\n\nAfter creating the monitor, verify that tests run successfully and adjust assertions or frequency as needed based on the API's performance characteristics and business requirements.\n\n**Parent Topic:**[Configuring synthetic monitoring](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/it-operations-management/configuring-synthetic-monitoring.md)\n\n"}}