It appears that there could be some improvements to how tag assignments on topics are exposed through the API. Specifically, the ability to query for newly-added tags on topics. My particular use case is to use tagging in Discourse to indicate that some topic should be exported to another system (a task manager, for example), and I’m planning to use Integromat to do that. But this could as easily apply to any system querying the API to determine if e.g. a “Create Task” tag has been added to a topic and then act on that information.
My understanding is the current API does not easily allow for that. There is a workaround with webhooks, but unless I’m mistaken, a direct API call would be cleaner and simpler.
Thanks for considering it! I hope I’ve put this in the right place.
Adding a tag in a topic will trigger the topic webhook class, that you can listen to in order to monitor any newly added tags in your topics. You can even filter it to a specific tag in Discourse UI, to keep the number of events low.
Thanks for the quick reply! So the “workaround” that Integromat suggests is really the intended way to handle this?
I’m not well versed in API vs. webhooks, etc. unfortunately, but I am specifically thinking about the integration that Fibery has with Discourse. It actually fully mirrors Discourse content, but in a system that allows arbitrary interlinking of data (e.g. topics, users, etc.) for higher-level project and feedback management. They use the API for the integration, as far as I understand:
So if they wanted to support tags in their integration (which they do not currently), including detection of adding/removing tags, would it be possible with the current API? If not, does this suggest some yet-unseen utility for adding more depth to the API’s tag support?
Again I recognize I may be asking obvious questions out of ignorance. Maybe it’s difficult or unreasonably burdensome to expose this in the API, or simply does not make sense for some reason. But hopefully it is an easy enough thing to clarify.
An API call let an outside service call Discourse whenever they like to extract data from Discourse.
However, if that service wants to react to events in Discourse, they would need to periodically pool for changes, which is either wasteful or impractical if there are many “things” to watch/pool.
Webhooks allow Discourse to gently nudge this external service every time a new event happens, so this external service can do their thing only when there is something to do. The service can rely on the webhook payload information, if sufficient, or use it to trigger extra API calls to perform the necessary task. So the API and the webhooks system are complimentary.
Excellent, that’s very helpful. So let’s say you are mirroring Discourse into this external system (Fibery). If I understand correctly, it would be appropriate to use the API to initially collect all topic data, etc. But if you wanted to keep that data maintained over time, e.g. for Category or Tag changes, you’d want to use Webhooks to keep apprised of those changes, right? If so, what about getting data for entirely new Topics? Through the API, or Webhook? Perhaps put another way, does it only make sense to use the API for a one-time pull to populate a mirror, and then Webhooks ongoingly to keep it updated across everything? Or is it a mix of the two, and if so, how does that mix work?
I’d love to be able to close the loop on this topic and know I fully understand how this should work. I am working with the Fibery team to hopefully get them to implement this as well. So if you get a chance to answer my remaining questions, that would be much appreciated.
