Get a Free 30-Day Trial of Netumo (no credit card required) - Signup Now

RESTful Monitoring

A RESTful API (also known as REST API) is an application programming interface (web API or API) that conforms to the constraints of REST architectural style and allows for interaction with RESTful web services. REST stands for representational state transfer and underlyingly utilizes the HTTP/S protocol.

RESTful monitoring in Netumo is a feature specifically designed for web service and web applications that are built using such APIs. RESTful monitoring in Netumo is possible with the creation of monitors for RESTful URLs, similar to website monitoring but take different parameters.

RESTful APIs can either require authentication or allow anonymous calls. In the case of anonymous calls then the REST monitor can work on its own without any additional requirements however for REST APIs that require authorization then Netumo requires the token and also the ability to fetch such a token. Typically tokens are generated with another REST API call with a normal username and password.

How does Netumo RESTful monitoring work.

Before Netumo performs the RESTful monitor call, it will ensure that it has all of the required data, and in case of an authenticated RESTful monitor call it will require the authentication data or token.

The data/token is typically obtained via another RESTful call which would have some form of more readable form such as username and password. 

Prior doing the RESTful monitor call Netumo will trigger the REST Auth call to update the token. The REST Auth call can be done each time, i.e. before the REST monitor call or else only once in a while, and the token used for subsequent calls. In case the server returns an updated token then Netumo will use that for subsequent REST monitoring calls.

Each RESTful monitor URL consists of the following:

URLURL of the RESTful service
HeadersAdditional headers to send with the request. 

In the case of custom, authentication the string {NETUMOTOKENAUTH} will be replaced with the token fetched via the Authentication method.

BodyBody value to send in case of POST / PUT etc.
AuthenticationAuthentication method based on Authentication table below
Match Criteria (Response)
Status CodeMatch the status code
BodyMatch any substring in the body
HeadersMatch any substring in the headers



URLURL of the RESTful Authentication service
HeadersAny additional headers to send
BodyBody value to send in case of POST / PUT etc.
Authorization TypeBearer Token, Basic, Digest, or Custom
Token LocationThe location of the token – Header, or Body (JSON or XML)

Example 1 – JWT


The token is present in the Authorization header.

Example 2 – OAuth2


The token is present in JSON body

Token PropertyThe property where the token is located

Example 1 – JWT


The token is present in the Authorization header.

Example 2 – OAuth2


The token is present in JSON body

A REST Authentication property can be used by multiple RESTful monitoring however in case of situations where the token changes with each request then it is suggested to only use a REST Authentication property per RESTful monitor.

The Authentication token can be refreshed as required. It can be refreshed with each request or after a period of time. It is suggested to set to refresh after a couple of days prior your token expires.

Body Variables

There are situations where data and time need to be added to the request body being sent in RESTful requests which would not need to be static when configuring the monitor. This can be achieved by adding Netumo monitor variables. Such variables are computed exactly before the monitor is being sent.

The variable format is the following:



  • <format> is the date-time format to use. We use Microsoft .NET format specifiers using en-US culture.
  • <adjust> would be the time adjustment like +1 to add 1, or +0 for no change or -1 to subtract 1.
  • <hour|minute|second|days> would be if the time adjustment is in hours, minutes, second or days. This is specified in h, m, s or d



would translate to “10/31/2008 5:04 PM” assuming it was run on the 10/31/2008 at 4:04 PM (UTC)