API Check Basics

This article will cover the creation of an API Check and its purpose within the Uptime ecosystem. An API check will monitor API (such as SOAP or REST) using multiple HTTP(S) requests in intervals ranging from 3 to 60 minutes. This tutorial assumes you’ve already logged into Uptime.com.

If you are looking for API check use cases, see this document. You can find more details on API Check commands and validation steps here

Table of Contents

Adding Your First API Check


To access an API Check, click on Monitoring in the left-hand menu, then Checks, followed by Add New. Select API from the Check Type drop-down menu.

APIs are useful for many Web applications.

REST API is an architectural styling that allows access to server resources. It’s the basis for many applications that exchange data online. REST API principles are helpful when you’re trying to automate data flow, query for resources, or, in our case, verify uptime.

To apply the principles within this tutorial to your server, you would need to write your requests in a language that your server can understand.

The following use case uses httpbin.org to illustrate a basic example with common commands. You may want to review our Field Explanation support article for more detailed definitions of terms you’re likely to encounter, or find more details on API Check commands and validation steps here.

Please note: API checks do not support self-signed certificates.  

Access Tokens

Uptime.com API checks can request an access token your server can issue for multiple sessions. Access tokens identify and authorize Uptime.com to fetch or query API resources without the need to authenticate the user and password, which can present a security risk.

To collect the token, create a command to Set a Variable from response body/header depending on where the token is issued.

Use the following formats to specify a selector:

For JSON responses: JSONPath or dot format, e.g. result.tokens[0].access_token

For XML responses: XPath, e.g. /result/token[1]/@access_token

Access tokens can be used in any subsequent step (in HTTP headers or data) using the validator Selector Value from Response Matches Value. Simply enclose the variable name in dollar signs ($), as in this example:

HTTP Header: Authorization: Bearer $TOKEN$

JSON Data: {"authtoken": "$TOKEN$"}

XML Data: <authtoken>$TOKEN$</authtoken>

Find more details on API Check variables here

Failed Checks


Using the returned data, debugging our requests is much easier. Click the green Run Test button and you  never need to leave the check edit screeen to see what Uptime.com sees when it makes the request. We can check for inconsistencies in our code, or review the returned data manually for other reasons. 

We can access this data by returning to our check screen.


Uptime.com will show the specific reason a step has failed, as depicted above where the  status code is not consistent with what was requested. 

The check will retry depending on the Sensitivity value you have defined. 

If there was a problem with syntax returned, we could view the response within the test screen.



Root Cause Analysis


API checks have a root cause analysis tool to identify the specific step where the failure occurred and identify the problem. This information is included in the alert email issued to your check contacts.


The Root cause analysis screen provides detailed check results, including response time metrics for each step the check was able to complete prior to failure.

Was this article helpful?
0 out of 4 found this helpful