API Check Use Cases and Examples

This document outlines some full and partial use cases illustrating various methods the API check can utilize to monitor endpoints. For API Check setup instructions, see this article.

Checking Multiple API Endpoints, and Using Variables

Uptime.com can use API to verify not only that a query was successful, but the data itself using specific values we ask it to retrieve. We will use this operation to query multiple endpoints with the same variable. 

We will use 8 steps including both commands and validators to finalize our check.  


  1. GET https://httpbin.org/json
  2. Validate HTTP status code is 200
  3. Set a variable named “title” and use the first value from the response body

  4. POST the value stored in variable $title$ to HTTPbin (note we surround our variable in ‘$’)
  5. Check that the response contains the value we defined
  6. A secondary validator used for more precision
  7. POST our variable to a new URL (httpbin.org/anything)
  8. Check that the response contains the text we defined

We check three endpoints and use a number of validators that help define specific responses we are looking for. We can change these variables according to our needs. 

If we wanted to test the Uptime.com REST API, for instance, we could set our variable to be a check’s service number. Then we could query multiple check related endpoints with this service number for a specific response. 

Form Submission

This example will utilize HTTPbin to pass data as a form field. The “anything” endpoint will return whatever we send to it, so we can use a selector value to validate that the correct data was passed.  


We’ve highlighted the relevant portion of the response from HTTPbin below:


We can use a validator step to validate the data was submitted and is present in the response body:


OAuth with the API Check

This example will show how to retrieve an oAuth token for use in your API check. To achieve our end goal, we will need to POST data to a specific URL containing some parameters required for authentication. We can do all of this in a single step with a POST Command:

POST to https://myURL.com/oauth/token 

This POST request can contain Content Type, Data, and HTTP Headers if required. Here, we have chosen to designate the content-type application/x-www-form-urlencoded

The Data field will contain the client’s ID and any requisite tokens or authorization required to authenticate:

Data:  grant_type=client_credentials&client_id=client_id&client_secret=client_token

No headers are needed for this operation. 


Test this operation to be sure authentication is successful. Upon a successful test, you are ready to proceed utilizing endpoints that require user authentication. As a general rule, Uptime.com recommends your authenticated test user has minimal permissions.

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