The List Alerts V2 - GET endpoint returns HTTP 413 under certain (unclear) conditions. The List Alerts V2 - POST endpoint does not seem to have this issue. HTTP 413 is not mentioned as a possible response code for the GET endpoint, and there doesn't seem to be anything to suggest that these endpoints would behave differently such that the POST endpoint would be unaffected.
Add HTTP 413 to the set of possible responses for the GET endpoint, with a summary of the cause of this response code
Deprecate the GET endpoint, or add a note that the POST endpoint is more reliable and preferred
Additional Information
In our support case we made a request to the GET endpoint specifying timeUnit=day&timeAmount=10&detailed=true&limit=1&alert.status=open. The first request succeeded, but attempting to get the next page using the pageToken param led to HTTP 413. Using the same filter with pagination for the POST endpoint, as recommended by support, did not have this issue.
We did not see this error in our test environment, with ~120 alerts, but saw it in a larger production environment with substantially more alerts.
Describe the problem
The
List Alerts V2 - GET
endpoint returns HTTP 413 under certain (unclear) conditions. TheList Alerts V2 - POST
endpoint does not seem to have this issue. HTTP 413 is not mentioned as a possible response code for the GET endpoint, and there doesn't seem to be anything to suggest that these endpoints would behave differently such that the POST endpoint would be unaffected.https://prisma.pan.dev/api/cloud/cspm/alerts#operation/get-alerts-v2
(This issue is based on support case
02378102
.)Suggested fix
Any of the following:
Additional Information
In our support case we made a request to the GET endpoint specifying
timeUnit=day&timeAmount=10&detailed=true&limit=1&alert.status=open
. The first request succeeded, but attempting to get the next page using thepageToken
param led to HTTP 413. Using the same filter with pagination for the POST endpoint, as recommended by support, did not have this issue.We did not see this error in our test environment, with ~120 alerts, but saw it in a larger production environment with substantially more alerts.