Let’s Git Commit(ted) to </Dev> Resources: Getting Started with the Workspace ONE UEM REST APIs

February 02, 2022

Have you ever been asked to perform a “one-time clean-up” in your Workspace ONE UEM console, only to have that request be repeated month after month? This could be something like moving devices with a specific set of serial numbers to a different organization group. This can all be accomplished manually using the UEM console, but it is time-consuming. What if there was a way to automate this task? The good news is we can do this with the Workspace ONE UEM REST APIs.

What REST API command is available in my environment?

Every UEM console has its own copy of the API documentation. When new features are added to the UEM console, there is a chance that the feature may have an associated REST API. For this reason, it is a best practice to point to the console you will be accessing when you make the REST API call to see the appropriate documentation. To be certain of where you look for your API documentation, you will need to find the API URL for your environment. This is found at Groups and Settings > All Settings > System > Advanced > Site URLs. You will be looking for the field called REST API URL.

Once you have your URL, you can find the REST API documentation at https://<your URL>/API/help. In the case above, it would be https://as1506.awmdm.com/API/help. You can access this URL by pasting the address into your browser. You will be directed to the Workspace ONE UEM API Explorer. You will see the following screen:

There are two tabs: Overview and API. Much of the information in the Overview tab is addressed in this document. When you click the API tab, you see the endpoints that are available. (You can think of endpoints as the capability to search for a device by serial number, for example, or to move device(s) to a different Organization Group.)

Authentication is Required for Every API Call

You start by creating an account and role for API calls, and then establish the authentication options.

Creating an account and role for API calls

REST API calls can retrieve sensitive information from the Workspace ONE console. This means there is a requirement that every REST API call must contain user authentication information. While it is possible to use standard Administrator accounts, it is a best practice to create special Administrator accounts for REST API calls and applications that will be used on a recurring basis.

Along with creating a special Administrator account for your REST API calls, it is also a best practice to create a special role for the account. It is possible to create a role that ONLY can make REST API calls. As with other roles in the UEM console, you can get very granular with the types of REST API calls that can be made by users that are assigned to the role. The following screenshot shows an example REST API Role:

Graphical user interface, table</p>
<p>Description automatically generated

The Edit permission will be required if you ever use an endpoint that requires a PUT, PATCH, POST, or DELETE command. Read permissions are sufficient for a GET endpoint.

Authentication options

There are 3 authentication options for REST API calls:

  1. Basic – Basic authentication is the easiest method. You simply create a Base64 encoded string with a combination of the REST API accounts username and password with a colon in between them. While Basic authentication is easy to use, it is best used when testing a REST API call or doing something simple that will only be used for a short period of time. The UEM console requires that passwords be changed periodically for Administrator accounts (even REST API Only accounts). If this occurs, calls that are using an old password will fail to authenticate and the call will fail.

    To create Base64 encoded username and password strings, it is easiest to use an online tool like https://base64encode.org. To create the Base64 encoded string, the syntax is <username>:<password> (a colon NO SPACES) between the username and password. Using the example of a REST API administrator with a username of APIAdmin with a password of Test1234!, paste APIAdmin:Test1234! into the text box of the site. Your Base64 string should be QVBJQWRtaW46VGVzdDEyMzQh. Note: Base64 encoding is case-sensitive.

  2. OAuth (Open Authorization) – The OAuth method of authentication is slightly more complex than the Basic method of authentication. With the added complexity comes the benefit of not having to deal with rotating passwords. There will be another complete blog post to discuss exactly how to obtain and use OAuth token as well as how to use the OAuth refresh token to obtain a new access token once the token time to live expires. [See – What is OAuth? Learning the Basics blog post].
  3. Certificate – Certificate authentication adds the complexity of requiring your application to deal with the certificate keystore, so it will not be covered in this document.

REST API Key / Tenant Code

One last piece of information is needed before we can make our REST API call. We need the REST API key. This key is used to identify the appropriate API tenant within a Workspace ONE environment. To locate your API key, navigate to Groups & Settings > All Settings > System > Advanced > API. If all your API keys have the asterisk (*) in them, you will need to create a new REST API key. If you need to create a REST API key, make sure to use Admin (that is the default) as the key account type. Note: You can only create REST API keys at the customer Organization Group.

