Rally - WSAPI: Not authorized to perform action: Invalid key


Article ID: 127054


Updated On:


CA Agile Central On Premise (Rally) CA Agile Central SaaS (Rally)


When trying to use the web services API to create or modify data, the following is seen in the errors section of the response:
"Not authorized to perform action: Invalid key"


This error can be encountered for the following reasons:

  • Using basic credentials without a security token in sandbox or on-premises
  • Using an API key with a client that maintains sessions using cookies
  • Using a read-only API key in the presence of an existing session that used basic authentication
  • Using a security token with a client that doesn't persist/pass cookies
  • Cached results in a proxy


Basic Credentials

Basic credentials cannot POST changes without first acquiring a security token.  This process has been deprecated in the production environment in favor of using API keys, however is still necessary for sandbox environments and on-premises appliances.


Session Maintaining Application

If you are working within an application that has already registered a session and you try to use an API key, you may encounter the above error if the application is sending cookie data that contains authorization from your registered session.  When this happens, it is effectively the same issue as sending basic credentials without a security token.


In this scenario, either disable cookies in the application/request or manually send a blank Cookie header.


An example of this scenario would be using a browser with an installed REST API client extension.  You are logged into Rally in another tab in the browser and using an API key in the REST API client extension.  If the browser is sending the existing cookie session data, the request may fail.


Not maintaining cookies

Each security token that is generated is tied to a session ID.  If you do not pass a session ID back to each request in the API, Rally assumes this is a new login and generates a new session ID.   At a minimum, you must capture JSESSIONID from the cookie of the authorization request and pass that back in the subsequent request to create, modify or delete data.  

The following is an example flow in curl:

First, we call the authorization endpoint, making sure to write a cookie file

curl -b cookies.txt -c cookies.txt -u [username]:[password] https://sandbox.rallydev.com/slm/webservice/v2.0/security/authorize

Next, open the cookie file and get the value for JSESSIONID.  Use that for the [jessionid] value below

Copy the SecurityToken value from the request above and replace [security_token] in the request below

curl -H "cookie: JSESSIONID=[jsessionid]" -u [username]:[password] -H "Content-Type: application/json" -d"{\"Defect\": {\"Name\": \"Hello world\",\"Description\": \"Hello world\",\"Workspace\": \"/workspace/198278166140\",\"Project\":\"/project/198278166556\"}}" https://sandbox.rallydev.com/slm/webservice/v2.0/defect/create?key=[security_token]


Read-only API Key

This scenario is actually a combination of the above two issues.  Under normal circumstances, a read-only key trying to POST would result in a 401 error.  However when using a read-only key in the presence of an established session it is guaranteed to try and use the credentials from the established session and will fail.



Cached Results

An extenuating condition where this is seen with full-access keys, is one where invalid POST operations have been attempted and subsequently the "Invalid key" response has been cached for that request by a proxy.  If there is a caching proxy server in use at your location, then there is no control over that from an Agile Central perspective and you will need to work with your network team to adjust rules to prevent responses from being cached.

Additional Information

Agile Central - WSAPI: Api Key and Oauth Client FAQ


1558686165457000127054_sktwi1f5rjvs16ev2.png get_app