So sorry for the delay here, we’ve gathered some tips from the team which I’ve attached below.
While we don’t have any specific best practices regarding webhooks, the guiding principle should always be to keep event processing overhead as small as possible, on the Shotgun side and on the client-side.
For example, setting up a webhook that is interested in all events from all projects means Shotgun has to send all these events to that webhook. If, in the end, the webhook is only interested in a known subset of these events then it has to filter them out. That’s a lot of overhead on the Shotgun and on the Client side.
This overhead translates into a service that runs at lower efficiency.
So, keeping the following in mind will definitely help:
(Some more details can be found here)
Some other tips:
- You should always try to respond as fast as possible to a webhook call.
- It is definitely worthwhile to set up your webhooks to only receive the events you are interested in (rather than set up a webhook that will receive all events and discard the ones it is not interested in).
- There is no exact rule about whether it is better to have multiple specialized webhooks or a smaller number of webhooks that handle different events, as long as the previous 2 points are taken into account. Also, events are guaranteed to be sent in order for each webhook but not across webhooks.
- You can have multiple webhooks that respond to the same type of event (ex: ‘Shot creation’) but keep in mind that this increases the processing time on the Shotgun side and could increase the delays at which events are received by all webhooks.
- As far as the network is concerned, our webhook stack is hosted on AWS so having webhook endpoints that have a fast connection to AWS will definitely make the calls faster.
Hope that is helpful, let us know if you have any other questions and I’ll be happy to help.