Troubleshooting and best practices for the PATCH API Call

[Kate_M]

Description	Troubleshooting and best practices for the PATCH API Call
Scope	Many of Lacework’s integration types can be updated programmatically by using the PATCH method with the Lacework API. This article collects together a few specific points and suggestions when using this method.
Solution	Best Practices using PATCH Lacework's API follows the HTTP standards for the PATCH method:  “The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI.  The set of changes is  represented in a format called a "patch document" identified by a media type.”  (https://datatracker.ietf.org/doc/html/rfc5789#section-2)  This means that every patch call identifies the object that is being updated as part of the URI provided to the PATCH call, and the contents of the changes required are provided in the request body (json is used by Lacework).   Further, patch requests only require the parameters that are being changed to be included in the request body. This is in contrast to the PUT method which can be used to update existing objects, but require a full object definition in the request body.  This ability to accept only the parameters being updated on an object (the "delta") allows for the PATCH method to be a quick and easy way to update multiple entities in bulk. For example, to disable all integrations of the same type in one go, a scripted solution based around the PATCH method could work like this: 1) A list of integration GUIDs (the unique identity of each Lacework integration) can first be obtained by a GET request.  INTG_GUIDS=$(curl --location 'https://youraccount.lacework.net/api/v2/AlertChannels' --header 'Content-Type: application/json' --header "Authorization: Bearer ${MY_TOKEN}" | jq -r '.data[].intgGuid') Then by simply looping over this list, updating the URL each time with the next INTG_GUID, we can use the same minimal json body with each different URL.  (The only json being sent to each INTG_GUID in turn is the enabled parameter, and it's new desired value of 0 (zero) to disable it).  for i in `echo $INTG_GUIDS` do curl --location --request PATCH "https://youraccount.lacework.net/api/v2/AlertChannels/${i}" --header 'Content-Type: application/json' --header "Authorization: Bearer ${MY_TOKEN}" -d '{ "enabled" : 0 }' done And then a quick check that the enabled parameter returns 0 for all the integrations (in this case, using AlertChannels, there will always be at least one "1" returned, for the default email AlertChannel, which cannot be disabled) curl --location 'https://youraccount.lacework.net/api/v2/AlertChannels' --header 'Content-Type: application/json' --header "Authorization: Bearer ${MY_TOKEN}" | jq -r '.data[].enabled' 0 0 0 0 1 Email Alert Channels There is a known issue with creating or patching an email type Alert Channel. The response body does not return the channel props Json block. (This block contains the recipient email addresses for the channel). Even though the channelProps are not returned in response to a PATCH call, any updates to the recipients are respected and applied. You can see this update reflected in the UI, or by making a subsequent GET API call. Policies The following policy tags are reserved keywords and any attempts to update them will result in a HTTP 400 error code response: Domain Subdomain Framework An example of attempting to change the domain tag for an existing policy: PATCH json body: {   "tags": [         "domain:AWS",         "subdomain:Configuration"       ] } Response: {"message":"[Error: tag key: domain is reserved, Error: tag key: subdomain is reserved]"}