The examples below describe several common requests including authentication, device and task creation, getting a list of platforms, and getting device information using Postman (see also how to use Postman for load testing).

To start with the Dotcom-Monitor API, the HTTP/HTTPS header must have Content-Type set to application/json.

For the API Method details, see the corresponding article from the Methods category.


For authentication, use POST URI “/login“. When you sign on via the “/login” call, a new client session begins. Sessions expire automatically after a predetermined length of inactivity. The default is one minute. If you make an API call, the inactivity timer is reset to zero.

When your session expires, the exception HTTP error code,“401 – Unauthorized,” is returned. If this happens, you must log in again.

It’s recommended to use your integration UID for logging in (Account > Integration > UID).

POST /config_api_v1/login HTTP/1.1
Content-Type: application/json


Get Platforms

To get the list of Monitoring Platforms, use GET URI “/platforms. If the request succeeds, the server responds with an HTTP status code and the list of all available platforms. It’s recommended to save the response in order to use your account details (package ID, platforms ID, device ID, etc.) in subsequent requests.

GET /config_api_v1/platforms HTTP/1.1
Content-Type: application/json

Create a Device

Use data received in the “GET Platforms” response to create a JSON request. The device parameters that are not specified in the request will be set to default.

POST /config_api_v1/devices?verb=PUT HTTP/1.1
Content-Type: application/json

"Name":"TESTDEVICE 9.23.2019"

Create a Task

Post /config_api_v1/tasks?verb=PUT HTTP/1.1
Content-Type: application/json

"DNSResolveMode":"Device Cached"

Get and Edit Device Information

To edit device information, first, send a GET request with the device ID in URI to receive the server response.

GET /config_api_v1//device/193403 HTTP/1.1
Content-Type: application/json

Next, use the response body to modify device parameters and send back the JSON request with new values.

