Here’s an example payload for the API call:
"state": "Under Review",
"reason": "Acceptable Risk"
You don’t actually need to fill in any of the info under links - those are fields that are populated when you do a GET of this endpoint and allows you to see more exception info.
The date format you see with
expires is the one you want to use, and you can update the date/time as you see fit.
scope, the ID is the asset ID since we’re doing a
type of asset, and the
vulnerability is just the name.
The state is going to be “Under Review” since the others are all approval/expiration related options.
The only field you need under
reason, and if you look at the documentation for this endpoint, you can see the valid options for
reason listed there.
In general if you’re trying to figure out what a payload requires in the future, one thing that can help is to do a GET of the endpoint and see what the payload looks like. In this case I did a GET for
api/3/vulnerability_exceptions in Postman and it allowed me to see what the above values should look like for an exception.
Also if you try to POST to this endpoint and you’re missing a field or have some other issue, the API may give you a helpful error message telling you what the issue is. When I was testing the payload above, I get a Bad Request and the error message told me that “State is a required field.” So sometimes you just have to play around with it until you get it right.