Graphical user interface, text, application</p>
<p>Description automatically generated

We have the ingredients – Let’s cook up a REST API call

For our exercise to explore the UEM REST APIs, we are going to 1) find the UEM assigned device ID based on the device serial number, 2) find the UEM assigned Organization Group ID for a specific Organization Group, 3) use the IDs that we found in the first two steps to move the device to the Organization Group, and 4) send a command to multiple devices.

When you click the APIs tab, you see that the REST APIs have been broken into different sections: MAM – Mobile Application Management, MCM – Mobile Content Management, MDM – Mobile Device Management, and System Management. Note: It is important to know what section you will be using when creating the URL endpoint for the REST API call.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Since we want to find a device, let’s do a search of the API endpoints. There is a Search box in the top right portion of the page. Since we are going to search for a device based on the serial number, let’s put device in the search box. You will see that the number of endpoints narrows. The left side of the page shows the endpoint, and the right side provides a high-level description.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Looking at the description on the right, I can see that there is an API endpoint that will get device details by an Alternate ID.

Graphical user interface</p>
<p>Description automatically generated with low confidence

If you click the /devices link, it shows additional documentation about the call.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

If you look at the highlighted section, it shows that this API call takes two parameters and that they are both required. We are going to need those parameters for our REST API call.

We need to take note that one of the parameters is searchby and the documentation explains that the valid values are Macaddress, Udid, SerialNumber, Easid, and Deviceid. For the example, we are going to use the device serial number. The second parameter is id. This will be the value that corresponds to the searchby. In my case, the serial number to the device is F9XXXXXXXXF9. I need to put that value in the parameter field.

Understanding how to create a URL endpoint – We need an endpoint for every API Call

There are 3 pieces of information that are required to build the correct URL endpoint:

  • The site URL. We found this in the first part of the post by looking at Groups and Settings > All Settings > System > Advanced > Site URLs. In my example this is https://as1506.awmdm.com/API.
  • The API subsystem Section (mdm, mam, mcm, or system). In this example, we are going to use an mdm endpoint.
  • The endpoint we want to use. In this example, the endpoint we are going to use is /devices based on the documentation. We will see how to handle the parameters below.

Putting it all together, the REST API endpoint is https://as1056.awmdm.com/API/mdm/devices. We are going to need those required parameters that were mentioned by the documentation; we will see them show up when we build the REST API call below.

Adding REST API call ingredients to the mix

Important Note: This section is going to describe the process that allows you to execute REST API calls directly from the documentation page. Please be aware that login credentials and authorization codes are not cached in any way, so if you navigate away from the page at any point during the process, you will need to re-enter those items.

A very nice feature of the API documentation is that we can make REST API calls directly from the documentation. We have the ingredients we need:

  • REST API login credentials
  • REST API tenant code
  • Example REST API endpoint

We need to do some prep work to get everything configured on the documentation page to run our call. The first thing we need to do is Log In:

Graphical user interface, text, application</p>
<p>Description automatically generated with medium confidence

Enter the credential of an account that has permissions to execute REST API commands:

Graphical user interface, application</p>
<p>Description automatically generated

We need to navigate to the REST API endpoint that we are going to run. Enter devices in the search box. This will bring up all the endpoints that reference devices. Some will be easy to identify because some devices are part of the endpoint URL, while others just have devices in the description.

Locate the line in the MDM (Mobile Device Management) REST API V1 section that just has /devices for the endpoint.

Application</p>
<p>Description automatically generated

Click the /devices link and it opens the MDM subsection page.

Table</p>
<p>Description automatically generated with medium confidence

You will probably need to scroll down to see the endpoint you clicked opened to the endpoint details page that we looked at earlier.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Scroll back up to the top of the page. Make sure you are still logged in. We need to authorize our call. This is where we are going to use the REST API key created / obtained earlier in the post. Click the AUTHORIZE button.

Note:  Later in the blog, we are going to use another tool that makes it easier to enter this information.

A picture containing application</p>
<p>Description automatically generated

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Enter the REST API key you found from earlier in the blog and click Authorize.

Back to the detailed information about the API call. We still need to fill out the information from the parameters before we can execute the call. For this example, I’m going to search for the serial number of an iPad. To make sure I have everything set up correctly, I’m going to find a single device in my UEM console and use that serial number for the look-up.

