Performing a DELETE operation with the REST API

This article provides the steps to remove resource data from Autotask by making a DELETE request to the REST API.

To help you learn how to construct requests to the Autotask REST API, Datto provides a customizable REST API request collection for use with Postman. For more information, refer to Sample requests.

Overview

You can use DELETE requests to remove a resource in Autotask via the API. For example, a DELETE request could remove a designated contact group.

NOTE  You can refer to the Online Help to find root and child access URLs of the entity you wish to query. Refer to Finding resource and child access URLs of REST API entities for more information.

BEFORE YOU BEGIN  Examples in this article may use the webservices[n].autotask.net placeholder. In such instances, substitute [n] for the zone of your user, as described in Autotask API zones and WSDL versions > Find your zone's API URL for the REST API or Autotask API zones and WSDL versions > Find your zone's WSDL file URL for SOAP API version 1.6.

Syntax examples

The following example demonstrates how to delete the ContactGroups resource with the unique ID of 4. Click the drop-down to view the syntax.

DELETE URL: 

https://webservices[n].autotask.net/atservicesrest/v1.0/ContactGroups/4

Verifying success or failure

When making operational calls, you will not receive a JSON-formatted response. Creating data will return a JSON-formatted response, which will either be the item ID of the created resource or an error string array. You can verify the success or failure of operational calls by checking their return HTTP status code.

Successful operations will return an HttpStatusCode of 200 with a response that looks similar to this example:

EXAMPLE  "itemId": 4

Unsuccessful operations will return an HttpStatusCode of 500 with a response that looks similar to this example:

EXAMPLE  {"errors":["A ContactGroup already exists with Name [Test 1 Create of Contact Group x]. ContactGroup names must be unique."]}

An unsuccessful operation might also return a 400-series response, depending on the cause of the error. In general, it's a best practice to treat any response other than 200 as an error state.