Using the API with Cross-Site Scripting Protection
This error (API token verification error) means that from the authentication perspective everything is fine.
For example, you can get any information from PAM at this point.
However, to use POST and PUT to create or change something, there is another level of protection from cross-site scripting attacks which is completely unrelated to authentication tokens.
The carrier of this protection is also called a token, (API Token or XSRF Token) but has nothing to do with authentication tokens that are referenced here.
To get this token you need to call /rest/user/whoami function – which is a GET function, meaning you do not require an API Token to call this function (you still need Authentication Token and Auth Cookie).
It is the only function that generates an API token and returns it in the XSRF-TOKEN cookie (Set-Cookie response header).
Below is the link with the example of how to get this XSRF-TOKEN:
You need to pass a value of this XSRF-TOKEN as a X-XSRF-TOKEN header when POST or PUT anything.
Below is the link with the example how to send this API Token as a header (scroll to create record section).
Note that this example does not include how to retrieve the API token referenced previously. (This is because you need to get it for every function or get it in the beginning for all functions. For this reason, me moved the explanation to the bottom of this page as a separate example as to not bog down the API examples.)
XSRF-TOKENS are relatively short lived so there is no point to save them – call whoami every time in the script.
The PAM GUI itself calls this function in the beginning. Therefore, you can log into PAM, open dev console, navigate to the network tab and refresh the page. You can then find the call to whoami to see the results it returns.
Something like update a record will use this token as a header which is also visible on the browser’s dev console.