Graphical user interface, application</p>
<p>Description automatically generated

The serial number is F9XXXXXXHLF9.

There are 2 required parameters: searchby and id. Look at the documentation description to determine what these requirements mean. You will see that there are several possible values. Highlighted below is the Serialnumber value that we will use. The id field takes the device serial number of the device we are looking for F9XXXXXXHLF9.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Note: I’ve highlighted the Response Context drop-down below. There are two primary uses for this drop-down. The first is that it allows you to select the format of the data that is returned. The options are XML and JSON. I find it easier to work with JSON, but you may prefer XML. There is no better format, it is just a matter of preference and how you like to deal with the returned data.

IMPORTANT time-saving note: The second portion of the option is version. As the UEM console evolves, there are times when new functionality is added to REST API endpoints. If you ever find yourself needing a version other than version 1, you will need to make sure to add this information to your Content-Type header, which will be covered below.

Graphical user interface, text, application</p>
<p>Description automatically generated

Let’s “Try it out!”

All the prep work is finally done. We are ready to see if we can use the REST API call to retrieve our device. Below the parameter details and the information about potential responses, there is a Try It Out! button. If everything is correct, the page will show a response code of 200, which means the call was successful.

Graphical user interface, application, Word</p>
<p>Description automatically generated

The page returns a lot of useful information that we can use to build our knowledge and be more efficient when creating the next REST API call.

  • REST Method – REST allows for the retrieval (GET), creation (POST / PUT), updating (PATCH), and deletion (DELETE) of data. The documentation page shows the appropriate REST method at the left-most column of the description. You will also see how to format parameters.
  • Headers – REST APIs make use of headers to pass information to the UEM server. The top line of the response shows the 3 headers that were needed for the call:
    • Accept – This is the information from the Response Content Type drop-down selected. The default type is application/json. Try changing that drop-down to application/xml and executing the call again. This would also change if you were using a version other than V1. Some V2 calls use the application/json;version=2.
    • Authorization – This is the Base64 encoded combination of your username:password, with the word Basic<space> in front of it (Basic is case sensitive).
    • aw-tenant-code – This is the REST API key retrieved from the UEM console
  • Request URL – This is the REST API endpoint that was called with the associated parameters.
    Note: Not all endpoints use parameters, so check the documentation page for details.
  • Body – This is the result of our call. We searched for a device, and it returned all the information about the device.

We now have all the basics in place. To complete the project, we are going to find the UEM ID of the location group we want to move the device to, and then move the device.

Understanding the Workspace ONE UEM ID

One of the most important concepts when learning about using the UEM REST API is understanding the UEM assigned ID. When devices, applications, organization groups (just about anything in the console) is added to the environment, UEM assigns an internal ID to that object.

You may notice this when viewing a device in the console. In the screenshot below, I’ve highlighted the UEM device ID as it appears in the console. This is the device I just looked up using the REST API for /devices. The highlighted number (1034831) is the Workspace ONE UEM assigned device number. We could use this number in any of our REST API calls that require the ID, and moving the device to a separate Organization Group will use this ID.

Graphical user interface, application, website</p>
<p>Description automatically generated

That UEM assigned Device ID is returned in the JSON or XML file body. Let’s look at all the data that was returned for that device. The UEM device ID is highlighted at the bottom of the returned information.

