Need to view webhooks in the grid view. Appreciate the registration view, however, our list of hooks is growing and it would be really convenient if we could see and edit some of the value in a grid view. The list will soon grow too long for us to manage in the current interface.
Need to be able to register a hook across multiple entities. The registration process is lengthy and we have a generic hook that spreads across multiple entities. It would be a lot better if we could pick multiple entities for a hook. If we had a grid view, having an option to duplicate a hook would also suffice and or be requested/needed.
Need the ability to access the hooks via the API so that we can automatically manage the URL during our serverless deployment and syncing operations from dev to prod instances.
I am sure I will have more. Hoping others here will start to add to this list.
Thanks for Posting. I think our Webhooks beta squadron will be happy to see these feedback. You could follow the post here to submit future feature requests.
Thanks for the response. When will the python wrapper be updated to support WebHooks? Regretfully all of our interaction with SG is currently being performed via the python wrappers.
Why? While I may be the first user to make the request, it doesn’t seem unreasonable to add the functionality. Furthermore, it seems short sided to add the functionality in one place but not the other. Do you guys plan to stop supporting the python API and maintaining it? Studios have piles of legacy code built on the python API. Please be straight as to why this is not in the plans.
There are currently no plans to deprecate the Python API or the endpoints it communicates with, which are different from the REST API endpoints.
The team felt that the REST API offered an easy enough way to interact with webhooks that we didn’t need to duplicate the functionality into the Python API. The use cases for entity querying and updating records vs Webhook management seem isolated enough from each other, you probably wouldn’t do both webhook management and record creation/editing in the same tool. Considering this separation of tool responsibilities, we didn’t feel that different access mechanisms would complexify any one given tool’s code.
Here is a usage case I expect to implement that does not subscribe to that rational that a developer would NOT query the database for entries while doing Webhooks maintenance, and hence why I’d like a python endpoint.
In the last 3 facilities I have worked for (all very large facilities with 500-1000 employees), I have implemented a global data point entity (Custom Non Project Entity ) to track user utilization of studio tools relative to a project and user. The rational behind this has been that I can track tool adoption relative to project and user and use this to help the projects succeed and management see the value of our pipeline work. This usage data needs to be persistent and historically available indefinitely (apparently Webhooks purges some of this info). Think of it as a bean counter or a turnstile in a subway. Then with the data in SG we use dashboard pages with graphs to review tool usage as it relates to the departments, projects or users. The hook to add entries into this database often lives in the base class of our tools. Currently we have a hook in our action menu item base class, however adding one directly in our Webhook class is a bit more risky for performance reasons. I plan to create a CRON service that extracts daily usage summaries of Webhooks and re-injects them back into a custom table in SG to assist in ROI/ROA (rate of adoption).
I know this data is in the Webhooks table, however everything about the Webhook data table is non-Shotgun like. A phrase that comes to mind during code reviews is NonPythonic. Managing the Webhook entries in a SG grid is not accessible, natively linking Webhook’s to our global data point table is not possible, the UI is a bit clumsy when you have Webhook names that are long or a long list of Webhooks and now the data is not accessible via the python API. Webhooks largely feels like a separate app strapped on top of SG.
The current implementation of Webhooks is a great spike of work that already appears very promising. I don’t want to overshadow that with my next few bits of commentary. I do mean GREAT! I truly think Webhooks is an astounding addition to SG. However, I believe they need some more refinement to make them more Shotgun-like, hence my persistence here and unwillingness to let some of these things go as “oh-well that’s the way it was meant to be”. Maybe the way it was meant to be needed more user feedback. My biggest fear is that Webhooks will be branded for ever more beta and continued development, improvement and refinement on it become abandoned like other spiked efforts we have seen within SG. Or when improvements are needed to be made they are made to serve internal SG development interests rather than the requests of the developer community. And as a result, throughout this journey user development team come to terms and are forced to accept the warts.
I am also concerned that my feedback into a black box of feature request does not drum up the right conversation regarding the needs for these improvements to warrant change. Hence utilizing this community board and this private section on Webhooks as a sounding board.
Thought I would share an update here. I configured a separate SG authentication method to double up authentication via rest API in my utils library. I was able to borrow our Jira requests authentication methods for the SG restAPI. As a result I made a separate method to gather webhooks data to help build out our Confluence documentation. Feeling a bit more confident about using both API’s sparingly. I am also considering building an action menu tool to synchronize to a Custom Non Project entity table for Webhooks but running out of non-project entities.
I’m very interested to see these become a mainstream feature which could serve to augment or replace current shotgun event daemons. But we are reluctant to shift our dependence to a “beta” (potentially volatile) feature.
@bouchep - Is there any updates you can share for the timeline of Webhooks?
I see they’re still in the “building” section of the Shotgun Roadmap.
Respectfully, I disagree with that assumption – if you have a tool that responds to webhooks via the Python API, I think it’s super reasonable to want that tool to be able to install itself to a Shotgrid site using the same API.
I have this exact use case myself, and while it’s not the end of the world to have to manage two separate APIs and authentication systems, it does seem kinda silly.