| Announced on | Rollout on |
| April 26, 2023 | April 26, 2023 |
After launching the ability to set up webhooks that can receive Zendesk events last year, we’re excited to release support for initiating a webhook invocation based on help center article and community post events.
What's changing?
Admins will now have the option to subscribe to a range of help center article and community post events in addition to the existing user and organization events that were previously available. This addition provides a wider range of event types for admins to choose from when configuring a webhook.
These new event types enable admins to push help center and community data outside of Zendesk to do things like advanced analytics on community activity or automating the awarding of badges based on user engagement.
Why is Zendesk making this change?
Customers have been using business rules and incremental export APIs with Zendesk support to publish business activity data to external systems for a long time, but until now, customers using Guide and Gather have had limited options to do so.
With this release, customers can now build more efficient and robust integrations with their help center and community while also optimizing their API usage.
What do I need to do?
No action is required. This change is automatically being rolled out to all accounts. If you're an admin, the next time you create or edit a webhook, these additional event types will be available to you. For more information, see Webhook event types.
6 Comments
Hi Zach!
Is there a way to receive a webhook notification when an article is updated? Or is this event covered by the "Article published" event?
Hi David,
If you're looking to receive a webhook notification when the content of an article is updated and published this would be covered by the "Article published" event. Does that cover your use case?
Hey Zach Anthony
Pretty cool stuff this new webhooks!
One question related to the above: to prevent duplicate messages being send to e.g. Slack upon ticket update (see here for an example) it might be useful to be able to differentiate between "type": "zen:event-type:article.published", and e.g. the non-existing "type": "zen:event-type:article.created", and "type": "zen:event-type:article.updated",
As a work around I currently grab the article ID, do an API lookup to check its created_at and updated_at dates, and act based on those, but a more native flow might be handy to prevent multiple API calls for one action?
--
Similar, any plans to also include the approval flows in those events? Sending an alert to an editor when an article is submitted for approval or review might be useful. Especially in bigger companies where not everyone from the copyright and marketing departments live in Zendesk or email the entire day. Adding those "articles to review" as tasks in e.g. Asana could be more practical for them.
Hey Thomas! Thanks for the feedback in regards to differentiating between publishing a new article versus re-publishing an existing article. We'll take that on board and think about how we can enable a more native flow for that.
With regards to including the approval flows, this is something we're aware of as a gap with the currently published event types, however I can't provide you a timeframe on when you can expect to see these available via webhooks
Zach Anthony
Would it be possible to also add a payload key for Visibility?
or
Reason:
You might want to only react to publicly visible articles for e.g. auto-post to Twitter (if that still exists..)
If the best practice advice here is: use the Article ID to do an API lookup of the article and get visibility from there, okay. But the less reactive API calls the better.
Hey Thomas, thanks for the additional insight into the use case for including a property that indicates the view permissions for an article. Given that articles are modelled internally with a relationship to the user segment, rather than a direct property of visibility it may not be possible for us to add a property in the way that you have described. This would likely still require an additional API call to retrieve the user segment details to see the set of users that the article is visible to.
Regardless, I'll make sure we capture your feedback to see how we can incorporate a property to help address the use case you outlined, as part of future iterations on the structure of our help center events.
Please sign in to leave a comment.