{
  "Udid": "69f85c1cXXXXXXXXXXXXXXXb5cad31edb5a22468",
  "SerialNumber": "F9XXXXXXHLF9",
  "MacAddress": "F8XXXXXX292",
  "Imei": "",
  "EasId": "5C58PAXXXXXXXXXA28GN634",
  "AssetNumber": "69f85c1cb4eb92c4acdf89ab5cad31edb5a22468",
  "DeviceFriendlyName": "scurry iPad iOS 15.2.0 HLF9",
  "DeviceReportedName": "Curryware Demo iPad",
  "LocationGroupId": {
    "Id": {
      "Value": 10154
    },
    "Name": "VMware scotcurry",
    "Uuid": "725aaf25-085f-4e9f-ae60-4d58187e70da"
  },
  "LocationGroupName": "VMware scotcurry",
  "UserName": "scurry",
  "DataProtectionStatus": 0,
  "UserEmailAddress": "scurry@curryware.org",
  "Ownership": "C",
  "PlatformId": {
    "Id": {
      "Value": 2
    },
    "Name": "Apple"
  },
  "Platform": "Apple",
  "ModelId": {
    "Id": {
      "Value": 2
    },
    "Name": "iPad (9.7-inch, 5th generation) (32 GB Space Gray)"
  },
  "Model": "iPad (9.7-inch, 5th generation) (32 GB Space Gray)",
  "OperatingSystem": "15.2.0",
  "PhoneNumber": "",
  "LastSeen": "2022-01-06T14:06:35.863",
  "EnrollmentStatus": "Enrolled",
  "ComplianceStatus": "Compliant",
  "CompromisedStatus": false,
  "LastEnrolledOn": "2021-11-18T15:23:50.093",
  "LastComplianceCheckOn": "2021-11-18T15:27:42.773",
  "LastCompromisedCheckOn": "0001-01-01T00:00:00.000",
  "IsSupervised": false,
  "IsRemoteManagementEnabled": "False",
  "DataEncryptionYN": "Y",
  "AcLineStatus": 0,
  "VirtualMemory": 0,
  "OEMInfo": "MP2F2LL",
  "DeviceCapacity": 32,
  "AvailableDeviceCapacity": 8.939146041870117,
  "LastSystemSampleTime": "2022-01-06T14:06:36.000",
  "IsDeviceDNDEnabled": false,
  "IsDeviceLocatorEnabled": true,
  "IsCloudBackupEnabled": true,
  "IsActivationLockEnabled": true,
  "IsNetworkTethered": true,
  "BatteryLevel": "85%",
  "IsRoaming": false,
  "LastNetworkLANSampleTime": "2022-01-06T14:06:36.000",
  "LastBluetoothSampleTime": "2022-01-06T14:06:36.000",
  "SystemIntegrityProtectionEnabled": false,
  "ProcessorArchitecture": 0,
  "TotalPhysicalMemory": 2076229632,
  "AvailablePhysicalMemory": 1747206144,
  "OSBuildVersion": "19C56",
  "HostName": "",
  "LocalHostName": "",
  "DeviceNetworkInfo": [
    {
      "ConnectionType": "WiFi",
      "MACAddress": "F8:XX:XX:XX:62:92"
    },
    {
      "ConnectionType": "Bluetooth",
      "MACAddress": "F8:XX:XX:XX:63:05"
    }
  ],
  "EnrollmentUserUuid": "33be03e8-12da-40c9-ab6d-50a1e3f5ca5a",
  "ManagedBy": 1,
  "Id": {
    "Value": 1034831
  },
  "Uuid": "79a5c274-6ef7-4ff3-b000-446f855d6c63"
}

As expected, we see the same value that we saw in the console of 1034831.

You will (eventually) need a special client to make REST API calls!

While it is a nice feature that you can make API calls from the documentation, there are drawbacks. What if you navigate away from the MDM page, for example, to the System page? If you had entered the authorization code on the MDM page, it would have to be re-entered when you return. This is the main reason you would want to use a tool better suited to making REST API calls.

There are several specialized tools that have been built specifically to make REST API calls. The most well-known is a tool called Postman (a free download that supports most operating systems). For the rest of this post, I will be showing screenshots created using the Postman client (v 9.5.0), so if you would like to follow along, please get a copy. If for some reason you don’t want to download a client to your machine, there is an online tool called ReqBin that you can use as well. See the Let’s Git Commit(ed) to </Dev> Resources blog for a list of REST API clients.

Cooking up the call for the UEM ID of an Organization Group with Postman

We need a REST endpoint to search for organization groups. One of the challenges with getting familiar with any API technology is learning where information is stored and what it is called. If you do a search for Organization Groups or OrganizationGroups, you will not find the endpoint we need for this call. The endpoint that is required is /groups/search, so put that in the search bar.

Graphical user interface, application</p>
<p>Description automatically generated

The first thing to take note of is that the endpoint uses a GET. This is the same as our device lookup. We are just asking the console for information. When we move the device to another Organization Group, we will use a third REST endpoint. Also notice that it is under the System sub-category, and it is using a V2 (version 2) endpoint. As we look at the details of the call, we see that there are no required parameters, but there are optional parameters. If you don’t put anything in, all the groups will be returned. We are going to use groupid because it requires an exact match, so we will only get back a single OG.

