Hey team! Following the ShotGrid rebranding announcement, I’m wondering to what extent this name change and transition is going to affect the API. Will the Github name change, for example? Will the API be renamed to shotgrid_api? Will there be mandatory updates, e.g. to core? If these things are going to change, what’s the timeline on this?
I was wondering this, too. From section 31:
…end users of the ShotGrid API should also configure a Personal Access Token in their Shotgun user profile
Does that mean the traditional API script keys are going away and being replaced by these personal access tokens? Could someone expand on this system and what the migration looks like? There’s worry that tools we have relying on API script names/keys will suddenly stop working on this switchover date.
7 Likes
Yes all of these details are critical in being able to plan for any upcoming changes. This is already generating an enormous amount of work for studios.
Will there still be user/password authentication support via the API or will this change as well?
You should review your code to ensure it remains compatible with ShotGrid functioning with Autodesk user management.
Documentation for this will be linked from the ShotGrid application once the migration flow is available.
Less than 4 weeks of notice until things start to transition and only 4 months to execute a plan to manage the technical side of these transitions… it’s not a ton of time.
9 Likes
Migration to AutoDesk support…
We now have:
a street team working on issues
Soon we’ll experience:
going on a support journey with different modalities.
Seems legit
2 Likes
A thing you are all forgetting… Will ShotGrid “feature” more crashes just Like Maya?
1 Like
Many, many questions… the FAQ didn’t really do much to address how the APIs are affected. Looking forward to detailed migration documentation.
6 Likes
Totally second that. The impact of these changes and how to alleviate them is totally unknown to us.
This needs to be clearly explained so we can prepare for it.
Shotgun is not just a web service where users login, it’s a rich and complex ecosystem that productions rely on. And this seems to have been totally ignored, at least in the communication so far.
9 Likes
Hi All,
It looks like there are no changes to API access, does’t need Autodesk identity. I’m getting someone to put out an official response about this.
-David
9 Likes
Thanks, David!
2 Likes
Just to be clear, API Auth using Script Name / API Key pairs will NOT be impacted
This will be business as usual for those… except for one thing : creation of HumanUsers : you will be able to create inactive users but not active ones.
There is a long story here, but because user creation also implies license assignment and invites being sent out by Autodesk backend services. To create an active HumanUser, you will need to connect to the API with a HumanUser credentials. (this will still be possible using your existing Shotgun user credentials, but will be dependant on that user creating a Personal Access Token on their Autodesk Identity profile, and copy-pasting that token into their Shotgun User Settings)
-Patrick
7 Likes
Okay so we can still create users however there is an extra step involved to activating them?
Because Shotgun is tied to our Network user management in places…
1 Like
You are not the only studio in this situation: using scripts to maintain their Shotgun user list and statuses. We do not want to prevent that flow… But yes, extra steps depending on how things are currently done.
The difficulty for us is that every studio that does this has their own recipe/scripts/methodologies. It makes it difficult for us to ensure that all of them will continue to work, or forecast the exact changes needed. This will require some testing on the studio’s end.
Taking a step back… In Shotgun, the use of sudo_as and having an admin/script use/see/interact with the site as one of their user does is not going away. But with the integration with Autodesk Identity and named user, we will not allow a user or a script to impersonate (a.k.a. sudo_as ) another Autodesk Identity user when interacting with services outside of Shotgun. This would be a security risk, and makes it way more difficult to trace and investigate.
-Patrick
3 Likes
Hey Patrick, does it mean that the sudo_as_login option of the Shotgun python API (API Reference — python-api v3.2.6 documentation) is going away? because we rely on that for some web services.
3 Likes
Hi @kevinsallee
Rest (no pun intended) assured that the sudo_as_login functionality is not going away. It is an integral part of the way shotgun is used, and is essential to many workflows.
As mentioned earlier, you will not be able to use sudo to perform actions external to the Shotgun site that uses the sudo target’s Identity profile.
The only constraint that we have identified at this time is with the creation of active users via the API.
-Patrick
3 Likes
@patrick-hubert-adsk could you clarify one point about the user access tokens? If an API script authenticates with user credentials, will this access token need to be put in place first? If so, can the generation and setting of these access tokens be automated in any way?
I ask because we have users who authenticate through pipeline tools using their login credentials, and if we have to make every user in the studio set up their own access tokens it is going to take quite some time.
1 Like
Good question @brandon.foster , I should have given more context.
I do not know if any client-facing docs is already available (and it really should have been, when the rebranding announcement was made)… I’ll try to find out and post it here.
The logic behind the use of that token is : from day -1 to day 0 of using Identity, there should not be a need for end-user to update any of their current software or the way they were connecting to Shotgun.
When authenticating via an API for a HumanUser, you would use the same credentials as before.
The magic happens at the Shotgun level : adding a Personal Access Token (PAT) to your user allows a way for Shotgun to authenticate you against Identity by validating your PAT. If it is valid, you are considered authenticated and the call can proceed.
The underlying mechanics are a bit more complex, but the 30,000 foot view is : by adding a PAT to your Shotgun user ahead of the migration to Autodesk Identity, you will be able to connect to the server as you would before.
Hoping it makes things a bit clearer.
-Patrick
1 Like
I may need more 
, but your reply seems to contradict itself.
…there should not be a need for end-user to update any of their current software or the way they were connecting to Shotgun.
That sounds good, no changes needed by us. But then:
…by adding a PAT to your Shotgun user ahead of the migration to Autodesk Identity, you will be able to connect to the server as you would before.
So if we don’t add a PAT to each and every user, they will not be able to continue to access Shotgun via the API with their user credentials like they could before? And how can we begin to generate these tokens for users if we don’t have access to this new Identity management named user system before the date all this goes live in 3 weeks?
1 Like
Sorry, I’ll rephrase:
You need to have a PAT set up for your user first. No PAT, no API access with username/password.
PAT creation and addition to the user account will need to be done by them. You cannot, even as an admin, do that for another user. Admins will likely have to communicate with their users as to the need to go through that process.
Once that is done, users with a PAT will be able to log in using the API as they did before.
For a regular user, it is not clear to them if they are using the API or not. It depends on the tools being used and their workflow.
Still need more coffee ? 
-Patrick
1 Like
As an added note, Identity will not be switched on automatically under your feet.
There will be a transition period, of a few weeks, which will give time to the admins to validate that all of their users have an Identity account tied to their email used in Shotgun.
From Shotgun, as an admin, you will be able to send invites to your users for those that do not have an Identity account. This transition period will allow time for your users to generate their PAT and add them to their account. As an Admin, you will be able to see who has their PAT set up, and those that do not.
You, the Admin, will be able to control the migration process, and you will be the one pulling the trigger to use set Identity as the authentication method on your site.
This is for existing sites. New trial sites, spun up starting from June 7th, will use Identity from the start.
-Patrick
Man, this is going to be a terrible experience for us based on what you’ve described with PATs. We have a large amount of freelancers, and sometimes they may only be booked for a day or two.
If we have a freelancer come in and they set up their PAT, will that still be valid if we deactivate their Identity / Shotgun User and then reactivate it? To add to this will Shotgun user creation / activation be tied to their Autodesk Identity or are we now going to be managing accounts in multiple locations?