You might think of it as cheating (and maybe it’s not as performant as a raw query), but a nifty way that I often use the API for more complex things like this is to do exactly what Yuriy suggested, and save that explore as a look that you then hit with the run_look endpoint. That way you can build out your query in the UI and leverage the content data model that we’ve already built, while still getting the results with the API in your preferred format.
If you don’t want to build a look that might clutter your instance, I would honestly probably still use the create/get/run_query endpoints to execute a looker query that would return unused content results.
You definitely COULD just use a raw API call to get_dashboard, which would return the last_accessed_at data for that dashboard as well as the list of looks on it ( the get_dashboard endpoint returns a DashboardElement object that contains a look_id). You’d then have to also hit the get_look or get_all_looks endpoint and get the last accessed date from that. Then, you’d have to check to see if that look ID is present on a dashboard, and if it is, check if the dashboard accessed date is earlier or later than the look accessed date.
So, definitely possible to do it, but why not make Looker do all the hard work and content mapping for you and just execute a look via the api! Lemme know if I can clarify anything about that