API Endpoint Monitor Settings

This topic describes the configuration settings for API endpoint monitors. These monitors make an HTTP request (GET, POST, PUT, PATCH, HEAD or DELETE) to the specified URL, and track the status (OK/error) and response time. You can customize the monitoring settings and locations to adjust the monitoring process.

API endpoint monitors are powered by SoapUI NG, which is part of the Ready! API testing suite by SmartBear.



Monitor Name

The monitor name that appears in dashboards and reports. For example, Customer Login.


On – the monitor is enabled.

Off – the monitor is disabled.


On – the monitor sends alerts. You can specify which alerts to send (availability, performance or both) in the Alerts section.

Off – the monitor does not send any alerts.

Validate API Settings

Click this button to send a test request with the specified settings and view the response. Use this to verify that the request URL, method, headers and body are valid.

Test on Demand Test on Demand

Runs a test on demand from the monitor’s primary location. Unlike Validate API Settings, test results are based on the response HTTP status, response time and the presence or absence of the specified keyword in the response.

Note: The results of tests on demand are not included in your monitor run history, do not trigger alerts and do not affect your SLA metrics.



Measurement Plan

The monitoring plan used for this monitor.


The request URL, including http:// or https:// and the query string parameters if any. For example:


Note: Multiple query string parameters with the same name are not supported (such as http://example.com/users?role=user&role=admin). This is a limitation of SoapUI, which AlertSite uses to run API monitors.

Run Interval (Minutes)

How often the monitor runs. Possible values depend on the measurement plan selected for this monitor.

Timeout (Seconds)

How long AlertSite waits for the API response before reporting a timeout error. Default value is 30 seconds.

Monitor Note

Leave a note for yourself or other users. This note will appear on the AlertSite Dashboard when you hover over the note icon. Note text can be up to 255 characters long.


Request Method

The HTTP method for the request: GET (default), POST, HEAD, PUT, DELETE or PATCH.


Custom headers for the request, such as API keys or the Authorization token.

If your API requires Basic authentication, you can specify the User ID and Password on the Advanced tab, and AlertSite will add the Authorization header to the request automatically.

Content Type

If Content Body is specified, select the content type, such as JSON or XML. This determines the Content-Type header that will be included in the request. To use a custom Content-Type, specify it in the Headers table instead.

Content Body

JSON, XML or other data to be sent in the request body. Content Body is usually needed for POST, PATCH and PUT requests. Example:

  "id": 5,
  "username": "trillian",
  "is_admin": true

POST the data as entered above

If this check box is selected, AlertSite displays a single text area for the request headers and body instead of two separate areas. The headers and body can be specified as shown below, with an empty line separating the headers and body.

Content-Type: application/json
X-API-Key: abcde12345

  "id": 5,
  "username": "trillian",
  "is_admin": true


AlertSite can search for a text string or regular expression in the API response body and report the error status if this text is not found (or found).

Note: AlertSite only searches in the response body, not the headers. To verify a header value, create a test case in SoapUI and upload the SoapUI project as a monitor to AlertSite.

Type of Match

Plain Text or Regular Expression.

Keyword or Phrase

Text to find in the response body, or a regular expression to match against the entire request body.

Notes on using regular expressions:

To learn more about how regular expressions work, see www.regular-expressions.info.

Finding This Keyword Is an Error

If selected, keyword validation succeeds if the response body does not contain the specified text or does not match the specified regular expression.

HTTP Authentication

If the request requires Basic authentication, enter the User ID and Password here.



Monitoring Mode

The monitoring mode controls if locations check your website simultaneously or sequentially, and when they send alerts. See Monitoring Modes for possible values and details.

Rotate Locations

For each monitor, you define a location pool. Rotation means the monitor uses a subset of this location pool (say, 2 out of 10 locations) on every run, cycling through the locations. If rotation is not used, the monitor checks from all of its locations every time.


Locations Per Run

If Rotate Locations is selected, you need to specify the number (subset) of locations to use for each monitor run. This value ranges from 1 to the total number of locations you selected for the monitor.

If Monitoring Mode is Round Robin or SLA (MultiPOP), you need at least 2 locations per interval.

Enable Local Retry

Used only for Usage-Based Monitoring plans. Controls the monitor behavior when it finds errors. Select this to retry the test from the same location to see if an error was just a temporary error. Clear to suppress the retry on errors.

Note: The retry consumes extra measurement credits.

Allow AlertSite QA Testing

Before releasing AlertSite updates, SmartBear runs regression tests to make sure that both existing and new functionality work correctly. Select this check box to include your monitor in SmartBear regression testing, so we can make sure your monitors will work correctly after AlertSite updates. Participation is voluntary.

TCP Traceroute on Error

If this is selected, the monitor runs a TCP traceroute to your website when it detects a network connectivity problem (status 1 or 2), and sends results to all email alert recipients. The traceroute shows the path that data packets are taking from a monitoring location to your server, and can help administrators and engineers troubleshoot problems.

HTTP Options

Report Redirects as Errors (HTTP 301/302)

By default, if the API response has HTTP status 301 or 302 (meaning a redirect), AlertSite repeats the request to the URL specified in the response header Location. Selecting this option prevents the monitor from following redirects, and response statuses 301 and 302 will be considered errors.

Report Authentication Challenges as Errors (HTTP 401/403)

If this option is selected, the monitor will raise an error if the final status code we receive from your API is HTTP 401 or 403, indicating an authentication error.

Note that if your API requires Basic authentication, you can specify the User ID and Password in the monitor settings.


Capture Level

AlertSite runs API endpoint monitors using SoapUI. This option specifies whether to store SoapUI logs from the test runs. SoapUI logs include complete requests and responses (URL, headers, body, HTTP status code) and the details of any errors that may have occurred.

Select the level of logs to store:

You can view SoapUI logs:

You can also have the SoapUI log attached to email alerts if you configure alert recipients with the Attach server response to e-mail alerts option. This does not depend on the monitor’s Capture Level.

Transaction Trace

This option enables or disables AppDynamics transaction tracing for the monitor (see AppDynamics Integration). If it is selected, AppDynamics captures transaction snapshots for HTTP requests made by the monitor. The snapshots contain server-side performance details, such as the slowest code methods and SQL queries. You can access these snapshots from the Monitor Runs dashboard.


Select one or more locations to monitor you API from. For details, see Selecting Locations for Monitoring.

Note: Private Node Server and InSite locations currently do not support API endpoint monitors. You can use Web URL monitors instead, but keep in mind that the request payload configuration is a bit different.


Here you can configure availability and performance alerts for the monitor. To receive alerts, you need to have alert recipients configured. By default, the monitor sends alerts to all configured recipients, but you can target alerts to specific recipients by selecting recipient groups for this monitor.

Recipient Groups

Select the recipient groups that will receive alerts from this monitor. The recipient groups must have been previously created in Alerts > Alert Recipients.

If the monitor is not assigned to any recipient group, it sends alerts to all the recipients configured in your AlertSite account.

Note that adding a monitor to the recipient group overrides any step-level associations for that recipient group. So if you want to add individual steps to a group, remove the monitor from that group first.

Availability Alerts

Select this check box to send alerts when the monitor detects errors like HTTP errors, timeouts, or incorrect website content. The monitor status turns red in these cases.

Alert Notes

Monitor-specific notes that can be included in email and JSON alerts (availability alerts only), up to 255 characters long. Note that to actually add these notes to alerts, you need to configure alert templates to include the $ALERT_NOTE variable.

Performance Alerts

Select this to send alerts when the monitor response time exceeds the specified value. See Performance Alerts for a description of available settings and to learn how to set up these alerts. Note that, for multi-step monitors, the response time thresholds should include the total response time for all test steps.

See Also

© 2017 SmartBear Software. All rights reserved.      Terms of Use · Privacy Policy