Graphical user interface, text, application</p>
<p>Description automatically generated

Ingredients for this REST API call:

  • Endpoint URL – https://as1506.awmdm.com/API/system/groups/search - API Server from Site URLs + REST subsystem (System) + Endpoint
  • Base64 Encoded Username & Password – Basic QVBJQWRtaW46VGVzdDEyMzQh – The word Basic + Base64 encoded APIAdmin:Test1234! (Replace these values with the username and password and use an online tool to encode the value.
  • Tenant Code - fq4BXXXXXXXXXXXXXXXXXXXXXXXXXXbClTwj7mY=. The value from the UEM console – Groups & Settings > All Settings > System > Advanced > API > REST API.
  • Accept Header – application/json;version=2 Note:  This is a version 2 API so that should be appended to the usual application/json (you can also use application/xml).

Let’s mix the ingredients in Postman

Here is what the call looks like when ported to Postman.

Graphical user interface, application</p>
<p>Description automatically generated

  • GET Dropdown - The default REST method in Postman is GET. In the next example, that will be changed, but for this call, it was left at the default value.
  • Endpoint URL – That information had to be filled in:  https://as1506.awmdm.com/API/system/groups/search?groupid=restapi
  • Pro tip - If you click the Parameters tab (Params in the Postman UI), you will see another way to enter those values.
  • Headers – All the Ingredients we brought together above. Pro tip – There is a way to perform authorization from the Authorization tab. Select Basic Auth from the Auth type download. You will then be able to add the Username and Password in the dialog boxes. It is a best practice to use OAuth authentication. This will be discussed in a separate blog post later in this month’s series.

Once you have entered the appropriate values, you click the Send button. If everything is correct you will get a response that shows the Organization Group information.

Body – This is the result of the search. I searched for an Organization Group with the name of restapi. The call returned an id of 26498. The complete Body is:

{
    "OrganizationGroups": [
        {
            "Id": 26498,
            "Uuid": "93be4adb-b9c7-49d7-9126-51382a22fb6a",
            "Name": "REST API Destination OG",
            "GroupId": "restapi",
            "LocationGroupType": "Container",
            "Country": "United States",
            "Locale": "English (United States)",
            "CreatedOn": "1/6/2022 5:59:39 PM",
            "LgLevel": 0,
            "Users": "0",
            "Admins": "0",
            "Devices": "0"
        }
    ],
    "AdditionalInfo": {
        "Links": [
            {
                "Rel": "self",
                "Href": http://as1506.awmdm.com/API/system/groups/search?groupid=restapi&page=0&pagesize=500
            }
        ]
    },
    "TotalResults": 1
}

Let’s move our device to the Organization Group

Let’s explore the different ways we can use to move our device.

Two ways to move the device

As with our other calls, the best place to start is to look in the documentation to see what REST endpoint we will use. Do a search across all subsystems.

Note:  If you are ever on a subsystem page, you can get back to the main page by clicking on Workspace ONE UEM API Explorer at the top left of the page.

Graphical user interface, application</p>
<p>Description automatically generated

The return shows us that there are two ways to move a device: 1) /devices/commands/changeorganizationgroup which takes a POST, and 2) /devices/{id}/commands/changeorganizationgroup/{organizationgroupid} which takes a PUT. Reading the documentation, it appears that there is a method that combines the first example call where we found the UEM device ID by looking up the serial number and moving it to the Organization Group ID we just found.

We’ve already done the work for the PUT method, so we will use that one first. We will then show the POST method that will allow us to send a command to multiple devices.

Note: Be aware of the Response Messages. REST API methods that add (POST, PUT), update (PATCH), and delete (DELETE) commands don’t usually respond with a JSON body. We need to validate the return status code to make sure our command was successful.

Looking at the documentation details of the PUT method, we see two items for the first time {id} and {organizationgroupid}. These are substitution parameters. I’m sure you can guess that we are going to replace these with the value that we found in the first two API calls.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Pro tip – You don’t need to fill in the login and authorization field to use the Try It Out button. Obviously, the call will not work, but you can see what the endpoint URL should look like. The screenshot below shows the result of the Try it out! button.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Back to Postman to move our device

