It’d be super great if these was available via an API call that could be iterated over time. That way we use it to identify trending topics/content.
If you can find the data that you are looking for at /admin/reports, you can query the report through the API. Try /admin/reports/trending_search.json?category_id=all for trending search terms. You can set the category_id and search period as parameters.
5 likes
Ahh didn’t realise that was an open API call 
Same thing for admin/reports/top_referred_topics.json?category_id=all!
Everything you see in Discourse is an API by definition, as we are a JavaScript application that runs in the browser. See How to reverse engineer the Discourse API
4 likes
Side note, this feels a bit like saying it’s self documenting code and I should just go figure it out. As a customer, rather than being told that it’d be great to have something added to the docs if it’s being added as an API. Even if it’s just a “this exists here” rather than a full breakdown, it’s a start.
As an open source community member and user, I totally get it’s open and accessible and I would be happy to make more PRs on the docs to expand what’s there.
It’s just finding the tricky balance between these two 
2 likes
The problem with documentation is that it tends to be speculative; my recommendation is to look at the network requests for the exact thing you want to do in the UI which is quite surgically precise 
2 likes
I can totally do this, it’s not a big deal for me technically.
As a customer, my feedback is that it doesn’t feel right that you are telling me I need to analyse network calls of the code in the browser to figure out functionality that could be documented.
2 likes
We are going to expose /admin/reports properly once it is ready and the reports inside it are properly documented and corrected. I think you just have to hold tight here while we clean stuff up.
2 likes
Ahh great, thanks for the heads up