How can I download permission tables?

I would like to programmatically download the entity (Artist, Admin, etc) permissions (Shot: see, created, delete, edit, etc) and haven’t been able to find a way with my limited knowledge of Shotgun. I have tried the shotgun_api3 module, but although I am able to get the PermissionRuleSet data itself (eg sg.schema_field_read("PermissionRuleSet")), I can’t find a way to get the actual permission data proper.

The permissions are available from a POST request in the REST API used by the webbrowser, obviously, so, using my limited web knowledge, I tried mimicking what it was doing with the Python requests module like so:

# Get authorization tokens
url = "https://<REDACTED>"
data = {"client_id": <REDACTED>,
        "client_secret": <REDACTED>,
        "grant_type": "client_credentials"}
response =, data=data)
authorization = response.json()

# Lookup permission rule set
url = "https://<REDACTED>"
data = {"permission_rule_set_code": "artist"}
headers = {}
headers["Authorization"] = "{} {}".format(authorization["token_type"], authorization["access_token"])
response =, headers=headers,  json=data)

The authorization works correctly (I get back the expected tokens), but the POST response is an HTML page of javascript dealing with logins. My Chrome browser doesn’t render the page correctly, so I infer that its trying to get me to login.

I’m hoping that the above just needs some tweaks (I’m not a web dev), but I’m open to other programmatic tools and techniques too. I don’t need to re-upload changes to permissions, only to readout the current values, via a cron job, say.

Any advice? How can I get the permissions tables data?

Backstory: A version of something went missing, even though the local databases and filesystems indicate it was published correctly. After some consternation, the item was found in the SG trash and un-retired, and so production tranquility was restored. A ticket has come down to alter delete permissions so that this can be avoided in the future. I would like to capture the current state of permissions to track changes, the introduction server-side of new permissions with advancing versions of SG, etc. etc.


Hi bot,

If you’re receiving back an html response dealing with logins it means that the connection you’re using to request the data currently isn’t authenticated and so it’s prompting you log in. It doesn’t make a lot of sense, I know, but that’s what that part means at least.

As far as reading the entire set of permission rules via the API, that currently isn’t something that’s supported as far as I’m aware. If you want to preserve the current state of your permission groups before you start making significant changes; the easiest thing to do would be to simply duplicate the existing group(s) you’re about to perform surgery on. Give them a name so you know what they’re for (e.g. Artist Reference Permissions 04.08.2021), and then start making your changes. That way if your new changes somehow manage to be completely unrecoverable (very unlikely) you can always switch folks over to the duplicated group and start again.

Hope that helps!


Hey @brandon.foster,

Ah. you’re right, yes, I see the connection would need to be pooled. I’ve taken your advice duplicated our permission rule set tables, which mitigates the risk somewhat. I changed some permissions yesterday, and no one seems to have noticed and no explosions were reported. No news is good news.