We always start with the same ingredients: Endpoint URL, aw-tenant-code, Authorization, and Accept Header. If you saved the call for the Organization group, you can use that as the starting point and just change the REST Method and Endpoint URL as shown below.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

All the header information is the same as the call we made to get the Organization Group information. We do need to use the method drop-down and change the method to a PUT as described in the documentation. Also, note that there is nothing in the Body. This is the reason we need to validate the Return Value. In this case, the return value is 202 Accepted. If you were following along, look at your console and you should see the device has moved into the new Organization Group.

Note:  Once you modify a call in Postman, you can Save As… to save the current REST API call. You can create a collection of reusable calls.

Let’s send a command to multiple devices

So far, we have been doing everything one at a time. There are times when you want to perform an action on multiple devices. At times you will need to build a script that has looping logic. We have several blogs that will help you on that journey. Fortunately, there are built-in REST API commands that can operate on multiple devices at one time. For this example, we are going to send a Lock command to multiple devices based on Serial Number. Back to the documentation to find that command.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

There are many endpoints that are listed, so find the endpoint called /devices/commands/bulk. It will be in the MDM REST API V1 subsection. There are a couple of items that we haven’t seen before. This is common when working with REST endpoints that use the POST method. Many POST commands require a data payload as part of the request.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

The screenshot shows two fields we haven’t seen up to this point: 1) Content-Type – this is going to specify the format of the content body, and 2) Body – this is the data that needs to be passed to the server. Change the dropdown that defaults to application/json to application/xml and watch what happens to the example data field. You will see that it changes from JSON to XML. It is important to know what type of data you prefer to work with because you will need to tell the UEM server what to expect. I prefer to work with JSON, so I’m going to build my body section as a JSON file.

The description tells me I need a list of devices ID’s and tells me I can pick from Macaddress, Udid, SerialNumber, or ImeiNumber. I’m going to build mine using SerialNumber. This is what my body file is going to look like:

{
 "BulkValues": {
  "Value": [
   "89QX0DVFT",
   "VPX7L5CX4D",
   "F9GTKFQPHLF9"
  ]
 }
}

It is a best practice to run your JSON (or XML) file through a validation tool before attempting to use it in your API call. There are several online tools. I used https://jsonlint.com/ to validate the information above.

REST API calls can take a combination of parameters and a body. This example illustrates having both. The parameters are command and searchby. See the screenshot below for the example created from the documentation page.

Graphical user interface, text, application, email</p>
<p>Description automatically generated

Let’s try the same command in Postman

Headers View

Graphical user interface, text, application</p>
<p>Description automatically generated

Just a few changes: 1) We need to add a Content-Type header that specified what will appear in the Body (screenshot below), and 2) This endpoint uses a POST method.

Body View

Graphical user interface, text, application</p>
<p>Description automatically generated

This is the first time we need to use a separate tab. The Body tab is where we paste the JSON file with the Serial Numbers we want to send the command to. There are many options for the Body. If you have validated the JSON using the JSONLint website (recommended) select the RAW option.

This endpoint demonstrates another new concept. There is a Return Status like there was when we called the PUT endpoint. There is also a Body returned. This return shows the number of items that were successful (AcceptedItems) and failed (FailedItems). It is possible to send a Serial Number that cannot be located. The call returns the number of devices it found and sent the command to (AcceptedItems) and any errors it encountered (FailedItems).

Conclusion and final thoughts

The Workspace ONE UEM product is extremely powerful, with the ability to handle devices, users, applications, content, and the platform to maintain all that information. There are corresponding REST API commands for most of the information that is managed by the console. It will take time to look through the documentation and become familiar with all the endpoints. Using the Search functionality should help.

Once you have the correct endpoint, you should have all the ingredients you need to run the REST API command.

While we did touch on a POST endpoint, you will find that there are many endpoints where the example of the Body that needs to be passed is extensive. I would recommend you try to find a corresponding GET command to get an idea of what field might be required for the call. Other than that, it is a fair amount of trial and error.

Happy cooking!

Agenda

By the way - make sure to check out the other blog posts in our 28-day series:

Associated Content

From the action bar MORE button.

Filter Tags

Workspace ONE Workspace ONE Access Workspace ONE Intelligence Workspace ONE UEM Blog Technical Overview Intermediate Optimize