POST /config_api_v1//device/193403 HTTP/1.1
Content-Type: application/json

    "Avoid_Simultaneous_Checks": false,
    "Alert_Silence_Min": 0,
    "False_Positive_Check": false,
    "Locations": [
    "Send_Uptime_Alert": false,
    "Status_Description": "POSTPONED",
    "Postpone": true,
    "Owner_Device_Id": 0,
    "Frequency": 10800,
    "Filter_Id": 7791,
    "Scheduler_Id": 0,
    "Notifications": {
        "E_Mail_Flag": false,
        "E_Mail_Address": null,
        "E_Mail_TimeInterval_Min": 5,
        "WL_Device_Flag": false,
        "WL_Device_Email_Address": null,
        "WL_Device_TimeInterval_Min": 15,
        "Pager_Flag": false,
        "Pager_Area_Code": null,
        "Pager_Phone": null,
        "Pager_Num_Code": null,
        "Pager_TimeInterval_Min": 15,
        "Phone_Flag": false,
        "Phone_Area_Code": null,
        "Phone_Phone": null,
        "Phone_TimeInterval_Min": 15,
        "SMS_Flag": false,
        "SMS_Phone": null,
        "SMS_TimeInterval_Min": 15,
        "Script_Flag": false,
        "Script_Batch_File_Name": null,
        "Script_TimeInterval_Min": 0,
        "SNMP_TimeInterval_Min": 0,
        "Notification_Groups": []
    "Id": 193403,
    "Number_Of_Tasks": 1,
    "WaitingForApproval": false,
    "Platform_Id": 12,
    "Package_Id": 465,
    "Name": "Under_Task"

Additional information on How to Create Devices with Dotcom-Monitor APIs is available on our Wiki.

  • Testing APIs with Postman Explained

    What is an API?

    An API stands for Application Programming Interface – an interface that allows applications to communicate. The API makes it possible for software developers to send information directly from one app to another, bypassing a user interface.

    For API testing and development, special tools that allow to send input data in a request and check if the output data is correct are widely used. Postman is one of the tools like this.

    Why Use Postman?

    Postman is an API testing and development tool that is designed to send requests from the client side to the web server and receive a response from the backend. The information received with the response is determined by the data sent along with the request. Thus, Postman is used as an API client to check client-server requests to make sure everything works on the server side as it is expected. Postman supports requests to Restful, SOAP, and GraphQL web services.

    A graphical interface makes Postman an easy-to-use tool in the API testing and development process.

    You can download Postman from

    To test Restful web services Postman uses HTTP requests to send information to an API. An HTTP request is an HTTP message that a client sends to an HTTP server. Generally, an HTTP request contains a start line, a set of HTTP headers, and a body.

    A start line of HTTP request contains HTTP method, URI of the target resource, and the version of the HTTP protocol and has the following structure:

    HTTP Method/ Target URI/ HTTP Version

    HTTP methods determine the action that must be performed on the resource. The meaning of HTTP methods is described by the protocol specification. The HTTP protocol specification does not limit the number of different methods that can be used. However, only some of the most standard methods are used to support compatibility with a wide range of applications.

    Some of the HTTP methods that can be used in API calls are:

    • GET – to get (read) data (e.g., a user list).
    • POST – to create new data.
    • PUT / PATCH – to update data.
    • DELETE – to delete data.
    • OPTIONS – to get a full description of API methods available on the service.

    The header contains metadata to allow a client to pass clarifying and service information about the HTTP request such as encoding information, authorization parameters, etc.

    Information you want to transfer over the network is passed in the body. The body is optional and can be left empty (depending on the HTTP methods and headers).

    HTTP-response is the data that comes back from the API server. Besides the data in the body, the response header contains a status HTTP code of the server response. For example, you can receive the following status codes in the response header:

    • 200 – Success;
    • 400 – Bad request;
    • 401 – Unauthorized.

    Working With Requests in Postman

    Using the Postman graphical interface there is no need for web developers to write their own code to test API features.

    Working with requests in Postman includes the following sequence of steps:

    • Adding a new HTTP request using the Postman interface.
    • Customizing the request (specifying an HTTP method, header, body, authentication parameters).
    • Executing the request.
    • Saving the request (e.g., to a folder or collection).

    Tests in Postman

    To process the response from the server one can create different tests in Postman. The test in Postman is a JavaScript code that is executed automatically after the client received a response to the request. In other words, Postman tests are applied to the result of the executed request.

    Postman offers many ready-to-use code snippets that you can add to your test. Here you can find snippets to validate the codes and content of responses, parse and save values to environment variables or global variables, check their compliance with specified values, etc. For example, you can verify that the status code of the response to the GET request is 200. Tests can be applied not only to a single request but can be moved to a collection level.

    Postman Collections

    To execute multiple requests one by one automatically a collection of requests is used in Postman. You can run Collections filled in with requests and tests with Collection Runner and use them as automated API tests. To run a collection, you can select the environment, the number of iterations in the run and a delay between requests. Moreover, Postman support logging of requests and storing variables and cookies.

    Once a collection of requests has been created, it can be exported to a file to be used in a third- party application. For example, Dotcom-Monitor supports import of Postman Collection to use in monitoring and load testing setup.

    Note that in case you need to call an API that requires authentication, the collection of requests to this API must include a POST request to the corresponding authentication service to authorize the client on the server.

    In addition to the described Postman features, you can parameterize your requests, add a breakpoint to API calls and create different environments for your requests. To learn more about working with Postman, check the Postman Learning Center website

    How Dotcom-Monitor’s Postman API Can Help You

    Using our API functionality software developers can interact with their Dotcom-Monitor monitoring and load testing data and leverage the results of Dotcom-Monitor tests in a third-party application. The integration of Dotcom-Monitor with other applications is configured through the REST API, the interface that allows software developers to create, read, and update data in our system.

    To set up integration with Dotcom-Monitor services, one needs to use Rest client to create requests to our API. In this case, it is recommended to use Postman as a Rest client to test the HTTP calls to Dotcom-Monitor API in an easy and fast way. In general, basic settings are made using a graphical interface that does not require deep knowledge of programming languages or software development experience.

    Once the integration was tested you can implement the results in a custom Rest client, use cURL or proceed using Postman.